Operations and IPv4/v6 Feature Parity

Service provider operators may recall when Cisco disabled routing on the GSR’s management Ethernet port. A large provider was using this management port for DNS, Usenet, and other servers. Somehow, the lack of reachability to the servers was not caught until the morning after the software upgrades. If you are a vendor, you might be thinking, “Why would you connect a LAN with servers to a management port?” This misses the point. The details of the customer environment drive decisions that people who have not operated large-scale networks struggle to understand.

Let’s get to the IPv6 example I discovered today. The example involves JUNOS 9.3. I wanted to ftp a file from an server (C::200) to the router, both in a lab.

You’d think the follow would work; however, the IPv6 literal is not parsed correctly.

jeffl@R5> copy file ftp://jeffl@C::200/testfile /var/tmp

fetch: ftp://jeffl@C:*: parse error

error: file-fetch failed

error: could not fetch local copy of file

 

jeffl@R5>

 

I suspect the problem here is the underlying FreeBSD ftp binary can’t understand IPv6 literals (lftp is the only *nix ftp version I’ve come across that supports IPv6 literals at the command line). I had to create a static DNS mapping as a work-around. I recognize that in production: 1) ftp shouldn’t be used, and 2) DNS is used in most cases. Still, ftp is very common in labs, and I wouldn’t be surprised to hear a lot of operators are still using insecure protocols such as tftp, ftp, and telnet to manage their network.

 

While the ftp issue is minor, the list of minor issues can quickly accumulate items. What happens when one of these annoyances forces Operations to re-write critical scripts that handle configuration management, provisioning, or monitoring? You’ll end up with some grumpy engineers who have to adapt their service assurance practices to compensate for the lack of IPv4/v6 parity.