Problems with removing NAT from a network

Sun Jan 9 14:42:16 UTC 2011

On Sat, Jan 8, 2011 at 10:55 PM, Matthew Kaufman <matthew at matthew.at> wrote:
> On 1/8/2011 3:22 PM, Frank Bulk wrote:
>>
>> Relay nodes are always protecting themselves by rate-limiting, aren't
>> they?
>
> Yes.
>>
>> 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 instance.)
>

1.  The companies that have selected NAT64 as a tool for rolling out
IPv6 to address the IPv4 exhaustion business risk are aware of the
various application trade offs.  They select NAT64 because it makes
business sense to aggressively go after IPv6 as the end-state and not
provide patches and work-arounds in their network to make dual-stack
work, which is not an end-state, it is a transition mechanism on the
path to ipv6.  Also, as i mentioned for mobile, dual-stack is MUCH
more expensive.  And ipv6-only works for the vast majority of my user
and my traffic.

2.  You can pass this FUD around about people leaving networks so that
skype and bittorrent work.  Last time i checked, many mobile network
operators and handsets only begrudgingly supported skype and bittorent
if at all.  In fact, many networks spend considerable time and money
to stop them.  I also know that Skype has some mobile partners.  I am
not here to say if this is right or wrong, but i do not expect network
providers to alter their ipv6 strategy of business decisions to
accommodate Skype and Bittorrent.  These applications have shown
amazing resiliency over the years to bust through firewalls and NATs,
and i am really amazed at how much opposition Skype is providing to
the IPv6 transition.  I imagine Skype would have a better hand if
Skype was IPv6 enabled a long time ago and pushing dual-stack and
waiting on the carriers, but Skype is IPv4-only just like all the rest
of the slow moving world.  If dual-stack had worked, we would not be
here talking about NAT64. But, dual-stack did not work.  We are out of
IPv4 and the network still has to grow, hence IPv6-only + NAT64.  And
again, dual-stack is much more expensive in mobile networks than
single stack so it won't happen with the Ipv4 side being endless
duplication of RFC 1918 and bogon space.

3.  I am just here to create awareness of this technology that the
IETF as the protocol standardizer and the 3GPP as the mobile
architecture standardizer have accepted and are moving forward.  I
want all applications to work with IPv6 and NAT64.  In every email i
have sent on this topic and off-list to Matthew, i have made the call
to action to support ipv6 and to work together.   From the network
side, i am willing partner.  But, not supporting IPv6 is not an option
in my mind. That is where Skype stands today.  IPv4 is really not a
strategic path for any network, especially a mobile network that has a
large and growing edge.   There are several ways to work through
making NAT64 work, as Matthew has acknowledge, and even hinted at
having a better proprietary way.  I am open to new ways and new
partnerships to make this work.  When you are ready to talk about
moving forward, i am all ears.  Until then, you can keep posturing
while the clock ticks on committed  deployments.  If you know it's
coming and don't have a solution, if you strategically choose to play
that game of chicken, thats fine too, it's a calculated risk that my
business has made.

Cameron

> Matthew Kaufman
>
>
>