Mailing List Archive

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
Re: Renumbering and the Feb 15-16 NANOG meeting [ In reply to ]
Craig,

I think that this would be an opportune time to mention the PIER [Procedures
for Internet/Enterprise Renumbering] WG; the issues that you mentioned below
fall with PIER's charter to accomplish.

I would recommend that anyone interested get involved with PIER; information
on the PIER mailing list is available at:

http://www.isi.edu:80/div7/pier/papers.html

We also have a block scheduled at the LA IETF, tentatively on Wed. March 6.

- paul


At 06:54 PM 2/17/96 -0800, Craig A. Huegen wrote:

>
>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.
>
Re: Renumbering and the Feb 15-16 NANOG meeting [ In reply to ]
> 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
Re: Renumbering and the Feb 15-16 NANOG meeting [ In reply to ]
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
Re: Renumbering and the Feb 15-16 NANOG meeting [ In reply to ]
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.
Re: Renumbering and the Feb 15-16 NANOG meeting [ In reply to ]
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]
Re: Renumbering and the Feb 15-16 NANOG meeting [ In reply to ]
> 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!
Re: Renumbering and the Feb 15-16 NANOG meeting [ In reply to ]
> > 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.
Re: Renumbering and the Feb 15-16 NANOG meeting [ In reply to ]
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]
Re: Renumbering and the Feb 15-16 NANOG meeting [ In reply to ]
On Mon, 19 Feb 1996, Matt Zimmerman 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'.

/cah
Re: Renumbering and the Feb 15-16 NANOG meeting [ In reply to ]
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]