On 2009-11-11 13:20, Roger Marquis wrote:
>>> That is a theoretical harm, or rather an opinion of such. It is not
>>> supported by the widespread use of IPv4 NAT. In fact the ubiquity of
>>> IPv4 NAT is proof that such criticisms are baseless.
>>
>> Er, no, it's proof that application designers have found work-arounds
>> for the lack of address transparency caused by NAT.
>
> "lack of address transparency caused by NAT" is rhetorical.
No, it isn't. Try RFC2101, RFC2775, RFC2993, RFC3027, RFC3234, and RFC4924.
> It would be
> more accurate to point out that application designers fixed protocols that
> were poorly designed in the first place. They do this in order to keep
> state as well as NAT. Since statefulness has to be preserved anyhow there
> would be no net gain in doing away with NAT. With regard to protocols,
> I assume you are not defending the design of SIP/STUN/TURN, ftp, ...
> If not please do explain.
SIP and FTP were certainly designed on the assumption of address
transparency. I'm not interested in defending or attacking those
designs; it was simply the standard design assumption in
the Internet at the time. Of course, STUN/TURN/ICE is a horrible
kludge as a result.
>
> NAT "translates" layers 3 and 4 the same way routers translate MAC
> addresses.
NAT translates layer 3 logical addresses, which were designed
to be globally unique, and kludges various bits of some layer 4
protocols accordingly. Routers don't translate physical layer
addresses; they decouple separate physical links and logical
address regions. In this respect, the OSI model is the best way
to describe things (I never thought I'd feel the need to say
that on an IETF list).
If this is a "work-around" then router vendors have a lot of
> explaining to do. I take it you are not seriously suggesting IPv6 do away
> with MAC layer translation? Can you explain why not?
That question simply doesn't arise. Who's being rhetorical now?
>
>> A common technique is of course to add an application-specific
>> endpoint identifier above whatever method is used to punch a
>> session through the NAT.
>
> What you call "whatever method" firewalls call statefulness. The session
> is "punched" by the state engine. NAT is added to that with little or no
> overhead. I take it you are not seriously suggesting IPv6 do away with
> statefulness? If not then please explain the difference.
Firewall state and NAT state are orthogonal. You can have either
one without the other. Of course, some protocols need to find a way
to punch through pure firewalls, but that's a quite different
problem from punching through NAT. The fact that the two get
confused is itself a source of complexity.
>> There's nothing vague about the complete lack of useful logging
>> of NAT bindings in the D-Link and LinkSys devices I have used in
>> my home
>
> It does not take many CPU cycles in the equipment I typically use (Juniper
> Netscreen, Cisco ASA, Sonicwall, and various http load balancers). Again,
> I assume you are not seriously suggesting IPv6 do away with NAT because
> low-end equipment does not implement sufficient logging for your
> requirements. If not could you explain again how this is factor in your
> anti-NAT position?
I would prefer a world in which millions of consumers do not
suffer random, undiagnosable session failures. I agree that this
is orthogonal to whether certain types of sites are using enterprise
grade NAT for the reasons you and Chris have given. If we do document
NAT66 we need to be very clear about the applicability statement.
Brian
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
