ISP customer assignments

Wed Oct 21 02:01:56 UTC 2009

In message <1256085698.30246.109.camel at karl>, Karl Auer writes:
> > 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.
> >=20
> > 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?

Well request it from you favorite router vendors.  Router/vpn/firewall
vendors should be forced to renumber annually.  That way they would
have some incentive to make their products usable when a renumber
event occurs.  The same applies to other vendors.

> 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!
> 
> --=20
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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
> 
> 
> --=-lq/A/spfwZ9P7pLx73k/
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: This is a digitally signed message part
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> 
> iEYEABECAAYFAkreWLgACgkQSkRqA/Q6fe//UACfcPMTlaufxR4sk8pfJ9d7Uk/W
> rW4AmgNnotHOzM4DnvcT90ow+0kDxMVF
> =aZzD
> -----END PGP SIGNATURE-----
> 
> --=-lq/A/spfwZ9P7pLx73k/--
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org