Problems with removing NAT from a network

Matthew Kaufman matthew at
Sun Jan 9 00:55:02 CST 2011

On 1/8/2011 3:22 PM, Frank Bulk wrote:
> Relay nodes are always protecting themselves by rate-limiting, aren't they?
> And isn't most media traffic relayed?
No, not at all. Almost all media traffic goes directly end-to-end by 
using really good NAT traversal.
>   I'm not seeing how the NAT64 scenario
> would *dramatically* increase Skype's global relay traffic.  NAT64 would
> currently be a very small percentage of all Skype traffic.
The relay issue isn't about that. If you can't discover the NAT64 and 
you can't discover the mapping algorithm, then you can't use IPv4 
literal addresses. If you can and the application is changed to use the 
discovery mechanism, then the traffic flows through the NAT64 and relay 
nodes aren't an issue.

But if you can't then the only way for a future IPv6-enabled Skype 
client that has IPv6 + NAT64 to (not) reach the IPv4 Internet can talk 
to another Skype client that has IPv4 only would be to go through the 
relay node.

That means that people who are on ISPs that use native IPv4 dual-stack, 
and people who are on ISPs that use CGN NAT44 to dual-stack both get the 
direct end-to-end experience when calling IPv4-only clients... but 
people who are on ISPs that use NAT64 instead of dual-stack end up 
having to go through (rate limited) relays to call IPv4-only clients.

That means they'd have an excellent reason to choose an ISP that uses a 
different technology. Which they'll need to do to make their BitTorrent 
and everything else that uses IPv4 literals work anyway.

> We can always find examples of where things will break with v6.  While the
> v6-only world is still very small, let's *start* somewhere, where
> intelligent clients like Skype can always "fall back" to v4.  Lots of time
> to figure out the corner cases.
The point is that NAT64 creates a huge additional set of corner cases 
(all of the cases where IPv4 literal addresses are transported by 
anything other than DNS lookups) that none of the other transition 
choices do. (NAT64 has all the problems of CGN *plus* this issue, for 

Matthew Kaufman

More information about the NANOG mailing list