Not really. Imagine the case where you're on IPv6 and you can only reach IPv4 via a NAT64, and there's no progress made on the detection problem. And your family member is on a Skype-enabled TV plugged into an IPv4-only ISP.
Now you can't get a direct media path between you, even though their ISP is giving them IPv4 and your ISP is *claiming* you can "still reach the IPv4 Internet".
Skype can still make this work by relaying, but in order to protect the relay machine's bandwidth it will rate-limit the traffic, and so your A/V experience will suffer. And that's assuming there's enough dual-stacked relays... if there aren't, it won't be possible to find a relay that they can reach over IPv4 and you can reach over IPv6 that has available bandwidth.
Without revealing too much about the architecture, I can tell you that it would need to be a significant fraction of the supernodes (due to how node-supernode mapping works in these types of P2P systems), the relay nodes (not mentioned) *and* the login servers. Not all of which are deployed and controlled by Skype, of course, as recent press about the most recent outage has reiterated for those who didn't know.
From: Matthew Kaufman [mailto:matthew@matthew.at]
Sent: Thursday, January 06, 2011 6:55 PM
To: Owen DeLong
Cc: Nanog Operators' Group
Subject: Re: Problems with removing NAT from a network
> Doesn't all of this become moot if Skype just develops a dual-stack
capable client
> and servers?
>
Not really. Imagine the case where you're on IPv6 and you can only
reach
IPv4 via a NAT64, and there's no progress made on the detection
problem.
And your family member is on a Skype-enabled TV plugged into an
IPv4-only ISP.
Now you can't get a direct media path between you, even though their
ISP
is giving them IPv4 and your ISP is *claiming* you can "still reach the
IPv4 Internet".
If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64.
That's the case we're discussing here.
It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. Even the protocol described in the referenced document, Jingle (as it essentially uses ICE) fails. The candidate IPv4 addresses for the end that's on the IPv4 Internet (local and STUN-derived) that are delivered over Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to reach the IPv4 Internet because it has no IPv4 sockets available to it and even if it knew that NAT64 existed (which would take a modification to the Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 address to use to reach the IPv4 host because there's no discovery mechanism. If you want we can take this back to the BEHAVE list now.
There has been discussions on v6ops mailinglist about BIH (Bump In Host) for mobile applications, so that one could create a client on the machine behind NAT64 and make it work work with programs that use v4 literals (or have no v6 support at all).
It though seems there is considerable resistance within the IETF community against such solutions as (I've been told) history has shown there to be a lot of problems with this kind of double translation.
Therefore the IETF seems to lean towards tunneling of IPv4 over IPv6 to give such a host literal IPv4 connextivity (could be called 4RD) instead of doing translation.
For mobile applications, single stack on the access is to only realistic method in the next few years, therefore this needs to be solved somehow. 3GPP doesn't like tunnels though (since they already do tunneling), so right now there isn't really broad agreement on how to solve this.
Personally I think we need some kind of transitioning mechanism to handle v4 only applications and v4 literals in the forseeable future, just like we needed trumped winsock in the 90ties, we're going to need full v4 connectivity for Windows XP (applications + dns transport) over v6only access.
To paraphrase what you're saying: stuff that embeds and passes around IPv4 addresses will break. I'm sorry to say this, but that's just reality. Embedded IP addresses has always been a Bad Idea (tm) in development and operations, and I don't think P2P protocols get a pass - building your own discovery and topology mechanisms don't insulate you from having to use the underlying network.
The best chance anybody has, is to build dual-stack support and start using DNS names rather than IP numbers. Oh, and expect IPv4 to start breaking in the near future. We're trying to make IPv4 work long enough to survive the transition, but it's not a good bet for new protocols.
If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 "solution") on the IPv4 Internet through said NAT64.
That's the case we're discussing here.
It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. Even the protocol described in the referenced document, Jingle (as it essentially uses ICE) fails. The candidate IPv4 addresses for the end that's on the IPv4 Internet (local and STUN-derived) that are delivered over Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to reach the IPv4 Internet because it has no IPv4 sockets available to it and even if it knew that NAT64 existed (which would take a modification to the Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 address to use to reach the IPv4 host because there's no discovery mechanism. If you want we can take this back to the BEHAVE list now.
To paraphrase what you're saying: stuff that embeds and passes around IPv4 addresses will break. I'm sorry to say this, but that's just reality. Embedded IP addresses has always been a Bad Idea (tm) in development and operations, and I don't think P2P protocols get a pass - building your own discovery and topology mechanisms don't insulate you from having to use the underlying network.
No, it hasn't always been a Bad Idea. It has been an idea fraught with peril since the deployment of overloaded NAT in IPv4.
Fortunately, overloaded NAT will hopefully be a thing of the past in IPv6 and we may get a chance to return to a more functional
end-to-end model of networking again.
The best chance anybody has, is to build dual-stack support and start using DNS names rather than IP numbers. Oh, and expect IPv4 to start breaking in the near future. We're trying to make IPv4 work long enough to survive the transition, but it's not a good bet for new protocols.
Embedding into apps isn't the same as embedding into protocol packets. While NAT and stateful firewalls do tend to break with embedded addresses that they don't know to check for, it's still not a bad idea.
I was fixing to complain that the IPv6 designers didn't take the chance to add the embedding to the Packet headers, when it occurs to me, they made the headers nice and extensible.
It also baffles me as to why applications such as skype dealing with NAT64 can't use the compatibility addressing to start communicating with v4 hosts from a v6 only NIC. I thought this was already a fixed problem not requiring DNS to deal with. It's not like NAT46 (anyone actually publish such a hideous protocol?), which requires really messy state tables bidirectionally for everything and DNS rewrites.
>> From: Matthew Kaufman [mailto:matthew@matthew.at]
>> Not really. Imagine the case where you're on IPv6 and you can only
>> reach
>> IPv4 via a NAT64, and there's no progress made on the detection
>> problem.
>> And your family member is on a Skype-enabled TV plugged into an
>> IPv4-only ISP.
>>
>> Now you can't get a direct media path between you, even though their
>> ISP
>> is giving them IPv4 and your ISP is *claiming* you can "still reach
the
>> IPv4 Internet".
>>
>> Skype can still make this work by relaying,
> Skype could make it work with direct UDP packets in about 92% of
> cases, per Google's published direct-to-direct statistic at
> http://code.google.com/apis/talk/libjingle/important_concepts.html
>
If one end is behind a NAT64 and there is no mechanism for discovering
the NAT64's IPv6 interface prefix and mapping algorithm (and at present
there is not), there is no way to send IPv6 IP packets from the
IPv6-only host to IPv4 literal addresses (that is to say, addresses
learned via a mechanism other than DNS responses synthesized by the
DNS64 part of the NAT64 "solution") on the IPv4 Internet through said
NAT64.
That's the case we're discussing here.
There are a bunch of ideas for how to accomplish that. Several of
the ideas don't require any support by the network infrastructure,
draft-korhonen-behave-nat64-learn-analysis.
It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal,
etc. Even the protocol described in the referenced document, Jingle (as
it essentially uses ICE) fails. The candidate IPv4 addresses for the
end
that's on the IPv4 Internet (local and STUN-derived) that are delivered
over Jingle's XMPP path cannot be used by the host that is on IPv6 +
NAT64 to reach the IPv4 Internet because it has no IPv4 sockets
available to it and even if it knew that NAT64 existed (which would
take
a modification to the Jingle-based apps) and opened an IPv6 socket it
wouldn't know what IPv6 address to use to reach the IPv4 host because
there's no discovery mechanism. If you want we can take this back to
the BEHAVE list now.
Compatibility addresses don't work on the wire. They're not supposed to. It's a huge problem if they do.
Compatibility addresses allow you to write an IPv6 application, run it on a dual-stacked host and talk to
the IPv4 and IPv6 remote systems as if all of them are IPv6 hosts. The IPv4 hosts appear to come
from the IPv6 range ::ffff:ip:v4 which is often presented to the user as ::ffff:i.p.v.4 .
In the upcoming years, we will have no IPv6 in some places and badly
performing IPv4 (CGN, etc.) with working IPv6 in others.
If I was Skype I would make really sure that all my relay nodes and
login servers have IPv6 with enough bandwidth or can easily upgrade the
bandwidth where neede. And make sure atleast IPv6-client and
IPv6-servers communication works everywhere where there is IPv6.
Atleast get your servers and network ready with IPv6. Tell your
suppliers that if they don't have IPv6 by 'deadline' (you decide) you
will (have to) go somewhere else.
Because if you still have to deploy, test and fix IPv6 to your servers
when it turns out the transition workarounds you have created in
software don't work as well as you hoped then you will have a real
problem on your hands.
For your customers it is really easy. When Skype does not work, people
will jump ship where they can and maybe use Google Talk or whatever. I
hear they also have a similair service like SkypeOut ? Judging by the
amount of effort Google put in to making sure their network supports
IPv6, I wouldn't be surprised if Google Talk 'just works'. They might
even start including it with Google TV.
I suggest making sure you include both IPv4 and IPv6 addresses in your
protocol, maybe it needs to be extended. So that the client at the other
end can choose what IP-version to use. Or can try both. Maybe the
login-server can help to decide for the client. But those login servers
will need to have good IPv6 connectivity to be able to do so.
If you don't do these 2 things (maybe you already have I don't know) you
might find that your business will suffer.
I'm sorry if it sounds a bit like fear mongering, but to me it sounds
like common sense that if a business is not prepared when the
environment that business operates in changes and that business does not
adapt to the changes in time that business might suffer.
Relay nodes are always protecting themselves by rate-limiting, aren't they?
And isn't most media traffic relayed? 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.
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.
Maybe HE would volunteer to host some Skype servers at their various POPS
for this purpose.
Skype has to start somewhere. While the v6-only population is still very
small, why not dual-stack the clients now with a heavily weighted preference
towards v4, track and understand the volume and capabilities of v6, and
slowly de-preference v4 over time?
While a rather inelegant solution, it just popped into my head that one could do an AAAA query for a known-value A record (i.e., under skype.com), and based on a response (if any), replace the known IP value with the IP which with one wants to connect.
A little weird, but it's a thought.
In the upcoming years, we will have no IPv6 in some places and badly
performing IPv4 (CGN, etc.) with working IPv6 in others.
Right. So we're discussing just how "badly performing" the IPv4 can be and still be acceptable as "access to the IPv4 Internet for your customers".
I am arguing that CGN (NAT44 to get additional IPv4 to dual-stack) doesn't break nearly as much as NAT64/DNS64 does, and that in fact NAT64/DNS64 breaks *so much* that you probably can't/shouldn't sell it to your customers as "access to the IPv4 Internet".
Note that for a *very* long time... much longer than there will be new IPv4 addresses available... there will be a whole lot of places that have good IPv4 and no IPv6. (As you note above)
If I was Skype I would make really sure that all my relay nodes and
login servers have IPv6 with enough bandwidth or can easily upgrade the
bandwidth where neede. And make sure atleast IPv6-client and
IPv6-servers communication works everywhere where there is IPv6.
Clearly that would be needed to serve the IPv6-only users well.
For your customers it is really easy. When Skype does not work, people
will jump ship where they can and maybe use Google Talk or whatever.
Ah. But you're taking the bet that when Skype does not work on *your* network that provides IPv4 access via NAT64 people won't "jump ship" to a provider that uses CGN or even has enough native IPv4 addresses left around.
I suggest making sure you include both IPv4 and IPv6 addresses in your
protocol, maybe it needs to be extended. So that the client at the other
end can choose what IP-version to use. Or can try both. Maybe the
login-server can help to decide for the client. But those login servers
will need to have good IPv6 connectivity to be able to do so.
But none of that solves the problem of talking from an IPv6 client that has broken IPv4 access (NAT64) to a an IPv4 client that has no IPv6 access.
I'm sorry if it sounds a bit like fear mongering, but to me it sounds
like common sense that if a business is not prepared when the
environment that business operates in changes and that business does not
adapt to the changes in time that business might suffer.
But that's true of ISPs when they choose how to deal with the lack of additional IPv4 space but continued customer demand to reach the IPv4 Internet, too, isn't it?
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.)