[arin-ppml] IPv6 Non-connected networks

Owen DeLong owen at delong.com
Fri Mar 26 14:56:00 EDT 2010

On Mar 26, 2010, at 11:35 AM, Roger Marquis wrote:

>> STUN, SNAT, UPNP, and a myriad of other often poorly implemented
>> incompatible and unreliable NAT traversal mechnisms, Application
>> layer Gateways, etc.
> Sounds like you're asserting that any application wishing to embed the
> remote IP in the data portion of an IP packet (SIP/STUN/...) or requiring
> a "hole" in the firewall (UPNP) are valid reasons to get rid of NAT?  I
> don't think you'll find much support for those assertions in
> security-related groups (like firewall-wizards).
No... I'm not saying we need  a reason to get rid of NAT. I'm saying that
NAT should be allowed to become obsolete with IPv4.

Those that want the destruction of NAT brought forward to IPv6 are the
ones that would need to justify such an action. I'm arguing for the status
quo.  NAT is implemented and deployed in IPv4 and that's fine. It's not
there in IPv6, and, that's good too!

>> However, at the far end when I'm trying to figure out why something didn't
>> work, any of the following behaviors related to NAT make things more
>> difficult to debug:
> This is an issue with logging, not with NAT or even stateful inspection.
Huh?  How is logging at the UN-NATted end going to in any way change
any of those issues I raised?  Remember, I'm talking about the guy
that is running the service trying to help his customer, not the customer
behind the NAT.

>> There are many many others, but, I think these three that come
>> to me off the top of my head from my own experience are
>> enough to make the point.
> I don't know who might be persuaded to dump NAT from these examples but
> from a security perspective they're simply not convincing.  That's just
> my opinion of course, but I encourage you to post them to a computer or
> network security mailing list and see if they hold water.

I'm not trying to get rid of NAT in an existing implementation. I'm trying to
avoid the damage known as NAT from being inflicted on a new protocol.


More information about the ARIN-PPML mailing list