[LAC-TF] Actualizacion (ERA: Re: Tema de IPv6 en Apple (ERA: Re: [v6ops] Apple and IPv6, a few clarifications (fwd)))

Sat Jul 11 19:38:38 BRT 2015

Buen Dia,

Continuando con el tema cito lo mas reciente comentado por David Schinazi, 
de Apple. (Date: Thu, 9 Jul 2015 17:00:40 -0500)

"Today Apple released the first public seeds of iOS 9 and OS X El 
Capitan.

These seeds (and the third developer seeds released yesterday) include an 
improved version of Happy Eyeballs.

Based on our testing, this makes our Happy Eyeballs implementation go from 
roughly 50/50 IPv4/IPv6 in iOS 8 and Yosemite to ~99% IPv6 in iOS 9 and El 
Capitan betas... ""

Mas info. y correo completo de David en la lista de v6ops:

  https://mailarchive.ietf.org/arch/search/?qdr=m&email_list=v6ops&so=frm
  (Ordenando los mensajes por nombre y ubicando el nom. de David.

SALUDOS
_______
Azael
UNAM
Mexico
____________________________
Mensaje enviado sin acentos

On Thu, 2 Jul 2015, Azael Fernandez Alcantara wrote:

> Buen Dia,
>
> Para empezar me gustaria compartir el tema del soporte de IPv6 en Apple, que 
> ha estado comentado ampliamente en el GT de v6ops de la IETF.
>
> Pueden encontrar los mensajes de David Schinazi, de Apple, que ha enviado 3 
> correos, para aclarar el soporte ( al final de este correo 2 de ellos).
> O los pueden encontrar en la liga:
>
> https://mailarchive.ietf.org/arch/search/?qdr=m&email_list=v6ops&so=frm 
> (Ordenando los mensajes por nombre y ubicando el nom. de David.
>
> Un breve resumen que he elaborado es:
>
> *************************************************************************
>
> - Hotspot personal en iOS:
> 			iPhone dual-stack  => Hotspot dual-stack
> 		    IPv6-only Broadcast  <= Si  lo hace la red celular
> 			Multiples Hotspots  al mismo tiempo
>
> No traduccion (hasta el momento)
> 	IPv4-only device -> IPv6-only iOS handset
>
> - Internet Sharing en la Mac:   NO soporta IPv6
>
> "would be nice to support IPv6"
>
> - Internet Sharing en la Mac - NAT64 testing mode:
>
> "No IPv6 connectivity to the global IPv6 internet"
>
> "advertises addresses from 2001::/64 instead of ULAs to simulate real IPv6 
> connectivity"
>
>
> - "Making IPv4 literals work on NAT64 networks when using high-level APIs:"
>
> NO soporte  de 464XLAT y "under-the-sockets bump-in-API"
> 		".. decided that it was not the best course of action."
>
> - Happy Eyeballs    En desarrollo solucion de problemas.
>
> - iOS y cellular carrier networks
>
> Cuando roaming =>  switcheo entre IPv4 e IPv6
>
> - VPN
>
> IKEv2 soporta IPv6, otros protocolos no garantizados
>
>
> *******************************************************************************
>
> Que experiencias y comentarios podrian compartir al respecto ?
>
> Como usuarios finales y como administradores de red.
>
>
> SALUDOS
> _______
> Azael
> UNAM
> Mexico
> ____________________________
> Mensaje enviado sin acentos
>
>
> ---------- Forwarded message ----------
> Date: Wed, 24 Jun 2015 02:15:44 -0500
> From: David Schinazi <dschinazi at apple.com>
> To: v6ops at ietf.org
> Cc: Vividh Siddha <vividh at apple.com>
> Subject: Re: [v6ops] Apple and IPv6, a few clarifications
>
> Hi again,
>
> First off, thanks everyone for the feedback and advice!
> Here's an attempt at answering the questions that arose since my last post.
>
> *) Personal hotspot on iOS
> Currently the hotspot shares whatever address families it gets from the 
> cellular network.
> The current implementation broadcasts an IPv6-only network if the cellular 
> network is of that type,
> but I could imagine carriers bringing up IPv4 specifically when using this 
> feature. Our custom version
> of prefix sharing is described in more detail here:
> https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet6/nd6_prproxy.c 
> <https://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/netinet6/nd6_prproxy.c>
> It supports creating multiple hotspots at the same time, such as Wi-FI and 
> Bluetooth and bridges them.
>
> *) iOS and cellular carrier networks
> I do not know if or when specific carriers plan to change their IPv6 
> policies. That said, we do believe
> there is a growing trend towards IPv6. When roaming between carriers, your 
> device will get new
> addresses and could possibly switch between address families.
>
> *) VPN
> Our implementation of IKEv2, which is our current recommended VPN protocol, 
> supports IPv6 on both
> the inside and outside of the tunnel. Other protocols are currently not 
> guaranteed to be fully compatible.
>
> *) Internet Sharing on the Mac
> We agree that it would be nice to support IPv6, but the risk/reward tradeoff 
> isn't necessarily there yet.
>
> *) Internet Sharing on the Mac - NAT64 testing mode
> To reset expectations on this feature, it targets developers of networked 
> apps that are not knowledgeable
> in IPv6, most likely not anyone on this list. If you're writing your own 
> sockets code that works on dual-stack
> and have a dual-stacked server, you probably know what you're doing already. 
> The goal is really not
> performance optimization, simply checking that your app will manage to 
> connect to your server at all.
> Realistically, today any service accessible by apps over IPv6 is also 
> available over IPv4. Debugging path
> MTU issues is currently out of scope of this test network. The App Store IPv6 
> compatibility requirement will
> not reject an app solely based on tests using the NAT64 test network. The 
> NAT64+DNS64 on the Mac will
> currently only query for A records and return synthesized AAAA records to its 
> clients, it effectively ignores any
> AAAA records it receives from the wide area. We're looking into improving 
> this feature, we agree that adding
> real IPv6 connectivity and using a different prefix would be better.
>
> *) Happy Eyeballs
> Thanks to everyone for the advice on this topic, we're looking into the best 
> compromise between providing
> our customers with good response times in the short term and helping them in 
> the long term by helping the
> deployment of IPv6. An issue with RFC 6555 is that it was designed in a 
> mindset where DNS resolution is
> provided by synchronous APIs such as getaddrinfo. In practice, your AAAA and 
> A records do not come back
> at the same time and if you receive the A record first, every millisecond you 
> wait before sending out a SYN is
> an IPv6 tax you're levying on your users. This being helpful in the long 
> term, there must be a sweet spot. To
> clarify our use of the RTT to prioritize addresses, we use historical RTT 
> measurements of all TCP packets on
> that route. If and when we release an updated implementation, I will update 
> this list.
>
> *) 464XLAT
> We've considered using this technology and decided that it was not the best 
> course of action. This doesn't
> mean we will never consider it and we're definitely interested in discussing 
> pros and cons but in my
> humble (personal) opinion, calling us names to "get our attention" is not 
> likely to convince us that 464XLAT
> is the One True Path to IPv6 deployment.
>
> As mentioned in my last message, all these details only reflect the current 
> betas and can change in the future.
>
> Thanks,
> David
>
>
>> On Jun 19, 2015, at 14:46, David Schinazi <dschinazi at apple.com> wrote:
>> 
>> Hi everyone,
>> 
>> I'd like to clarify a few points about Apple's IPv6 announcements during 
>> WWDC 2015.
>> The video (streaming with Safari or download with all browsers) and slides 
>> of that talk
>> are available at: https://developer.apple.com/videos/wwdc/2015/?id=719 
>> <https://developer.apple.com/videos/wwdc/2015/?id=719>
>> 
>> *) Personal hotspot on iOS
>> If your iPhone has dual-stack connectivity on its cellular network, the 
>> hotspot it creates
>> will be dual-stack as well. The phone will share its prefix with Wi-Fi 
>> clients.
>> 
>> *) Internet Sharing on the Mac
>> Today, regular internet sharing (from your ethernet to Wi-Fi for example) 
>> does not
>> support IPv6 because of the limited use cases, and the lack of demand for 
>> it.
>> 
>> *) Internet Sharing on the Mac - NAT64 testing mode
>> The NAT64 test mode was designed to help developers ensure that their app 
>> can still
>> function with IPv6-only NAT64+DNS64 connectivity and communicate with their 
>> IPv4
>> server, even if the developer does not have access to the IPv6 internet. 
>> That NAT64
>> network does not have IPv6 connectivity to the global IPv6 internet. As 
>> such, the current
>> version advertises addresses from 2001::/64 instead of ULAs to simulate 
>> real IPv6
>> connectivity, as all IPv6 packets are terminated at the NAT64 server on the 
>> Mac.
>> This implementation detail could change in the future.
>> 
>> *) Making IPv4 literals work on NAT64 networks when using high-level APIs
>> Starting with this year's versions, if you use NSURLSession to connect to 
>> an IPv4
>> literal on an IPv6-only NAT64-DNS64 network, the API will bump in a IPv6 
>> literal
>> synthesized using RFC 7050. Note that this will not happen when using 
>> sockets
>> directly. We do not support under-the-sockets bump-in-API (RFC 3338) and we
>> do not support 464XLAT.
>> 
>> *) Happy Eyeballs
>> We've heard feedback on our Happy Eyeballs implementation and are 
>> investigating
>> this topic.
>> 
>> Note that this reflects how these technologies work in the current versions 
>> of the
>> 2015 betas, many of these details could change in future betas. Please keep 
>> in mind
>> that these betas are previews and we welcome feedback on improving them.
>> 
>> Feel free to contact me if you have any questions, I will also attend 
>> IETF93.
>> 
>> Thanks,
>> David Schinazi
>> Apple CoreOS Networking Engineer
>
>