Operational challenges of no NAT

[Brian E Carpenter]

> We could have written compatibility libraries

I couldn't agree more. This is effectively what Java did
in JDK 1.5 and above, and the result has been that vaste
swathes of Java apps work well in dual stack mode (modulo
the well known RFC 3484 issues and the well known Teredo
and 6to4 glitches).

Regards
   Brian

On 2010-10-30 09:09, David Conrad wrote:
> On Oct 29, 2010, at 9:46 AM, Brian E Carpenter wrote:
>>> The folks not interested in paradigm shifts, as demonstrated by the lack of significant IPv6 deployment, are pretty much everybody else (modulo the tiny percentage of geeks and early adopters).  These folks do not want to care how things work.  The fact that IPv6 makes them have to care is probably the worst failing of IPv6.
>> Unfortunately, it's actually a failing of IPv4 that they have to care,
>> since v4 makes no provision for address extensibility.
> 
> Not a failing of IPv4.  A failing of the the bits and pieces around IPv4 that all _know_ an IP address is 32 bits.
> 
>> That's been
>> our problem since the start - mathematically, there is no transparent
>> upgrade path.
> 
> It is true that it is mathematically impossible to squeeze 128 bits into 32 bits.  However, we seem to have gone out of our way to both force people to make the distinction as well as ensure that we have to go through this crap yet again sometime in the (presumably far) future.
> 
> We could have written compatibility libraries that hid the fact that address length changed so that most applications would simply need to be relinked instead of requiring editing/recompilation.  Even better, we could've pushed address handling into the kernel, returning a 'special' 32-bit value that signified 'not your father's Internet address' (e.g., a class E address) so that most applications wouldn't have even needed relinking.  Instead, we came up with new APIs. Worse, those APIs repeated the errors of letting applications know what an IP address actually looked like and let those application cache those addresses in the application data space.
> 
> We chose fixed-length addresses instead of variable length with a maximum, guaranteeing that we have to be careful in allocation policy.  We failed to address the fact that identity does not depend on network topological location, guaranteeing either routing scalability concerns or imposition of particular business models on the Internet.  Blah blah blah.  I could go on, but what's the point: IPv6 is what it is and we have to deal with it.
> 
> The reality is that the vast majority of people on the Internet don't care about any of this.  They simply want an infrastructural service that works. Attempting to force these folks to undergo a "paradigm shift" is likely to simply result in migration taking longer or simply failing (and everybody making do with multi-layer NATv4 until IPv7 comes along).
> 
> Regards,
> -drc
> 
>