-----Original Message----- From: Geoff Huston [mailto:gih@apnic.net] Sent: Wednesday, September 07, 2011 10:27 PM To: Leigh Porter Cc: nanog@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@cluenet.de] Sent: 07 September 2011 17:38 To: nanog@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