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

Owen DeLong owen at delong.com
Thu Jan 27 10:06:45 EST 2011

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.  

>> 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.


More information about the ARIN-PPML mailing list