NAT444 or ?

Thu Sep 8 16:44:30 UTC 2011

> -----Original Message-----
> From: Geoff Huston [mailto:gih at apnic.net]
> Sent: Wednesday, September 07, 2011 10:27 PM
> To: Leigh Porter
> Cc: nanog at nanog.org list; Daniel Roesen
> Subject: Re: NAT444 or ?
> 
> 
> On 08/09/2011, at 2:41 AM, Leigh Porter wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Daniel Roesen [mailto:dr at cluenet.de]
> >> Sent: 07 September 2011 17:38
> >> To: nanog at nanog.org
> >> Subject: Re: NAT444 or ?
> >>
> >> On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote:
> >>>> I'm going to have to deploy NAT444 with dual-stack real soon now.
> >>>
> >>> you may want to review the presentations from last week's apnic
> >> meeting
> >>> in busan.  real mesurements.  sufficiently scary that people who
> were
> >>> heavily pushing nat444 for the last two years suddenly started to
> say
> >>> "it was not me who pushed nat444, it was him!"  as if none of us
> had
> >> a
> >>> memory.
> >>
> >> Hm, I fail to find relevant slides discussing that. Could you please
> >> point us to those?
> >>
> >> I'm looking at http://meetings.apnic.net/32
> >
> > There is a lot in the IPv6 plenary sessions:
> >
> > http://meetings.apnic.net/32/program/ipv6
> >
> > This is what I am looking at right now. Randy makes some good
> comments in those sessions. I have not found anything yet, but I am
> only on session 3, pertaining specifically to issues around NAT444.
> 
> It may not be what Randy was referring to above, but as part of that
> program at APNIC32 I reported on the failure rate I am measuring for
> Teredo. I'm not sure its all in the slides I was using, but what I was
> trying to say was that STUN is simply terrible at reliably negotiating
> a NAT.

Teredo does not use STUN; Teredo was implemented before STUN was fully
spec'd and does its own thing.

Teredo tries to determine if the type of NAT it is behind ("cone", 
"symmetric", etc.)  Determining the type of NAT has been found to 
be difficult, and nearly impossible (*) and removed from the current
RFC for STUN (**).  I suspect most of Teredo's failures are related 
to this procedure not working effectively.  A CGN can't improve that.

(*) http://tools.ietf.org/html/rfc5780#section-1
(**) http://tools.ietf.org/html/rfc5389#section-2

> I was then wondering what pixie dust CGNs were going to use that
> would have any impact on the ~50% connection failure rate I'm observing
> in Teredo.  And if there is no such thing as pixie dust (damn!) I was
> then wondering if NATs are effectively unuseable if you want anything
> fancier than 1:1 TCP connections (like multi-user games, for example).
> After all, a 50% connection failure rate for STUN is hardly encouraging
> news for a CGN deployer if your basic objective is not to annoy your
> customers.

If the CGN has both Endpoint-Independent Filtering (***) behavior
and Endpoint-Independent Mapping (****) behavior, the CGN won't make
Teredo worse -- Teredo will be as bad as today, caused by the home
user's own pretty NAT.  With that behavior, it also won't make 
applications that use STUN or ICE worse, or applications that use 
STUN-like or ICE-like techniques such as Skype.

(***) endpoint-independent filtering: means it doesn't filter incoming
packets after a mapping is created.  See
http://tools.ietf.org/html/rfc4787#section-5 for canonical definition.

(****) Endpoint-Independent Mapping:  means when the internal host sends a
packet with the same source port, to any destination, the same public port
is mapped.   See http://tools.ietf.org/html/rfc4787#section-4.1 for
canonical definition

-d