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

Sat Jul 11 19:39:56 BRT 2015

Se ve bien. A ver como sube el uso de IPv6.

Slds
as

On Sat, 11 Jul 2015 at 19:38 Azael Fernandez Alcantara <afaza at unam.mx>
wrote:

> 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
> >
> >
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
> Cancelar suscripcion: lactf-unsubscribe at lacnic.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20150711/347f6b9a/attachment.html>