The Internet Protocol Journal, Volume 13, No.3

Letter to the Editor

In response to "NAT++: Address Sharing in IPv4," in The Internet Protocol Journal, Volume 13, No. 2, June 2010:

Excellent article Geoff, so good I read it twice. While reading your article I was reminded of a recent experience that falls in the category of "unintended consequences." Since one of your situation descriptions was similar to the one I'm in, I thought I would relay my circumstance and experience and see if I can make my point.

A couple of months ago I signed up for an IPTV trial with my provider, and it was installed with a minimum of effort. The service is based on Cisco Dial-on-Demand Routing (DDR) and, of course, DSL service.

It worked fine for a couple of days; video feeds were good and all my computers and server worked just as before on a wireless network within my home. Then one day it appeared that I had lost Domain Name System (DNS) service, because I couldn't get name resolution to work but could route using the raw IPv4 addresses. So, I placed a trouble ticket and, of course, the provider's first request was to cold boot the DDR device and everything in the house, which I did. Sure enough, upon bringing all components back up (except one), everything was fine.

A day or two later I had to print something and powered on my HP 6510 wireless printer, printed what I needed to print, and then discovered I had lost DNS service again. I placed a trouble call and my provider came out and replaced the DDR device I went through the cold boot process (except one device) and everything was OK until I brought the printer online and the trouble returned. By now I had this nagging memory that wouldn't surface; something about that printer... With the printer powered off I rebooted the DDR, fired up SharkWire, and everything looked and worked OK.

Then I powered up the HP printer and saw another nagging memory; it immediately performed an Address Resolution Protocol (ARP) broadcast of the v4 address 169.254.65.206—the famous black-hole address from RFC 3927 [1]. Immediately after the ARP broadcast, the printer put out the normal Dynamic Host Configuration Protocol (DHCP) request and was assigned one from the Network Address Translation (NAT) pool.

That's when I stepped back from looking at the "trees" and gazed upon the "forest" and realized, with some embarrassment, that the public side (access side) was using a single IPv4 address with Port Address Translation (PAT) so the DDR box was blocking all the outbound PAT addresses attached to the single IPv4 address. I wrote down the details and e-mailed them to my provider, and had revised code pushed to the DDR the next day. Problem fixed.

All of this discussion leads me to ponder about other situations of "hard codes" in the network, either RFC-based or circumstance-based, that will falter with a switch to IPv6. Not in the core but in the customer networks. These unintended consequences could be many. Does HP run a dual stack for IPv4 and IPv6? I doubt it.

How can we get customers and vendors thinking about possible long-ago workarounds that they may have hard coded using IPv4? Any other RFCs out there like 3927? (It used to be easy when there were only a few hundred RFCs.) That could be the most expensive portion of the transition, verifying code ...

Keep up the good work; your articles make me think a lot and I really enjoy them. And, yes, I do use them for reference quite often.

Regards,

—Paul Dover
pdover@centeriem.com

[1] S. Cheshire, B. Aboba, and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses," RFC 3927, May 2005.

The author responds:

Thank you Paul for this anecdote and the important lesson behind it. Over some 30 years of intense development we've managed to accumulate a sizeable volume of technical specifications. Indeed, in October 2010 the RFC Editor published RFC 6068, and I'm not sure that any individual could claim a deep familiarity with every one of them, let alone claim to have a good understanding of their potential interaction. So when we look at various transitional technologies to sustain this industry through the next few years of attempting to support a comprehensive dual stack network in the face of the forthcoming hiatus of supply of IPv4 addresses, it should not come as a surprise when some devices or configurations fail in strange and unexpected ways, simply because they adhere to a technical standard that perhaps we've lost sight of in the flurry of generating new transitional technologies.

—Geoff Huston
gih@apnic.net