- Test - lists.nanog.org

Re: ISP and NAT (question and some thoughts)
by jeanlou.dupont＠na.marconicomms.com 18 Oct '99

18 Oct '99

oups... just thought of an important issue: I guess the clients would care about the address remarking; the DNS process is a good example... jld. --- just a thought... why not expand the IPv4 address field using the 'Fragment offset' and 'Identification' fields? Use those fields to mark packets at the edge with the destination AS number, for example. Customer equipment could use private address space and not bother with the edge remarking process. (I know that the fragmentation function would be lost due to this 'extension'.) (I am also aware of transitioning problems related to what I am proposing; the routers in the network cannot be upgrade all at once...) thoughts/comments? jld. "Alex P. Rudnev" <alex(a)virgin.relcom.eu.net> on 10/18/99 12:46:50 PM To: nanog(a)merit.edu cc: (bcc: Jeanlou Dupont/RMQ/RELTECCORP) Subject: ISP and NAT (question and some thoughts) Today we see the classical schema ISP/customer; this means - the customer have his own address space, requested by him (directly or undirectly) - due to the lack of public addresses, the customers are forced to use NAT; just NAT provide some extra security - ISP do not provide NAT themself; NAT configuration is not easy task and cause a lot of headache for the customers (just as a lot of money they pay to the network admins). First question - is this picture right or it is wrong? The second question. What prevent the _future ISP_ from some another schema, when: - the customer always use the private address space, for example, 10.0.0.0/8; - the provider bother about address translation, just as about name translation (DNS re-writing), just as about the address allocation (not the customer but the provider - if existing address space is not enough); - the providers's software learn about _open, or public_ services which must be translated statically, from the customer using (for example) DNS. Don't answer _it's too slow_. This is my attempt to predict where we are going this days. Today the _know-how_ the customer should know is too huge - if (if I am the admin of the company, not ISP!) I open electronic market or want to get Internet for the companies employees, I must allocate space (why? What for? It's not my concern, if we think a little), I must prove I need this addresses (why? This is my business how much addresses I need internally; and let's software decide how much addresses I need externally), and I should configure firewalls and NAT's. We used to think about it as about the normal admin's knowledge; but why we are sure it's normal. If you got a car (in USA, not in the Russia), you don't bother about the oil stations or about the roads - you just use it. This is not really a dump question. If it is possible to build such Internet service when every customer should be free to use any address space in the hidden way, and ISP (not the customer) bother about the global address and name translation, we should have just this hierarchical address schema IPv6 offer to us. On the other hand, it means a great increase in the NAT engine. Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

3 3

Re: ISP and NAT (question and some thoughts)
by Dean Anderson 18 Oct '99

18 Oct '99

There are a couple of unused bits in the IPv4 header that one could use. I thought of this during the last "paper" to expand address space that circulated this summer on nanog. Unfortunately, the real problem is deployment. Once you decide to change the protocol in any way that is not completely downward compatible, everyone has to deploy the modification. I'm going to hazard a guess that IPv6 will really be widely deployed by tunneling it in IPv4. And I'll hazard that much of the IPv6 traffic will just contain tunnelled "private" IPv4 traffic. Tunnel inside tunnel. So much for header compression. --Dean Around 01:13 PM 10/18/1999 -0400, rumor has it that jeanlou.dupont(a)na.marconicomms.com said: > > > >just a thought... > >why not expand the IPv4 address field using the 'Fragment offset' and >'Identification' fields? >Use those fields to mark packets at the edge with the destination AS number, for >example. >Customer equipment could use private address space and not bother with the edge >remarking process. >(I know that the fragmentation function would be lost due to this 'extension'.) >(I am also aware of transitioning problems related to what I am proposing; the >routers in the network cannot be upgrade all at once...) > >thoughts/comments? > >jld. > > > > > >"Alex P. Rudnev" <alex(a)virgin.relcom.eu.net> on 10/18/99 12:46:50 PM > >To: nanog(a)merit.edu >cc: (bcc: Jeanlou Dupont/RMQ/RELTECCORP) > >Subject: ISP and NAT (question and some thoughts) > > > > > > >Today we see the classical schema ISP/customer; this means >- the customer have his own address space, requested by him (directly or >undirectly) >- due to the lack of public addresses, the customers are forced to use >NAT; just NAT provide some extra security >- ISP do not provide NAT themself; NAT configuration is not easy task and >cause a lot of headache for the customers (just as a lot of money they pay >to the network admins). > >First question - is this picture right or it is wrong? > >The second question. What prevent the _future ISP_ from some another >schema, when: >- the customer always use the private address space, for example, >10.0.0.0/8; >- the provider bother about address translation, just as about name >translation (DNS re-writing), just as about the address allocation (not >the customer but the provider - if existing address space is not enough); >- the providers's software learn about _open, or public_ services which >must be translated statically, from the customer using (for example) DNS. > >Don't answer _it's too slow_. > >This is my attempt to predict where we are going this days. Today the >_know-how_ the customer should know is too huge - if (if I am the admin of >the company, not ISP!) I open electronic >market or want to get Internet for the companies employees, I must >allocate space (why? What for? It's not my concern, if we think a little), >I must prove I need this addresses (why? This is my business how much >addresses I need internally; and let's software decide how much addresses >I need externally), and I should configure firewalls and NAT's. We used to >think about it as about the normal admin's knowledge; but why we are sure >it's normal. If you got a car (in USA, not in the Russia), you don't >bother about the oil stations or about the roads - you just use it. > >This is not really a dump question. If it is possible to build such >Internet service when every customer should be free to use any address >space in the hidden way, and ISP (not the customer) bother about the >global address and name translation, we should have just this hierarchical >address schema IPv6 offer to us. On the other hand, it means a great >increase in the NAT engine. > > >Aleksei Roudnev, Network Operations Center, Relcom, Moscow >(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N >13729 (pager) >(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) > > > > > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: ISP and NAT (question and some thoughts)
by jeanlou.dupont＠na.marconicomms.com 18 Oct '99

18 Oct '99

I guess going to IPv6 would be simpler in this case. Or, we can maybe dream of some 'service locator' function tied to inter-domain MPLS tunnels... again, just food-for-thoughts. jld. "Alex P. Rudnev" <alex(a)virgin.relcom.eu.net> on 10/18/99 02:29:29 PM To: Jeanlou Dupont/RMQ/RELTECCORP@RELTECCORP cc: nanog(a)merit.edu Subject: Re: ISP and NAT (question and some thoughts) Yes, but... The first step doing any increase difficult was done when the HOST_NAME->IP_ADDRESS translation was chosen instead of HOST_NAME:SERVICE -> IP_ADDRESS:PORT Now we have a lot of troubles due to this choose. On Mon, 18 Oct 1999 jeanlou.dupont(a)na.marconicomms.com wrote: > Date: Mon, 18 Oct 1999 13:33:14 -0400 > From: jeanlou.dupont(a)na.marconicomms.com > To: Alex P. Rudnev <alex(a)virgin.relcom.eu.net> > Cc: nanog(a)merit.edu > Subject: Re: ISP and NAT (question and some thoughts) > > > > > > oups... just thought of an important issue: > > I guess the clients would care about the address remarking; > the DNS process is a good example... > > jld. > > > > --- > just a thought... > > why not expand the IPv4 address field using the 'Fragment offset' and > 'Identification' fields? > Use those fields to mark packets at the edge with the destination AS number, for > example. > Customer equipment could use private address space and not bother with the edge > remarking process. > (I know that the fragmentation function would be lost due to this 'extension'.) > (I am also aware of transitioning problems related to what I am proposing; the > routers in the network cannot be upgrade all at once...) > > thoughts/comments? > > jld. > > > > > > "Alex P. Rudnev" <alex(a)virgin.relcom.eu.net> on 10/18/99 12:46:50 PM > > To: nanog(a)merit.edu > cc: (bcc: Jeanlou Dupont/RMQ/RELTECCORP) > > Subject: ISP and NAT (question and some thoughts) > > > > > > > Today we see the classical schema ISP/customer; this means > - the customer have his own address space, requested by him (directly or > undirectly) > - due to the lack of public addresses, the customers are forced to use > NAT; just NAT provide some extra security > - ISP do not provide NAT themself; NAT configuration is not easy task and > cause a lot of headache for the customers (just as a lot of money they pay > to the network admins). > > First question - is this picture right or it is wrong? > > The second question. What prevent the _future ISP_ from some another > schema, when: > - the customer always use the private address space, for example, > 10.0.0.0/8; > - the provider bother about address translation, just as about name > translation (DNS re-writing), just as about the address allocation (not > the customer but the provider - if existing address space is not enough); > - the providers's software learn about _open, or public_ services which > must be translated statically, from the customer using (for example) DNS. > > Don't answer _it's too slow_. > > This is my attempt to predict where we are going this days. Today the > _know-how_ the customer should know is too huge - if (if I am the admin of > the company, not ISP!) I open electronic > market or want to get Internet for the companies employees, I must > allocate space (why? What for? It's not my concern, if we think a little), > I must prove I need this addresses (why? This is my business how much > addresses I need internally; and let's software decide how much addresses > I need externally), and I should configure firewalls and NAT's. We used to > think about it as about the normal admin's knowledge; but why we are sure > it's normal. If you got a car (in USA, not in the Russia), you don't > bother about the oil stations or about the roads - you just use it. > > This is not really a dump question. If it is possible to build such > Internet service when every customer should be free to use any address > space in the hidden way, and ISP (not the customer) bother about the > global address and name translation, we should have just this hierarchical > address schema IPv6 offer to us. On the other hand, it means a great > increase in the NAT engine. > > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow > (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N > 13729 (pager) > (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) > > > > > > > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

2 1

Re: using gated for multi-home BGP
by Michael Heller 18 Oct '99

18 Oct '99

This was just the >primary reason why we dropped out the customers from the PC a few years >ago. Another reason was the stability - the piece of hardware withouth the >disks (Cisco) seems to be just more stable than PC with (often) badly >designed fans, power supply and rotating disks... I've played with some Torrent/Ericcson equipment. They had the foresight to utilize pcmcia flash devices as the stoage on their pc-based RSP. Very nice stuff. Its been a while since I've played with it, however. Michael Heller Sr. Systems Engineer Earthweb, Inc. 212.448.4175 mikeh(a)earthweb.com

1 0

Re: ISP and NAT (question and some thoughts)
by jeanlou.dupont＠na.marconicomms.com 18 Oct '99

18 Oct '99

just a thought... why not expand the IPv4 address field using the 'Fragment offset' and 'Identification' fields? Use those fields to mark packets at the edge with the destination AS number, for example. Customer equipment could use private address space and not bother with the edge remarking process. (I know that the fragmentation function would be lost due to this 'extension'.) (I am also aware of transitioning problems related to what I am proposing; the routers in the network cannot be upgrade all at once...) thoughts/comments? jld. "Alex P. Rudnev" <alex(a)virgin.relcom.eu.net> on 10/18/99 12:46:50 PM To: nanog(a)merit.edu cc: (bcc: Jeanlou Dupont/RMQ/RELTECCORP) Subject: ISP and NAT (question and some thoughts) Today we see the classical schema ISP/customer; this means - the customer have his own address space, requested by him (directly or undirectly) - due to the lack of public addresses, the customers are forced to use NAT; just NAT provide some extra security - ISP do not provide NAT themself; NAT configuration is not easy task and cause a lot of headache for the customers (just as a lot of money they pay to the network admins). First question - is this picture right or it is wrong? The second question. What prevent the _future ISP_ from some another schema, when: - the customer always use the private address space, for example, 10.0.0.0/8; - the provider bother about address translation, just as about name translation (DNS re-writing), just as about the address allocation (not the customer but the provider - if existing address space is not enough); - the providers's software learn about _open, or public_ services which must be translated statically, from the customer using (for example) DNS. Don't answer _it's too slow_. This is my attempt to predict where we are going this days. Today the _know-how_ the customer should know is too huge - if (if I am the admin of the company, not ISP!) I open electronic market or want to get Internet for the companies employees, I must allocate space (why? What for? It's not my concern, if we think a little), I must prove I need this addresses (why? This is my business how much addresses I need internally; and let's software decide how much addresses I need externally), and I should configure firewalls and NAT's. We used to think about it as about the normal admin's knowledge; but why we are sure it's normal. If you got a car (in USA, not in the Russia), you don't bother about the oil stations or about the roads - you just use it. This is not really a dump question. If it is possible to build such Internet service when every customer should be free to use any address space in the hidden way, and ISP (not the customer) bother about the global address and name translation, we should have just this hierarchical address schema IPv6 offer to us. On the other hand, it means a great increase in the NAT engine. Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

2 1

using gated for multi-home BGP
by jim＠reptiles.org 18 Oct '99

18 Oct '99

we are currently using gated to do BGP with some private peers. the configs are based on a few factoids derived from the examples and alot of trial and error. i wonder if there is a site or some sample configs that i can use to learn about using gated/BGP in the following contexts: - filters (rejecting/dropping specific routes RFC1918, default, sub/24, etc) - combining AS's (we have 3+ AS's behind our network) - raising/lowering preferences on routes/AS's also, if using an intel platform, with FreeBSD, what would your recommendations be for processor/RAM with two full peers? -- [ Jim Mercer Reptilian Research jim(a)reptiles.org +1 416 410-5633 ] [ The telephone, for those of you who have forgotten, was a commonly used ] [ communications technology in the days before electronic mail. ] [ They're still easy to find in most large cities. -- Nathaniel Borenstein ]

5 5

Re: Regarding global BGP community values
by Aleksi Suhonen 18 Oct '99

18 Oct '99

On Mon, 11 Oct 1999 22:19:21 -0600 Danny McPherson <danny(a)qwest.net> wrote: > While it's clear that a considerable amount of disagreement exists regarding > transitive communities dynamically doing things, it's extremely simple for > providers to just not pay attention to them. Which is desirable. Customers who want them to work will buy from providers who can make them work. There will still be customers who don't need them for those providers who don't want to pay attention to such communities. The rest shall be history. > Another potential application for global transitive communities, > which is likely even more debatable than path selection issues, > is using them in conjunction with MEDs and "more specifics" of > provider aggregates (to fix some of the brokenness of aggregates > and MEDs) in order to provide a safety net for potential route leaking. This is what the already well established community "no-export" is for. You announce the supernet as you would any normal route and you announce the specifics with "no-export" at only their "best-exits" and only to your multi-exit-peers. That way the specifics can't (well shouldn't be able to at least) leak but no connectivity is lost since the supernet is never a candidate for filtering or dampening. The traffic will follow the supernet until it gets to a network that has the more specifics. No need to litter the routing tables of thousands of autonomous systems that don't have a need to know. The community 65530:arg was in my message for two purposes: ("when announcing to <arg>, replace this community with no-export") * So that you can scratch those hard to reach places, I.e. peers of transits. Tier 1 providers don't have those of course. * So that you can tag your specifics when injecting them with a community that will get automatically replaced with no-export when exporting to your own direct peers. More useful for Tier 1s. It doesn't have the desired effect alone of course, but a trained mind can easily see what other communities are needed to create the correct combination in their own environment. -- Aleksi Suhonen PS. Andrew Partan suggested that I'd write up an example implementation of these communities for Cisco, Juniper and Gated. The Cisco version was already included in the end of my original message, but I'm having trouble with the Juniper implementation. I have no access to a Juniper router and all the references for a configuration manual on www.juniper.net were password protected. Hence I need pointers that would tell me how to configure a Juniper router.

3 2

OT:MarketSpeak
by Eric Germann 17 Oct '99

17 Oct '99

Someone needs to flog the marketing people at Sprint .. http://www.sprintbiz.com/ip/backbone.html "Sprint's Internet backbone includes redundant equipment and diverse routing to ensure the highest reliability. Leveraging Sprint's advanced SONET network, we have specially engineered our network to take full advantage of SONET reliabiliity. In addition, Sprint uses the Cisco Gigabit Switch routers in its backbone, which translates into greater response time and reliability for your users" oops. ========================================================================== Eric Germann CCTec ekgermann(a)cctec.com Van Wert, OH 45891 http://www.cctec.com Ph: 419 968 2640 ICQ: 41927048 Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

15 17

Re: Fiber cuts, telcos and excavators
by Hal Murray 17 Oct '99

17 Oct '99

> I have heard from the excavator community over the years. They often > point out the utilities seem to not care, and don't show up to mark > their utilities on-time. The famous telco appointment time of > between 8 and 5, if at all. The excavator is losing money for every > minute the locate marker is late, or doesn't show up at all. This > isn't a lot of profit margin in excavation. Sometimes the choice is > between not digging and definitely going out of business, or digging > and possibly going out of business. Why is the contractor waiting around? I'm not very familiar with how things are done in the construction industry, but I see a lot of paint on roads and sidewalks around here. I've seen occasional people out putting down paint without any contractors waiting around. I thought the standard practice was to mark the limits of the area you want to dig in with "USA" (Underground Service Alert) and then call the USA 800 number a few days before you want to dig there. That gives the USA people time to contact all the utilities so they can come out and mark the area. I should read the fine print on a call-before-you-dig sign the next time I get a chance. > As far as sending a big bill to the contractor. As has been pointed > out before, most excavators have the minimum insurance and few assets. > And the cynic may look at the number of contractors hired by utilities Does it work to sue the organization that hired the contractor? If not, why?

2 1

Re: IP-Internets
by Vadim Antonov 16 Oct '99

16 Oct '99

Don't know :) I don't recognize cars. (the Mercedes picture is also good :) --vadim >From owner-nanog-outgoing(a)merit.edu Fri Oct 15 21:31:28 1999 Delivered-To: nanog-outgoing(a)merit.edu X-Originating-IP: [171.70.219.30] From: "Ron Buchalski" <rbuchals(a)hotmail.com> To: avg(a)kotovnik.com, rs(a)seastrom.com, salo(a)networkcs.com Cc: nanog(a)merit.edu Subject: Re: IP-Internets Date: Fri, 15 Oct 1999 21:09:17 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing(a)merit.edu X-Loop: nanog >From: Vadim Antonov <avg(a)kotovnik.com> >To: rs(a)seastrom.com, salo(a)networkcs.com >CC: nanog(a)merit.edu >Subject: Re: IP-Internets >Date: Thu, 14 Oct 1999 19:38:34 -0700 > >rs(a)seastrom.com (Robert E. Seastrom) wrote: > > > 99.9% of all Internet traffic touches an Ethernet device. To follow > > Fred Baker's line of reason, this presents irrefutable proof that that > > Ethernet is an appropriate technology for building one's backbone > > network. > >Fred has to move all that ATM crap Cisco acquired over the years. > Vadim, is this a member of your ATM Fan Club? http://www.employees.org/~david/ip.jpg :-) -rb ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1