[uylug-varios] IPv6

[Carlos Martinez]

Lo de preferir v6 siempre venia de antes de HE, de hecho el trabajo que
desemboco en HE vino en parte como respuesta al comportamiento anterior y
los problemas que generaba.

Muy buenos tus otros comentarios sobre HE.

Abrazo

Carlos
On Feb 18, 2012 12:15 AM, "etrapani" <etrapani at unesco.org.uy> wrote:

>  Es que la idea de 'happy eyeballs' tal como se hablo en el IETF es
>> preferir la conexion mas rapida y cachear ese resultado a nivel del
>> sistema operativo, o de la aplicacion al menos. Ya no es mas el
>> preferir IPv6 siempre, como era antes.
>>
>
> En el draft (miré el histórico, arriba de todo) nunca la opción fue
> preferir IPv6 siempre, en todas las versiones hablan de encontrar la manera
> óptima.  Igual en el último (07) le dan una "pequeña ventaja a IPv6" al
> seguir la preferencia del sistema operativo (manifestada en getaddrinfo())
> y la explicación está buena, es para ahorrar tráfico sobre IPv4, porque es
> de esperar que cada vez haya menos infraestructura dedicada a IPv4 y más a
> IPv6.
>
> En MacOSX si anda IPv6 *y también* IPv4, se queda con el más rápido.  No
> sé si va en línea con el draft.  El ejemplo es que cuando andan los dos
> dejan caer IPv4.
>
> Sobre el cacheo, ojo que no es a nivel del sistema operativo, el cache se
> hace donde sea que se esté resolviendo el happy eyeballs, que puede ser
> exclusivamente de aplicación (tipo Firefox).  Lo importante es cachear en
> algún lado para no seguir haciendo todo doble.
>
> En una versión más vieja que encontré[1] de algo relacionado se habla
> incluso de ¡elegir entre IPv4, IPv6, TCP y SCTP!
>
>  Esto tiene algunas consecuencias muy interesantes a la hora de
>> desarrollar aplicaciones web, y me lo encontre cuando estuve
>> trabajando en la aplicacion del concurso IPv6.
>> Lo que pasa es que ya no es mas deterministico que stack se va a
>> usar, lo cual hace que un reload de la pagina pueda venir por un stack
>> diferente que el usado para la anterior, lo cual altera bastante la
>> gestión de sesiones en PHP, Django y otros frameworks web.
>>
>
> El draft dice en esta sección[2] explícitamente que eso no debe suceder:
> "While it is tempting to use Happy Eyeballs to maintain responsiveness, web
> browsers MUST NOT change their Same Origin Policy because of Happy
> Eyeballs, as that would create an additional security exposure.".
>
> En particular en Rails no he visto a nadie hablar de ese problema con las
> sesiones (no digo que no exista, sólo que nunca lo oí mencionar).
>
>  Incluso la
>> carga de la *misma* pagina termina a veces trayéndose algunos objetos
>> por v4 y otros por v6. Esto probado con Firefox y Chrome en OSX y con
>> Chrome en Linux.
>>
>
> Si son objetos del mismo servidor, entonces está muy mal implementado o no
> es por el "happy eyeballs". O sea, si lo detectaste, yo creo habría que
> reportarlo como bug.  Después que se "rompió" IPv6 en Firefox agarré
> confianza para eso ;), si querés lo reporto yo.  Hay que tener una versión
> de navegador y una página donde pase el problema, algo que lo haga
> reproducible.
>
>  En algun momento el comportamiento de happy eyeballs
>> supongo se va a ir al kernel, que es donde mas sentido tiene que esté.
>>
>
> ¿En el kernel?  No veo que pueda ir ahí.  Primero llamás a getaddrinfo() y
> después a connect().  Visto desde el kernel, ¿cómo podrías implementar
> "happy eyeballs"?  Los pasos del algoritmo te quedan en dos llamadas
> diferentes.  EL draft en las estrategias sugiere que el kernel recuerde
> prefijos y direcciones que no conectan.  Eso ayudaría a la aplicación al
> volver inmediatamente la conexión, pero es eso, una ayuda, no la
> implementación.
>
> Para mí, como en MacOSX eso es parte de una biblioteca.  Yo entiendo que
> adentro del kernel no podés porque connect() ya trae *una* dirección y las
> alternativas (ipv4 o ipv6) están en espacio de usuario, las tiene la
> aplicación después de la llamada a getaddrinfo.  Y además no me suena mucho
> a tarea del kernel andar reintentando y buscando alternativas.  El kernel
> tiene que crear el socket y hacer el connect con la dirección que el
> programa le diga,punto.  Lo demás va afuera, creo yo.
>
> La única que se me ocurre es agregar alguna metafunción que haga el "happy
> eyeballs", pero más que en el kernel iría en libc, ¿no?  ¿O me estoy
> perdiendo algo?
>
> Eduardo.
>
> [1] http://tools.ietf.org/html/**draft-wing-http-new-tech-00#**section-1<http://tools.ietf.org/html/draft-wing-http-new-tech-00#section-1>
> [2] http://tools.ietf.org/html/**draft-ietf-v6ops-happy-**
> eyeballs-07#section-5.6<http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-07#section-5.6>
>
> ______________________________**_________________
> Uylug-varios mailing list
> Uylug-varios at listas.uylug.org.**uy <Uylug-varios at listas.uylug.org.uy>
> http://listas.uylug.org.uy/**listinfo.cgi/uylug-varios-**uylug.org.uy<http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.uylug.org.uy/pipermail/uylug-varios-uylug.org.uy/attachments/20120218/2d658078/attachment-0001.htm>