2014-05-29 16:46:00 UTC

Does anyone have a Decision Matrix, a list of concerns, a Project Plan or lessons learned for IPAM tools?


We have recently initiated a project to integrate our IPv4 network with IPv6 capabilities. We believe that our first step is to make customer facing applications accessible via IPv4 and IPv6.  

Does anyone out there have a Decision Matrix, a list of concerns, a Project Plan, or any other type of document that would help us get started down the right path? Lessons Learned?  

What issues should we be prepared to address?

  • Address Scheme
  • Applications
  • Infrastructure Inventory of devices that can or can not support IPv6
  • Appliances
  • Servers
  • DNS
  • DHCP
  • etc.
Guest
33 Answers

author avatar
Vendor

Thanks for the information John. I really appreciate it.

2014-06-12 13:36:28 UTC
author avatar
Vendor

PS. I found a talk I gave about our "IPAM" 7 years ago:
https://www.questnet.edu.au/questnet2007/Presentations/Thursday12/Bluewater/John_Mann_FINAL_WEB.pdf

I think it contains some interesting stories about problems faced, solutions found, lessons learned.

Thanks,
John

2014-06-11 21:29:29 UTC
author avatar
Vendor

Firstly: I don't have any experience with commercial IPAM tools because we built our own DNS/DHCP management system in 1994, started adding IPv6 to it in 2003, ...

Lessons learned:
1. It is very useful to have _one_ IPAM host database entry that is linked to Mac address, IPv4 address, IPv6 addresses (link-local, SLAAC, and "fixed"), and some controls over whether these addresses are published in the DNS.
2. Collect IPv6 addresses in use on your network, e.g. by polling ND tables on routers, and add them to your database.
3. Publish reverse DNS, even if you don't put AAAA records in the forward DNS.
4. Publishing the AAAA record for a host is _the_ trigger for clients to start using it.
For safe development/testing of IPv6 on a production host, map a different name e.g. -v6 to the AAAA address of the server.

5. Choose your IPv6 subnet plan carefully. Simplicity (e.g. nibble boundaries) is much more important than address conservation. Be prepared to dump your address plan and do it again.
6. Have one database of "subnets" that has both IPv4 and IPv6 addresses associated with it. Don't have separate IPv4 and IPv6 databases!

Generally:
7. You must build a monitoring system that checks that your IPv6 networks and services are working.
Since many clients now have IPv6, IPv6 services must now be production-quality with feature and performance parity (or close) with IPv4 services.
8.Pay special attention to access rules in, e.g. router ACLs, host firewalls, application config. Make sure they have equivalent rules for IPv4 and IPv6, and that in the future, if one family is updated that the other is updated too. Bonus points if you can link your IPv4 and IPv6 network security objects to your IPAM database -- to avoid having to have duplicate information that you need to manually sync!

2014-06-11 11:53:44 UTC