[arin-ppml] ARIN-prop-127: Shared Transition Space for IPv4 Address Extension

[Owen DeLong]

On Jan 27, 2011, at 6:46 AM, Lee Howard wrote:

> 
> 
>>> It's ironic that NAT  traversal hacks can't handle NAT.
>> Not really. They originally  handled it pretty well, with ALG support 
>> making it a lot more friendly.
> 
> ALG isn't NAT.  And without defining a layer-violating protocol,
> (an application-agnostic application-layer gateway)
> it isn't realistic for every NAT implementer to build an ALG for 
> every application that needs one.  
> 
Agreed.

>> However,  CPE's started utilizing uPNP 
>> and applications decided that it was saturated  enough in the market 
>> to use it instead of relying on ALG support. This lead to  applications 
>> creating non-uPNP unfriendly NAT hacks. Now they will regret  it.
> 
> Even if every NAT vendor built an ALG for every new app, new 
> apps couldn't be deployed because of the installed base of NATs
> which didn't have the ALG for the new app.
> 
New apps shouldn't be deployed on IPv4 at this point, arguably,
so that's not really an argument I'm going to buy into.

> So here we are:
> uPNP doesn't work for large-scale NAT, because it can't traverse
>  the NAT layers 
> ALGs aren't a solution, because there are too many applications
>  needing gateways
> PCP is too late for implementation in applications and appliances
> 
> Seriously, for things that don't work beautifully through multi-layer
> NAT, IPv6 is the only way to go.  And if you think NAT444 is
> your solution for exhaustion, you really need to do IPv6, too.
> 
Yep... IPv6 is the only way to go anyway. even for things that do
work through NAT444. I don't think you can defend a claim that
anything works "beautifully" through NAT444. Less ugliness
for some simpler things than others, but, less ugliness is
very different from beauty.

Owen