October 1999 - Test - lists.nanog.org

Re: ISP and NAT (question and some thoughts)
by Vadim Antonov 19 Oct '99

19 Oct '99

O, wow. Take two broken-as-designed technologies, mix together... :) --vadim > 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.

2 1

ISP and NAT (question and some thoughts)
by Alex P. Rudnev 19 Oct '99

19 Oct '99

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

Offtopic: VERIO --> BGP/Routing problem? (fwd)
by Tim Wolfe 18 Oct '99

18 Oct '99

I e-mailed this to noc(a)verio.net as per their contact information on the page at puck.nether.net I also attempted to contact their 800 "noc" number but it dumps me into a queue for customer support (hold queues suck BTW). Can someone with a clue from Verio please contact me off list ASAP? (If they didn't invite all of those people to go elsewhere that is) -- Tim -------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim(a)clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * -------------------------------------------------- ---------- Forwarded message ---------- Date: Mon, 18 Oct 1999 11:41:22 -0700 (PDT) From: Tim Wolfe <tim(a)clipper.net> To: noc(a)verio.net Cc: support(a)clipper.net Subject: BGP/Routing problem? I'm getting extremely irate customers all with complaints about sites/networks on Verio's network. Traceroutes to multiple locations all die as shown below, any ideas? [root@net-admin /root]# traceroute www.continet.com traceroute to hansolo.continet.com (206.58.168.253), 30 hops max, 40 byte packets 1 gateway.hq.eug.clipper.net (216.116.45.190) 0.532 ms 0.425 ms 0.398 ms 2 coburg04.router04.clipper.net (209.180.239.254) 19.263 ms 38.812 ms 38.601 ms 3 noc.coburg06.eug.clipper.net (216.116.32.53) 123.452 ms noc.co02.eug.clipper.net (216.116.32.1) 112.872 ms noc.co04.eug.clipper.net (216.116.32.5) 77.812 ms 4 cisco.core.eug.clipper.net (216.116.32.65) 83.984 ms 29.316 ms 248.527 ms 5 border02.usw04.clipper.net (207.109.242.45) 544.418 ms 243.517 ms 101.522 ms 6 router.usw.clipper.net (207.109.240.250) 234.573 ms 158.146 ms 92.305 ms 7 500.Serial5-1-0.GW1.POR2.ALTER.NET (157.130.177.201) 272.617 ms 140.342 ms 192.853 ms 8 121.ATM3-0.XR2.SEA1.ALTER.NET (146.188.200.182) 63.554 ms 97.295 ms 87.504 ms 9 194.ATM8-0-0.BR1.SEA1.ALTER.NET (146.188.200.77) 38.719 ms 85.008 ms 67.806 ms 10 uunet.sea3.verio.net (129.250.9.53) 132.312 ms 77.157 ms 187.899 ms 11 sea3.sea2.verio.net (129.250.2.229) 104.399 ms 51.872 ms 47.942 ms 12 * * * [root@net-admin rc.d]# traceroute 205.162.201.235 traceroute to 205.162.201.235 (205.162.201.235), 30 hops max, 40 byte packets 1 gateway.hq.eug.clipper.net (216.116.45.190) 0.536 ms 0.410 ms 0.387 ms 2 coburg04.router04.clipper.net (209.180.239.254) 14.443 ms 9.093 ms 10.161 ms 3 noc.co04.eug.clipper.net (216.116.32.5) 21.815 ms noc.coburg06.eug.clipper.net (216.116.32.53) 18.024 ms 20.605 ms 4 cisco.core.eug.clipper.net (216.116.32.65) 69.319 ms 19.117 ms 19.315 ms 5 border02.usw04.clipper.net (207.109.242.45) 27.940 ms 39.711 ms 54.538 ms 6 router.usw.clipper.net (207.109.240.250) 83.400 ms 48.314 ms 74.778 ms 7 500.Serial5-1-0.GW1.POR2.ALTER.NET (157.130.177.201) 123.655 ms 60.980 ms 56.282 ms 8 121.ATM3-0.XR2.SEA1.ALTER.NET (146.188.200.182) 58.828 ms 86.353 ms 82.602 ms 9 194.ATM11-0-0.BR1.SEA1.ALTER.NET (146.188.200.69) 70.771 ms 169.238 ms 58.317 ms 10 uunet.sea3.verio.net (129.250.9.53) 35.361 ms 30.677 ms 57.102 ms 11 sea3.sea2.verio.net (129.250.2.229) 71.382 ms 60.869 ms 54.746 ms 12 * * * -- Tim -------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim(a)clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * --------------------------------------------------

1 1

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