-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, September 13, 2011 9:43 PM To: Dan Wing Cc: 'Leigh Porter'; 'David Israel'; nanog@nanog.org Subject: Re: NAT444 or ?
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.
I disagree it reached that conclusion. That may have been its intent.
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.
Yes, your statement is completely accurate. I agree that IPv4 address sharing causes additional problems (which encompasses all forms of IPv4 address sharing), and CGN causes additional problems.
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.
Yeah, you are probably of about 1000 or maybe 3000 people in the world that do that. Seems to be a minority.
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.
Neither am I. But if major content providers cannot provide AAAA on their properties, and if ISPs and CPE vendors do not make IPv6 available and working, and if web browsers don't adopt faster fallback to IPv4 when IPv6 is borked .... We will all be behind NATs. -d