[uylug-varios] IPv6

[etrapani]

> 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
[2] 
http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-07#section-5.6