Unreadable IPv6 Addresses Might Be Good For Us in the Long Run
One of the first arguments used by networking engineers living in IPv6 denial and trying to justify their stance is “IPv6 addresses are unreadable. We will never migrate to IPv6; it’s much easier to deal with IPv4 addresses.”
That’s absolutely true. If you use RFC 1918 addresses in a small(ish) network, the first two octets don’t change, and it’s easy to remember the remaining two numbers … but the unreadable IPv6 addresses just might change the way we approach network configuration and monitoring.
It’s obviously hard to remember the 128 bits of an IPv6 address written in hex, and even though you might eventually remember you PI prefix, and use some smart memorizable addressing scheme, you’ll still have to deal with autoconfigured addresses and random ones generated by SLAAC privacy extensions.
Now ask yourself: why would you want to remember the network addresses of individual servers or network devices? The simple answer: because network configuration, monitoring and address management tools suck – the vendors obviously didn’t do their job. We’re quick to tell everyone how to use DNS to map application names into underlying network addresses, but we don’t do that when configuring our network devices.
How many show printouts use reverse DNS lookup? Not many, the notable exception being OSPF printouts in Cisco IOS – if you configure OSPF to use DNS. How many times can you use a host name when configuring routing protocols, ACLs or firewall rules?
While it might not be a good idea to use dynamic DNS-based packet/session filters for security reasons, it wouldn’t be so hard to allow the network operator to enter the rules using FQDNs, store the rules in FQDN format, do the DNS lookups, start using the results of the DNS lookup as a packet filter, and alert the operator if the DNS mappings suddenly change (without rewriting the actual packet filter, because the DNS server might have been compromised).
When the uproar about unreadable IPv6 addresses becomes noticeable, some vendors just might decide to do something about the problem, at which time it’s up to you to vote with your wallet. It’s also entirely possible that all vendors will continue to pretend there’s no problem till they wear us down and we accept that we have to deal with yet another unnecessary burden.
So the support for resolving addresses needs to be better than the current "oh, this is an address, let me do a lookup before printing" approach. Maybe an async lookup cache and quick timeouts on the output side.
Please add to the "suck list" also the device instrumentation, e.g. SNMP agents on routers, switches, servers, firewall, etc. I tried to build an address management tool for IPv6, and find out that pulling SNMP ND tables (and other equally fundamental IPv6 data) from devices is worse than pulling ARP tables, and keep in mind that an ASA (that many branch users have as a default and only gateway) won't let you do even that! Put VRFs and their nonexistent SNMP support in the mix, and you have some of the reasons why address management tools, and management tools in general, as you said, suck.
As for numeric vs. names in config, we debated this issue a lot (for IPv4) in my company, since we maintain some iptables based firewalls with lots of rules, and in this environment you actually have all the tools to put together such a solution.
There are some issue that complicate the specification (implementation per se is not difficult), and I would like to share some thoughts.
Network devices and firewalls provide connectivity, which is a prerequisite for a working DNS. If you want to have names in the configuration, some kind of persistent (surviving AC failures) DNS caching is required. How exactly should such a cache be managed?
A name/IP mapping change is an event that can hardly be regarded as exceptional, since its happening is one of the reasons why we automate this. So you don't want to page the sleeping on-call guy, and actually the only reasonable way to handle it is manual lookup and pondering of a knowledgable person (or discard, which is much more likely).
DNS names are set of addresses, so using names can make you reconsider what you are doing: if you set "ip route 0.0.0.0/0 mynexthop", we can debate what to do when mynexthop has three A and two AAAA records, some in a connected subnet/prefix and some not, what is important is that all this corner cases are well specified and documented.
Fortigate firewalls allow names in objects, but I was unable to find any documentation about this issues.
Reverse lookup in show commands is a real benefit, without adverse effects, provided that IT WORKS. And something that by default tries a server, waits a few seconds timeout, then tries next server up to the end of the server list, doesn't work. Perhaps you know how to configure decent DNS resolution parameters in IOS, and what the defaults are: I don't. A decent resolver would query all servers simultaneously, using the first answer, with a subsecond timeout, and would mark downed server and retry them in the background, so as to make your 400K lines "sh ip route" possible. Unlikely to happen, even in mainstream desktop and mobile OSes.
Best regards,
Bergonz