In message <1256085698.30246.109.ca...@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 (ka...@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: ma...@isc.org