ISP customer assignments

Wed Oct 21 00:41:38 UTC 2009

> There is no need to say at XX:XX on DD/MM/YYYY we will be switching
> prefixes.  One can be much smarter about how you do it.
> 
> You can just introduce the new prefix.  Add second address to the
> DNS.  Do your manual fixes.  Remove the old addresses from the DNS.
> Stop using the old prefix when you are satisfied that there is no
> traffic over them.

True in principle. In practice, changing stuff, especially globally, is
not as simple as that.

Many (most?) enterprises still have pretty primitive DNS/DHCP
management. While there are good management systems out there, many of
the largest are custom made for the enterprise concerned, and are not
yet up to speed with IPv6. The practical experience is not yet there to
drive the development of the right features - especially ones as rare as
a complete renumbering.

DHCPv6 server software is still pretty early days, too.

The addressing on infrastructure kit like routers and switches,
firewalls and IDS boxes and so on is also typically hard coded and
difficult to change, as are the addresses used in ACLs and firewall
rules.

Renumbering means:

- adding a new AAAA record to the DNS for every existing AAAA record,
but using a different prefix (plus any other DNS changes needed - like
giving the servers themselves addresses in the new prefix, and making
sure they reply from the right address...) Reverse lookups may be an
issue during the changeover, too.

- updating DHCP configurations to issue addresses from the new prefixes,
automatically divided along the same numbering plan

- setting up reserved DHCP addresses with the same host parts as the old
reserved addresses but using the new prefix etc

- adding new addresses to every location where an address is hardcoded -
such as in router and switch configurations

- updating ACLs to account for the new addresses (without discarding the
old rules yet)

- updating firewall rules and what-have-you to account for the new
prefix, without discarding the old ones yet

- waiting the weeks or months until the old prefix may be safely
discarded. During this time you have a prefix-schizo network.

- updating firewall rules and what-have-you to remove the old prefix

- updating ACLs to remove the old addresses

- removing old addresses from every location where an address is
hardcoded - such as in router and switch configurations

- removing now-unused DHCP reservations

- removing now-unwanted DHCP ranges

- removing all AAAA records that reference the old prefix

... and this is by no means an exhaustive list. Many higher-level
services will also need updating (twice) - your web server
configurations, for example. And it gets more complicated if your prefix
changes length as well. And what if the network was not set up with
future renumbering in mind? DHCP servers issuing eternal leases, things
like that.

So once again the theory is good, but reality intrudes. Renumbering,
even with the undeniably much better features of IPv6, is still going to
be a royal pain. Of course, IPv6 may drive improvements in all these
areas over time, but they're not there yet.

Wouldn't it be cool to have a "renumber router" command that just took
an old prefix, a new prefix and a number of seconds and did all the
work?

Regards, K.

PS: If anyone knows of an IPAM that can do all the above, or even just
some of the above, please let me know!

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/                  +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20091021/b9431a94/attachment.sig>