NAT444 or ?

Wed Sep 14 04:42:41 UTC 2011

>> 
>> Good point, but aside from these scaling issues which I expect can be
>> resolved to a point, the more serious issue, I think, is applications
>> that just do not work with double NAT. Now, I have not conducted any
>> serious research into this, but it seems that draft-donley-nat444-
>> impacts does appear to have highlight issues that may have been down to
>> implementation.
> 
> Draft-donley-nat444-impacts conflates bandwidth constraints with CGN
> with in-home NAT.  Until those are separated and then analyzed carefully,
> it is harmful to draw conclusions such as "NAT444 bad; NAT44 good".
> 

Continuing to make this claim does not make it any more true.

Draft-donley took networks and measured their real-world functionality
without NAT444, then, added NAT444 and repeated the same tests.
Regardless of the underlying issue(s), the addition of NAT444 to the
mix resulted in the forms of service degradation enumerated in the draft.

Further, I would not ever say "NAT444 bad; NAT44 good". I would say,
rather, "NAT44 bad, NAT444 worse". I think that's a pretty safe and non-
harmful thing to say.

>> Other simple tricks such as ensuring that your own internal services
>> such as DNS are available without traversing NAT also help.
> 
> Yep.  But some users want to use other DNS servers for performance
> (e.g., Google's or OpenDNS servers, especially considering they
> could point the user at a 'better' (closer) CDN based on Client
> IP), to avoid ISP DNS hijacking, or for content control (e.g.,
> "parental control" of DNS hostnames).  That traffic will, necessarily,
> traverse the CGN.  To avoid users burning through their UDP port 
> allocation for those DNS queries it is useful for the CGN to 
> have short timeouts for port 53.
> 
If the user chooses to use a DNS server on the other side of a NAT, then,
they are choosing to inflict whatever damage upon themselves. I'm not
saying that short UDP/53 timeouts are a bad idea, but, I am saying that
the more stuff you funnel through an LSN at the carrier, the more stuff
you will see break. This would lead me to want to avoid funneling anything
through said NAT which I could avoid. Then again, I run my own
authoritative and recursive nameservers in my home and don't use
any NAT at all, so, perhaps my perspective is different from others.

>> Certainly some more work can be done in this area, but I fear that the
>> only way a real idea as to how much NAT444 really doe break things will
>> be operational experience.
> 
> Yep.  (Same as everything else.)
> 

I'm sure that will happen soon enough. I, for one, am not looking forward
to the experience.

Owen