Dec. 1, 2011

Today seems like a fitting day to launch the blog, as it was many moons ago on this day that my post-Academic career began. Looking back I would never have guessed the twisting path that my career has taken, or how seizing opportunities at hand would leave the impression of ‘being in the right place at the right time’. The journey continues, with the always necessary flexibility to deal with the situation, and need for continuous education. Where this wandering path will lead me from here? Only time will tell ...

I plan to use this blog as a space to discuss a variety of topics on development and deployment of new Internet technologies. In the short term the primary focus will be on IPv6, as there is an acute need for guidance across the industry. While everyone would have been better off with a well-planned and orderly deployment over time, by waiting until the last minute to start the industry as a whole has guaranteed the most complex and expensive transition one could imagine. With that as a backdrop, it is time to get on with moving forward.

A blast from the past is as good a way to start as any, so turn the clock back to January 2004:

Death of the Internet - details at 11

The damage done to the Internet architecture by IPv4/NAT is impossible to calculate. How many other applications were quietly withdrawn? More importantly, how many never made it out the door due to the support concerns over the widespread use of a man-in-the-middle attack on the IP header? As primary author for the IAB position statement: RFC 2993 Architectural Implications of NAT, my goal was to expose the serious implications of ‘things that will never exist because they are incompatible with a NAT infrastructure’. At the time I was criticized for ‘not understanding NAT technology’, although I submitted the document from a machine behind 2 layers of IPv4 NAT. As a further point, I had originally proposed a NAT approach in 1987 to deal with inflexible allocation policies at the time, but withdrew it because it broke too many of the existing Internet applications.

While all of that might be an interesting history lesson, what does it have to do with today? Sadly it turns out that there are still many people in a state of denial that are insisting that NAT is the solution and we don’t need IPv6. These are the people that truly do not understand the technology, or have any ability to conceive what might have been. This myopic viewpoint is further compounded by those that insist that carriers can ‘just deploy NAT’ because we already know how that works. Again, sadly they really don’t know. Deployment and operation of NAT at the edge of the Internet is one thing, but doing it in the core is an entirely different animal. While the header mangling process is identical, the operational detail of who has control is the detail that gets overlooked. Beyond the detail of who gets to use which (and how many) port numbers associated with the address, the fact that there will be multiple layers at arbitrary points in the network assures that diagnostics efforts will require multi-party coordination. That simple traceroute in a ‘NAT at the edge’ environment suddenly has multiple instances of 10.1.1.1 in the path, so is that a loop or multiple layers of NAT?

The bottom line: we have known for a decade that we need to change course, and have had the tools to do so, but kept heading deeper into the morass. Now that the debate over exhaustion of the IANA IPv4 free-pool has ended, it is time to get serious about deploying IPv6. The transition need not be abrupt, but avoiding urgent change requires starting well before any issues become critical. Start today ...