[134566] in North American Network Operators' Group
Re: Problems with removing NAT from a network
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Jan 7 04:07:20 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4ECA283F-856C-4813-A4E8-073C136613C5@queuefull.net>
Date: Fri, 7 Jan 2011 01:02:50 -0800
To: Benson Schliesser <bensons@queuefull.net>
Cc: 'Nanog Operators' Group' <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 6, 2011, at 11:49 PM, Benson Schliesser wrote:
>=20
> On Jan 7, 2011, at 12:39 AM, Matthew Kaufman wrote:
>=20
>> On 1/6/2011 9:28 PM, Dan Wing wrote:
>>>=20
>>> 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
>>>=20
>> 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.
>>=20
>> That's the case we're discussing here.
>>=20
>> 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.
>=20
> 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.
>=20
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.
>=20
On this, at least we agree.
Owen
