Renumbering and the Feb 15-16 NANOG meeting
As I sat in the auditorium listening to the speakers at the NANOG meeting Thursday and Friday, a realization came to me. Almost every speaker there who happened to talk about the problems with space and CIDR and what-not said "renumbering is a fact of life", or "renumbering is a simple method to solving these problems". While contemplating this, I realized that every speaker who said something along these lines really hasn't done massive renumbering to fulfill CIDR plans--they either have this HUGE block (i.e., major provider like SprintLink) that just needs to be aggregated on out-bound or aren't involved in the direct operation of NSP/ISP's. I've seen a specialty provider renumber about 15 class C's _twice_, the first because he changed providers and they urged him to CIDRize. He then had to change again when the first provider didn't live up to the contractual obligations. Because of a lack of planning on his part, he lost 20% of his customer space during/after these renumberings--customers don't want to put up with problems such as a) applications which compute the IP address into an equation with the license number, b) problems with _all_ parameters not being changed in terminal servers and hosts, c) DNS problems with off-site backup servers, and a few others that just generally made his customers not happy. (Keep in mind that "a)" above generally requires you to purchase new licenses from the software manufacturer.) The problem, you ask? I don't see very many resources available which help ISP's to renumber more easily--time line planners, reminder lists with commonly-missed parameters, etc. I realize that renumbering is a fact of life--my last post, however, shows my true feelings regarding most pre-CIDR blocks; that their providers should be willing to allow customers to keep using the space they allocated in the pre-CIDR days. If there are these renumbering resources available, make sure that the small and big providers alike are making them available to the customers who are willing to attempt a re-number. Make sure the customer service of the provider is willing to deal with the complexities of renumbering (and keep in mind it _IS_ a very complex project--EVERYTHING from IP addresses to static routes to applications which are hard-coded). Unfortunately, the ISP that I saw change providers didn't have this help at their fingertips--they could have potentially saved almost all of the customers they lost. My thanks go out to everyone who made this NANOG one of the best--keep up the good work! /cah
On Sat, 17 Feb 1996, Craig A. Huegen wrote:
While contemplating this, I realized that every speaker who said something along these lines really hasn't done massive renumbering to fulfill CIDR plans--they either have this HUGE block (i.e., major
Errr, *bonk*. Stupid me. What I meant to say is that I expect (from the various speakers' positions) that these people haven't faced large renumbering lately. I didn't mean to accuse the others of not knowing about renumbering--it is much harder than anyone at the NANOG meeting made it sound. Yakov said during his talk that the cost of the route announcements should be more than the cost to renumber into a provider's block; unfortunately, this cost would be HUGE if you consider an average "medium-sized" provider and the hours required to renumber 8 /24's or so. I also meant to applaud the PIER WG's work to help others do renumbering--and recommend that all providers make this available on their web hierarchy (hopefully somewhere EASY to find). Any other information the providers can serve to help out is great, too. /cah
I've seen a specialty provider renumber about 15 class C's _twice_, the first because he changed providers and they urged him to CIDRize. He then had to change again when the first provider didn't live up to the contractual obligations. Because of a lack of planning on his part, he lost 20% of his customer space during/after these renumberings--customers don't want to put up with problems such as a) applications which compute the IP address into an equation with the license number, b) problems with _all_ parameters not being changed in terminal servers and hosts, c) DNS problems with off-site backup servers, and a few others that just generally made his customers not happy.
(Keep in mind that "a)" above generally requires you to purchase new licenses from the software manufacturer.)
The problem, you ask? I don't see very many resources available which help ISP's to renumber more easily--time line planners, reminder lists with commonly-missed parameters, etc.
We could use your help in the PIER wg. The areas you have identified are areas that need a lot of work. (Note that I have renumber large chunks of space three times, 127 class C nets, a class B and part of a class A) If you could help identify those vendors who make use of a), then we could take soem time to wrok with them on other methods. b) is being worked on by Dave O'Leary and c) is part of the Dynamic DNS work. -- --bill
Date: Sun, 18 Feb 1996 19:37:08 -0800 (PST) From: bmanning@ISI.EDU (Bill Manning) Message-ID: <199602190337.AA09149@zephyr.isi.edu> c) is part of the Dynamic DNS work. Not necessarily (not the way I read the message you quoted). The problem with off site secondaries with renumbering is generally that they have the IP address of the primary server in their named.boot file, and don't necessarily update it in any big hurry, even if requested. This is not an internal DNS issue, and dynamic dns isn't doing anything about this problem at all - that is, it is more just an implementation issue (the named.boot file could have names in it instead of IP addresses, with a bunch of extra work to make sure the name could still be resolved). kre
I'd like to see a DNS xfer protocol that allowed secondaries to be completely updated from a master - ie, the master could send all types of updates to the secondary site - mater ip address, domains to handle, etc. Perhaps it exists, but I haven't heard of it. Most people seem to be doing the "send email to the secondary admin" or "get root on the secondary machine" things.
On Mon, 19 Feb 1996, Jon Zeeff wrote:
I'd like to see a DNS xfer protocol that allowed secondaries to be completely updated from a master - ie, the master could send all types of updates to the secondary site - mater ip address, domains to handle, etc.
Hmm...so a secondary DNS server would be told by another which primaries it should trust? Sounds like trouble to me. As does allowing remote creation of zones. This should not be part of a DNS standard. Setting aside the security aspect, how would this be implemented? Would the secondary server poll the primary at intervals to determine how it should reconfigure itself? Or switch to a "server push" method of transfer? You're better off setting up a seperate subsystem to manage the configurations. // Matt Zimmerman Chief of System Management NetRail, Inc. // mdz@netrail.net sales@netrail.net // (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]
I'd like to see a DNS xfer protocol that allowed secondaries to be completely updated from a master - ie, the master could send all types of updates to the secondary site - mater ip address, domains to handle, etc.
Hmm...so a secondary DNS server would be told by another which primaries it should trust? Sounds like trouble to me. As does allowing remote
Sounds like a lot less trouble than giving someone root on my machine because I don't want to be bothered everytime he starts providing service for another domain. Obviously it should have various authentication and access control features. I agree that this is probably a new protocol.
On Mon, 19 Feb 1996, Jon Zeeff wrote:
I'd like to see a DNS xfer protocol that allowed secondaries to be completely updated from a master - ie, the master could send all types of updates to the secondary site - mater ip address, domains to handle, etc. Hmm...so a secondary DNS server would be told by another which primaries it should trust? Sounds like trouble to me. As does allowing remote Sounds like a lot less trouble than giving someone root on my machine because I don't want to be bothered everytime he starts providing service for another domain.
If this is that often, perhaps he should be doing his own secondary DNS. Or you could set up an automated system (perhaps with a user-friendly WWW interface?) that authenticates username/password pairs and makes controlled changes. Dunno about you, but I wouldn't trust my DNS configuration to very many of our customers, authenticated or no. Even if you do allow others to make changes, there's no reason why superuser access is required make changes to the bootfile. // Matt Zimmerman Chief of System Management NetRail, Inc. // mdz@netrail.net sales@netrail.net // (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]
On Mon, 19 Feb 1996, Craig A. Huegen wrote:
If this is that often, perhaps he should be doing his own secondary DNS. Even if you do your own secondary DNS, you still should have off-site backups 'just in case'.
From what I gather, the customers involved are downstream from branch.com, and as such a backup there doesn't seem to be serving much purpose. In the two most probable scenarios of unreachability:
1. branch.com has connectivity problems with the world: The "backup" servers aren't reachable either. 2. Customer has connectivity problems with branch.com: The hosts to be resolved probably aren't reachable anyway. When it is necessary to maintain a backup nameserver on a network administered by someone else, and frequent changes are required for maintenance of said nameserver, a system would be necessary to oversee such changes. I don't think that this situation is widespread enough to justify standardization. Most of our customers here have one or two domains, and rarely, if ever, add more (excepting the in-addr hierarchy, but since we assign them address space anyway, we can't unload that part of the duty). // Matt Zimmerman Chief of System Management NetRail, Inc. // mdz@netrail.net sales@netrail.net // (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]
I'd like to see a DNS xfer protocol that allowed secondaries to be completely updated from a master - ie, the master could send all types of updates to the secondary site - mater ip address, domains to handle, etc.
Perhaps it exists, but I haven't heard of it. Most people seem to be doing the "send email to the secondary admin" or "get root on the secondary machine" things.
this is on my personal list for some time after DNSIND closes and we get it all implemented. if someone else gets to it sooner, well, great!
participants (6)
-
bmanning＠ISI.EDU -
Craig A. Huegen -
jon＠branch.com -
Matt Zimmerman -
Paul A Vixie -
Robert Elz