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