Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

[Ca By <[e-mail]>]

On Friday, April 3, 2015, James Woodyatt <[e-mail]> wrote:

> On Fri, Apr 3, 2015 at 4:23 PM, Ca By <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> wrote:
>
>>
>> The fundamental issue is that you have no control over these on the
>> internet, ipv4literals | tmoipv6
>> <https://sites.google.com/site/tmoipv6/ipv4literals>
>>
>
> That list is badly out of date.
>
>
It is only a few weeks old.


> (For grins, I looked at some entries on the list. The first one I looked
> at was at nodejs.org which has an IPv4 literal in its pre-formatted
> example code on the first page. Which I would note is example code that
> WOULD NOT BREAK in the absence of a CLAT. You'd have to remove the IPv4
> stack completely from the host to break it. The second one I looked at was
> the one at the top of the list. There is one IPv4 literal in the page. It's
> assigned to an unused Javascript variable. The third one I looked at was
> the second one on the list, which appears to have moved entirely since this
> list was created. Please update the list.)
>
> But put that aside for now. There aren't many people in this discussion
> who DO have control over the entries in that list, but Internet service
> operators certainly have more influence over them than anyone outside of
> the actual site owners. Tremble at the risk entailed in using your
> influence if you must, but don't complain that you have no influence at
> all. You can choose to get them to stop using IPv4 literals by taking away
> the free lunch. Or you can choose to let them run wild without consequence.
> Just start moving select populations of CLAT-less users to IPv6-only+NAT64
> networks. They'll figure it out pretty quickly.
>
>

This is 0% executive leaders from the customer service, network operations,
marketing, or regulatory affairs would approve such a move. Seriously, the
only viable path for that is if the government required it.


> You, and i, also have no control over what is implemented in signalling
>> channels. Your sockets my be AF agnostic, but that does not stop the data
>> structures for peer to peer apps being ipv4 addesses like Bittorent or
>> Skype use. [...] In fact, Skype works on iOS today on IPv6-only.... why?
>> Because they built a CLAT into the App.
>>
>
> Ah yes, those pesky IPv4-only P2P applications. Especially the ones with
> DHT keys containing IPv4 addresses. Which can't be easily adapted to handle
> IPv6 address too. A scourge on the Internet those apps are. Exactly how
> many are we talking about? Besides Skype and BitTorrent, I mean. Oh wait.
> They're already IPv6-capable. So, who *are* we talking about today?
>
>


It is a horrible idea of ask all the app vendors to invent their of unique
>> CLAT.  Because they have already reacted to the threat of IPv6-only... and
>> this is what they do.
>>
>
> Well, we aren't asking *all* the app vendors to do that, are we? Just the
> ones that are so amazingly clever they can't do the simple straightforward
> obvious thing, which is to change their protocols to not use IPv4 literal
> addresses.
>
> I simply don't see the downside of telling whatever remaining IPv4-only
> P2P app vendors are out there that they have to implement their own UNSAF
> mechanism over IPv6 rather than rely on the system to do it for them. Who
> knows, for many of them, it might not be that hard to just upgrade their
> protocols to support the dual-stack IPv4/IPv6 public Internet. That it was
> hard for Skype, but not very hard at all for FaceTime, seems like a
> relevant point to keep in mind.
>
>
>
Hard  or not, FaceTime requires IPv4 the last time I checked.

-- 
> james woodyatt <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>>
> Nest Labs, Communications Engineering
>