RE: NAT444 or ?

["Dan Wing" <dwing () cisco com>]

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