- Test - lists.nanog.org

Re: BGP announcements and small providers
by Justin W. Newton 27 Feb '97

27 Feb '97

At 02:31 PM 2/26/97 -0500, Bradley Dunn wrote: >On Wed, 26 Feb 1997, Lyndon Levesley wrote: > >> Nameservers are a bit harder to renumber, but that's not too bad. > >When you have hundreds of virtual web sites? Uhm, sure. Just slowly decrease the TTL on your name server until you are ready to renumber (and the TTL is set to something ridiculously low such as 1 minute). The customers will then experience something like a 1 minute outage when you renumber. If we are going to start getting into the procedures of HOW to renumber this should likely move to the PIER mailing list. I think if in general people become more interested in HOW to gracefully renumber themselves and their customers instead of worrying about how hard it is to do they would see that while it is work, it isn't really all that hard. Justin Newton Network Architect Erol's Internet Services ISP/C Director at Large

8 8

Re: BGP announcements and small providers
by Stephen Sprunk 27 Feb '97

27 Feb '97

What is difficult about renumbering DNS entries? You DO refer to your websites with hostnames don't you? The nameservers themselves are a bitch (since you break all the clients unless you're using dhcp) to renumber, but none of your other services should have problems. What protocols (besides FTP) are you referring to? FTP translators are common enough, and I am not aware of any other user application protocols that transmit IP addresses. Stephen Sprunk At 14:31 26 02 97 -0500, you wrote: >On Wed, 26 Feb 1997, Lyndon Levesley wrote: > >> Nameservers are a bit harder to renumber, but that's not too bad. > >When you have hundreds of virtual web sites? > >> Wonder how long it'll be before ISPs rather than corporates start to >> use NAT for most of their network. > >When our customers stop wanting to use applications that carry IP >addresses at the application layer. Until then, NAT is a no-go. > > >pbd > > >

3 2

Re: BGP announcements and small providers
by Paul Ferguson 27 Feb '97

27 Feb '97

At 06:17 PM 2/25/97 -0700, Chris Phillips wrote: > >We service hundreds of dedicated customers and some customers don't mind >renumbering (if they are small) but most of our larger customers who have >more than 100-200 hosts on their network have expressed GREAT opposition to >any such notion of renumbering. Its not that they don't want to do it >because they are lazy, on the contrary, many companies cannot the afford the >downtime or cost asociated with renumbering their LAN/WAN. I agree that >renumbering is an important aspect of address grooming for better agregation >but there are some real $$$ costs to some end-user networks to do so. Also, >how many times can you ask a customer to renumber before they bail and go >elsewhere? > It's been suggested that renumbering is a fact of life; everyone will do it at least once in their lifetime. This is one of the reasons why an entire working group in the IETF has been created to deal with this from an operational perspective. See: http://www.ietf.org/html.charters/pier-charter.html and http://www.isi.edu:80/div7/pier/ See also RFC2071. - paul

8 7

Re: BGP announcements and small providers
by Stephen Sprunk 27 Feb '97

27 Feb '97

At 15:10 26 02 97 -0600, you wrote: >You're making lots of assumptions. > > >1) That client DNS systems will actually honor such a TTL. Many > don't (claim they're broken all you want, but these are the facts). > >2) That client SOFTWARE will actually go back and ask again for the > IP number. Several won't (Netscrape being rumored to be one of > them). TTLs are irrelavent in that case. > >Go ahead and try to tell your customer, who purchased web service from you, >that you have the right to disrupt their operations at any time and under >any pretense and see how many of them you have left. I would hope that your contract didn't state the customer was guaranteed the same IP for eternity; if so, your legal department needs to be hanged. You can either renumber once into an RFC 1918 block and use NAT, or you can renumber into a new space every time you change providers. Your customers will understand renumbering once, especially if you can find a way to improve services with it. They'll look elsewhere if it happens more than once or twice, or if they get nothing from it. Benefits of NAT? You can allocate as many addresses as you want to each of your customers, regardless of how many you actually advertise. For instance, if you had a provider with a cluster of servers, they could all have the same external IP, and NAT could do load-balancing between them internally (with a bit of hacking). I'm sure there are other benefits I'm missing. You can minimize the effects of renumbering by doing it at "off" hours, by leaving old addresses active for a month, etc. There are plenty of people who are willing to help you make this as painless as possible. If Microsoft wrote noncompliant DNS code in their stacks, that is an issue to be taken up with them, and something that can probably be incorporated into the next service packs. This is not a NANOG issue or even a provider contract issue. As for broken browsers, most applications cache the hostent after the first gethostbyname() call each session. This is not likely to change, and a 1 month compatibility period will easily be sufficient. After all, have you ever seen Netscape run a month without crashing?

6 11

Re: BGP announcements and small providers
by Stephen Sprunk 27 Feb '97

27 Feb '97

At 19:13 26 02 97 -0500, Bradley Dunn wrote: >On Wed, 26 Feb 1997, Stephen Sprunk wrote: > >> What protocols (besides FTP) are you referring to? FTP translators are >> common enough, and I am not aware of any other user application protocols >> that transmit IP addresses. > >I believe CUSeeMe does. I believe NAT also breaks IPSec and mobile IP. >Maybe I am wrong, though... AFAIK, CUSeeMe doesn't transmit any addresses at the application level. The clients display IP addresses to the user, most likely due to the assumption that most people won't remember them and it helps cut unsolicited CUSeeMe calls. If the client knows that NAT is occurring, IPsec can take that into account and encrypt/authenticate its packets accordingly. This is a bad solution, but I doubt IPsec will become common before IPv6 takes over. I have heard rumors that IPv6 allocations will not be provider-based, so there will be no need for NAT. I'm not familiar enough with Mobile IP to comment on that, other than to say it's not common yet. >pbd Stephen Sprunk

3 2

Re: F.Root-Servers.net and bogus data
by Eric Kozowski 26 Feb '97

26 Feb '97

>Whois has the contacts for the various root servers. As an alternative, >mail to action(a)internic.net will work. The InterNIC has a 24x7 noc whose >personnel monitor that alias as well as monitoring the roots via an network >monitoring system. It would be nice if email to action(a)internic.net actually caused action or even an ack. So far my email sent on 2/14/97 to action(a)internic.net regarding a bogus host record has gone unanswered. Structured Ticket #2796 for reference of the folks at InterNIC. Eric PS - This isn't the first time email to action(a)internic.net has gone unanswered. -- Eric Kozowski Senior Network Engineer eric(a)structured.net Structured Network Systems, Inc. (503)525-9375 FAX http://www.structured.net/ (800)881-0962 Voice PGP Key fingerprint = 2E 5F 3E 6D AA 61 AA 14 D8 FB A4 15 CE 2C D8 8C 'They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.' -- Benjamin Franklin 1759

2 1

Re: BGP announcements and small providers
by cdc＠groupz.net 26 Feb '97

26 Feb '97

>Uhm, sure. Just slowly decrease the TTL on your name server until you are >ready to renumber (and the TTL is set to something ridiculously low such as >1 minute). The customers will then experience something like a 1 minute >outage when you renumber. If we are going to start getting into the >procedures of HOW to renumber this should likely move to the PIER mailing >list. I think if in general people become more interested in HOW to >gracefully renumber themselves and their customers instead of worrying >about how hard it is to do they would see that while it is work, it isn't >really all that hard. > Why don't you slowly decrease the TTL on your name server until you're ready to renumber. Configure your web server bind to the old address(es) and new address(es). Re-number in the DNS, and your customers will experience something like no down time. Then put the TTL back to where it normally is. -Christopher

2 1

Re: optimal web service (Re: BGP announcements and small providers )
by Paul A Vixie 26 Feb '97

26 Feb '97

> > My approach avoids the use of BGP, but not for the above stated reasons. As > > I said at the SF NANOG, it is hard to get transit providers to send a full > > BGP table, it is hard to accept it, and it would take a modified GateD that > > randomized destinations in order to keep BGP's path selection from leading > > 90% of your routes down 1/Nth of your transit providers. BGP was the wrong > > answer. > > Were the majority of your paths going down one single provider because > of a silly tie-breaker like the numeric value of the IP address of the > peer, Mostly. > or was it because that provider had a shorter AS path? If its > the latter, where's the problem? AS path elements are not indicators of path badness. a!b!c!d might be better than x!y!d depending on whether (a!b + b!c + c!d) < (x!y + y!d). Some of the links could be subrate T3s or SMDS or ATM whereas others could be FDDI or private multi-DS3 interconnects. BGP wasn't intended to be used this way, that's why it doesn't have an end to end connection quality / linkstate model. > If one provider has a better path > and you aren't out of bandwidth on the connection to that provider, > why would you want to take a different path? Defining "better" when all you have to work with is BGP, is pretty hard. It turns out that, as in DNS, round robin is better than any definable static ordering.

1 0

Re: BGP announcements and small providers
by Justin W. Newton 26 Feb '97

26 Feb '97

At 10:50 AM 2/25/97 -0500, Paul Ferguson wrote: >Well, without naming names, the prefix-length based filtering is >done on non-customer routes. A byproduct of this is it grudgingly >encourages aggregation. Well, yes, but now that multiple providers are doing this the fact that they are non-customer filters affects anyone who is not a customer of BOTH providers, thus further encouraging people to aggregate. I would not mind seeing these filters become more prevalent, making it unreasonable for people to become customers of everyone who filters to get around the filters. Renumbering is NOT that hard folks, and it DOES help. Justin Newton Network Architect Erol's Internet Services ISP/C Director at Large

11 14

Re: BGP announcements and small providers
by Lyndon Levesley 26 Feb '97

26 Feb '97

Stephen Sprunk wrote : |-> What about application protocols like ftp that specify network addresses in |-> the protocol session? Do you propose the NAT gateway alter FTP packets in |-> transit? |-> Yes, that is exactly what NAT does - it has a pool (or a static list, or both) of "Externally facing" IP addresses, and it alters the IP packets in realtime (in both directions, obviously) between "Externally facing" IP and "Internally facing" IP address, on a per-conversation basis. It then keeps a "cache" of what addresses have been dynamically mapped to what. The aggro used to be that for things like DNS/Mail/News etc. (almost any service machine) you have to keep the IP address the same and not dynamically change it. However, NAT boxes allow you to use dynamic mapping for your users and static for your other services. They also provide extremely good security - check out Cisco's PIX at : http://www.cisco.com/warp/public/751/pix/index.html which is basically a low spec PC in a rack-mountable box, that can happily perform NAT at 100Mb/sec. CPU-wise, NAT is not a hard thing to do, although you might end up needing a fair whack of memory on a box with *lots* of flows per second. The security features of the PIX are not a feature of NAT - they are a feature of the PIX, so you don't (I presume ;) get them on standard NAT boxes. |-> Also, I don't believe it will be possible to use host or user-based AH/ESP |-> with NAT, since they protect the source address. |-> Good point - TBH, I don't know how NATs deal/don't deal with ESP. Although the last time I looked, ESP had only been implemented with DES, and was therefore fatally flawed (there was a draft by Bellovin about this somewhere...) This is not an insurmountable problem - it can be solved either at the initial key exchange, or by the NAT in realtime, and will hopefully be / have been solved by one of the ipsec groups - I'll go and check out ESP again and see if NAT breaks it or not - I don't know much about it at the mo' |-> Stephen Sprunk |-> Cheers, Lyndon Levesley Xara Networks |-> At 17:34 26 02 97 +0000, Lyndon Levesley wrote: |-> > There's always the nice 'n' easy system of using 10/8 and NAT as a |-> >provider, making renumbering about 5 minutes work. |-> > |-> > Even taken to the extreme, it wouldn't take long to change your BGP |-> >announcements / have your provider change their BGP announcements / |-> >whatever. |-> > |-> > Nameservers are a bit harder to renumber, but that's not too bad. |-> > |-> > Wonder how long it'll be before ISPs rather than corporates start to |-> >use NAT for most of their network. |-> I've had a wonderful time... ...but this wasn't it.

1 0