[134542] in North American Network Operators' Group
Re: Problems with removing NAT from a network
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jan 6 20:52:28 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4D2634E7.2060502@matthew.at>
Date: Thu, 6 Jan 2011 17:48:12 -0800
To: matthew@matthew.at
Cc: Nanog Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Doesn't all of this become moot if Skype just develops a dual-stack =
capable client
and servers?
Owen
On Jan 6, 2011, at 1:32 PM, Matthew Kaufman wrote:
> On 1/6/2011 10:07 AM, Cameron Byrne wrote:
>>=20
>> Skype is not defined in an IETF RFC, so saying you need an RFC to =
move
>> forward is bit confusing.
> I don't see a disconnect at all. Skype also uses TCP and UDP, which =
are both subjects of RFCs.
>=20
> That said, it doesn't need to be an RFC... just *a reliable way* of =
discovering the appropriate NAT64 prefix.
>> There are several methods that just work
>> today,
> Of the methods proposed in the survey draft, only one - the one that =
doesn't require the DNS64 spec or operator to make any changes (making =
an AAAA lookup for something you know only has an A record) - works but =
*only if* the mapping scheme is such that it is possible to successfully =
derive a functional prefix and the scheme from the results of that =
query.
>=20
> So in other words, *if* the query results in an AAAA where, by =
inspection, you can guess where you'd need to stuff the IPv4 address =
bits *and* the resulting address causes the "right" NAT64 (if there's =
>1) to be used, then you're set.
>> I am all for standards, but a closed platforms generally find ways to
>> progress without or in spite of standards. Skype is a closed
>> platform.
> No question. And for all you know we might be working on other ways =
around this problem, but none of them as elegant as a defined =
specification for how to discover the presence of a NAT64 and the =
mapping.
>>=20
>>> There's lots of other apps that don't work. Skype is just the =
squeaky wheel
>>> because it is so popular.
>>>=20
>> Please make a list and let us know. Otherwise, this is just hand
>> waving like the IPv4 literals sites.
> I'll start with "peer to peer connectivity using RTMFP in Flash =
Player" and "BitTorrent". Both Flash Player and BitTorrent are fairly =
popular on desktop platforms.
>=20
> I'm sure there's more.
>=20
>=20
>> My advice to Skype is to come up with a solution to work for =
IPv6-only
>> clients. That is my advice to all apps and all content. IPv6-only
>> clients are an obvious reality in an IPv4 exhausted world.
> That's not the problem... the problem is reaching the existing base of =
IPv4 clients from those IPv6-only clients without making Skype relay all =
the traffic via servers somewhere, as I'm sure you know.
>=20
>> You cannot seriously come to a network operators support mailing list
>> and say that the network guys have to keep investing in network =
tweaks
>> while you wait for a standards body to solve a problem for your =
closed
>> non-standard applications.
> I've been on this list since approximately the time it was formed, so =
I'm not coming here to ask for something. Just pointing out what will =
break.
>=20
>> I also assure you, many mobile operators are pursuing this NAT64 path
>> for the same reason I am.
> Randy Bush would encourage his competitors to do just as you've done, =
I'm sure.
>=20
> Matthew Kaufman
>=20
