Juan Carlos Gurtierrez Ayala Buenas noches en Europa, Buenas tardes en America. En nombre del Comite Organizador del I Encuentro Internacional de IPV6, Firewalls, Criptografia Y VPN en UniNet, les agradezco su amable presencia y participacion entusiasta.
Para continuar con los trabajos de este evento cientifico, tengo el honor de presentarles a Horacio Pena, miembro del grupo de trabajo IPv6 de Uninet y manager de nuestra red. Como podran comprobar ustedes, la amplia experiencia y conocimiento del Sr. Peña en el tema que desarrollara son las bases para discusion y analisis salidos.
Es esta una oportunidad mas dentro del Congreso para la actualizacion profesional y profundizacion en el campo de conocimiento del area. La charla lleva como titulo "Las semanticas de bind en la RFC 2553 bloquean el camino hacia la independencia de protocolos".
En ella se desarrollan ideas importantes sobre la forma de construir o modificar aplicaciones que podamos emplear en la transicion hacia los nuevos mecanismos de comunicacion en las redes IPv6 y las implicaciones que esto trae consigo. Recibamos ahora a nuestro conferenciante.

Horacio J. Peña Buenas tardes. El texto de la presentación de hoy está en http://6fevu.uninet.edu/text/afindependence.html por lo que no repetiré aquí lo allí expuesto sino que haré un breve repaso para luego dar lugar a la discusión al respecto.

Este trabajo es el resultado de la participación del grupo de IPv6 de Uninet en el ipngwg (grupo de trabajo de la ietf sobre IPv6) y fue inspirado por los inconvenientes encontrados al colaborar con el grupo IPv6 de Debian.

El grupo IPv6 de Debian tiene como objetivo permitir a esta distribución de linux ser capaz de trabajar en entornos IPv6, y su principal tarea es portar aplicaciones que actualmente son exclusivas de IPv4 para que funcionen en IPv6 también.

Existen dos mecanismos de convertir una aplicación exclusiva de IPv4 para que funcione con IPv6. Uno de ellos es crear aplicaciones que conozcan de IPv6 y puedan comunicarse con nodos IPv4 por medio de un sistema de traducción de direcciones llamado mapeo (que hace al espacio de IPv4 un subconjunto del de IPv6) el otro método es crear aplicaciones que sean independientes de los protocolos usados. Esto se realiza mediante ciertas interfaces que permiten a la aplicación obtener del sistema operativo información acerca de cuáles son los protocolos que pueden usarse.

En el grupo Debian existe consenso de que este segundo método es más adecuado ya que permite hacer la conversión de las aplicaciones una sola vez. Si en algún momento aparecieran otros protocolos con este sistema no haría falta una nueva conversión de las aplicaciones sino que todas ellas pasarían a funcionar con este nuevo protocolo inmediatamente en cuanto el sistema operativo lo soporte.

El problema es que la especificación de la API IPv6 impide que se pueda trabajar bien con esta metodología.

Para entender por qué debemos ver cómo funciona: cuando una aplicación quiere funcionar como servidor de un determinado servicio utiliza la función `getaddrinfo' para pedirle al sistema operativo información acerca de a qué direcciones debe ligarse. El sistema operativo le devuelve una lista con los protocolos soportados, y a qué puerto (o equivalente, en realidad usa estructuras sockaddr) debe ligarse la aplicación entonces creará un socket por cada protocolo, hará las ligas (con bind/listen) y luego esperará (mediante select o loop) que alguno de los sockets reciba una nueva conexión.

El problema con esto es que -por el mecanismo de mapeo de direcciones IPv4 a IPv6 mencionado antes- el conjunto de conexiones al que se liga la dirección 'comodín' de IPv6 incluye aquel al que se liga la dirección 'comodín' de IPv4. Este solapamiento genera tres posibles comportamientos de la función bind:

- No respetar el standard y considerar IPv6 e IPv4 como protocolos distintos, anulando el mecanismo de mapeo y por tanto el solapamiento. Es el camino elegido por OpenBSD, NetBSD (salvo configuración en contra) y Windows.
- Permitir que se ligue un socket IPv4 a la dirección 'comodín' pese a estar ligado otro al mismo puerto en la dirección 'comodín' IPv6. Permitiendo entonces al nuevo socket `robar' conexiones que sin su acción debería recibir la aplicación IPv6 (esto genera un bug de seguridad)

- No permitir el ligado del socket IPv4 cuando está ligado el de IPv6. Esto implica que al intentar trabajar con la metodología independiente del protocolo se deben ignorar errores.

Ante este problema hemos escrito el trabajo que aquí se presenta, y que será enviado para la consideración del grupo de trabajo de la IETF luego de esta charla. En este trabajo proponemos distintas posibles soluciones:

- Eliminar el mecanismo de mapeo de direcciones IPv4. Esto tiene una cierta cantidad de ventajas adicionales (Jun-ichiro itojun Hagino, de IIJ, describe en su ipv6-transition-abuse problemas adicionales que acarrea este mapeo), pero hay demasiado invertido ya en esta tecnología por lo que es inviable `politicamente'.

- Permitir que este mecanismo de mapeo deba ser activado explicitamente por las aplicaciones que desean usarlo. Esto solucionaría el problema principal, pero no abriría el camino a las implementaciones que en este momento no respetan el standard a cumplir con él sin tener que hacer una concesión a la que se resisten (por razones de seguridad)

- Agregar más `magia' a getaddrinfo, haciendo que esta función no informe de la existencia del protocolo IPv4.

- Agregar una provisión que permita la existencia de sistemas con pilas múltiples (y aisladas) en ves de con una pila única que incluya a ambos protocolos.

Todos los mecanismos son suficientes a nuestros propósitos (poder crear aplicaciones portables que no deban volver a ser cambiadas con la aparición de nuevos protocolos), y aunque preferiríamos que se considerara al mapeo de IPv4 como obsoleto y se abandonara, creemos que la mejor solución `posible' es esta última.

Esto es todo, muchas gracias por su atención.

(aquí grandes aplausos)

Tras esta exposición, se dearrolló el siguiente coloquio:

Juan A. Campo Que es eso de la direccion "comodin"???

Horacio J. Peña Cuando programas un server tienes que decirle al sistema operativo en qué dirección quieres escuchar (si tienes varias direcciones en la máquina), si no te interesa restringirte a una sola dirección puedes usar la dirección `comodín' que acepta lo enviado a cualquiera de las direcciones del sistema

Juan A. Campo muchas gracias HoraPe :))

Juan A. Campo las distintas implemetaciones no van a dar lugar a herramientas no portables?

Horacio J. Peña netlag: sí, efectivamente eso está pasando me ha pasado portar aplicaciones para que trabajaran con ipv6, y que al llevarlo a otras plataformas no anduviera ese fue el motivo por el que empezamos a trabajar en esto

Juan A. Campo gracias :)

Raul Mahiques eliminar el mapeo de direcciones IPv4, puedes explicarnos mas pq es inviable politicamente?

Horacio J. Peña hay mucha inversión en ello muchas empresas que han portado su software basandose en ese sistema para permitir la interoperación con ipv4 y que se opondrán a que este sistema les sea anulado de golpe lamentablemente,

Raul Mahiques de quien?

Horacio J. Peña uno de quienes más firmemente ha trabajado sobre este modelo es Jim Bound, que es autor de la especificación y que en cierto modo controla qué va y qué no...

juanpe seria viable una implemetacion de comunicaciones tipo 'plugin' con un 'core' lo suficientemente flexible, que permitiese evitar esto? (Rompiendo POSIX)

Horacio J. Peña explicate un poco más, por favor

juanpe bien el problema es que el paso de ipv4 a ipv6 conlleva a problema en las aplicaciones

juanpe digo que si seria viable una especie de caparazon para las aplicaciones por si algun dia ipv6 tuviese problemas

Horacio J. Peña ya creo entenderte

juanpe seria viable que ese caparazon fuese flexible?

Horacio J. Peña ese caparazón está hecho y es lo que he presentado como "método independiente de la familia de protocolos" :-) justamente lo que intentamos con este trabajo es evitar que el caso especial del mapeo de ipv4 a ipv6 estorbe la generalidad de este caparazón

Horacio J. Peña contestá tu pregunta?

juanpe crees que seria eficiente su implementacion?

Horacio J. Peña sí, funciona y funciona muy bien (salvando que en algunos casos, la implementación de otras cosas lo complica más de lo que hace falta)

juanpe aps gracias :)

Antonio Verdejo aunque se han propuesto varias soluciones, parece ser que la mas acertada (o la que a priori plantea menos problemas, eso entendi) pasa por tener pilas dobles, ala open/netbsd... sera esta la que de algun modo se imponga? historicamente ha sido asi como se ha venido haciendo, cuando una maquina tenia mas de un protocolo (recuerden los tiempos de novel y su ipx conviviendo con ip, por ejemplo)

Horacio J. Peña el problema está en que ipv4 e ipv6 son protocolos distintos. Lamentablemente se los disfraza como si fueran uno solo con pequeñas diferencias entre versiones supuestamente, en un futuro no demasiado remoto nos desharemos de la parte IPv4 de las pilas duales

Antonio Verdejo precisamente por eso: dos protocolos, dos pilas... :? (perdon por la interrupcion)

Horacio J. Peña y tendremos pilas IPv6 independientes, iguales a las que ahora implementan los sistemas con pilas dobles nuestro trabajo propone la legalización de esos sistemas con pilas dobles haciendo opcional el mecanismo de mapeo, que es lo único que fuerza la existencia de la pila dual

Horacio J. Peña contestado?

Antonio Verdejo si, gracias...

Antonio Verdejo a proposito de lo que comentas en tu doc: "we don't believe IPv6 is the cure-everything protocol and that any time in the future (probably in the far future) there would be a new transition from IPv6 to some other protocol"

Antonio Verdejo con el tiempo y el dinero que se esta invirtiendo en IPv6, tan poco futuro se le augura como para plantearse un futuro y posible cambio? :)

Horacio J. Peña no es que se le augure poco futuro pero con ipv4 hemos ya visto un protocolo que sería perdurable, y que terminó por necesitar un reemplazo

Antonio Verdejo ?

Horacio J. Peña no estamos hablando de pocos años, sino mas bien de décadas... creemos que ipv6 durará mucho hay aspectos en los que creemos que nunca se alcanzarán sus limitaciones (por ejemplo, el espacio de direcciones, que es enorme) pero hay otros aspectos, de los que no creo seamos conscientes todavía sino que aflorarán con el uso y que nos harán buscar quizá otro protocolo a modo de ejemplo, hace 30 años el espacio de direcciones de ipv4 era suficientemente grande hace 10 años ya no lo era, pero la cantidad de rutas en los backbone no era todavía un problema hoy lo es de la misma manera, hay aspectos que hoy no vemos y que serán las limitaciones que harán necesario buscar nuevos protocolos y si esas transiciones han de pasar, conviene intentar que se puedan llevar a cabo facilmente

Jimmy Teixeira Espinoza soy estudiante de ingenieria. En un futuro seguiran existiendo direcciones IP o se sustituiran?

Horacio J. Peña mientras los protocolos en uso se llamen IP sus direcciones se llamarán direcciones IP :-) aunque no se si es eso lo que preguntas... si preguntas si seguiremos usando direcciones del tipo 200.47.36.251, la respuesta es no.

Jimmy Teixeira Espinoza ya que se habla de un futuro, exisitira algun reemplazo para los IP

Horacio J. Peña Usaremos direcciones como 3ffe:29a1::200:21ff:fe47:2d95

Jimmy Teixeira Espinoza eso que es

Horacio J. Peña esa es una dirección IPv6. Las direcciones IPv6 tienen 128 bits, en vez de los 32 de IPv4. Las nuevas direcciones se siguen llamando "direcciones IP" aunque estemos hablando de un protocolo totalmente distinto y que comparte no demasiado mas que el nombre con el anterior.

Jimmy Teixeira Espinoza gracias :)

Antonio Verdejo (con lo que se ve, y me van a permitir la broma, como de necesario sera el sistema dns en un futuro ;) mi pregunta: uhm... aunque sea un ejercicio de prospectiva, cuales crees que pueden ser esos posibles aspectos? aspectos en los que IPv4 flojea (seguridad, calidad de servicio, espacio de direcciones) parecen resueltos con IPv6...

Horacio J. Peña actualmente las direcciones ipv4 son memorizadas todo el tiempo (creo conocer las direcciones IPv4 de toda la red del ISP donde trabajo), esto en IPv6 no va a ser razonable (no tengo la menor idea de qué direcciones tienen mis equipos IPv6) hmmm, hay problemas que no están todavía resueltos, pero que se ven venir...

David Correa agradese a HoraPe el tiempo dedicado a investigar ese tema ademas de sacar tiempo para compartir con nosotros aca

Horacio J. Peña contra los que IPv6 no es la solución, pero que no tomarán a este protocolo por sorpresa por ejemplo el tema del tamaño de las tablas de rutas: la necesidad de agregación, el problema de cómo hacer multihoming sin que esta tabla crezca, etc. O los temas de movilidad creo que los temas que pueden limitar a IPv6 no podemos sospecharlos siquiera hoy y que los encontraremos a medida que tengamos mayor experiencia.

Antonio Verdejo eso me da pie a una pregunta que no se si planteo en tu otra charla... como va a afectar IPv6 (y su ingente espacio de direcciones) a protocolos de rutado exterior, bgp por ejemplo... veremos routers con memoria y capacidad de proceso dignas de un superordenador? :)

David Correa w8 eso mismo iba a preguntar yo, pero me imagino la respuesta (aumentar RAM y capacidad de CPU) para manegar tanta informacion

Horacio J. Peña no

Antonio Verdejo cron: nos colamos los dos :)

Horacio J. Peña porque el problema mayor no es ni la RAM ni la capacidad de procesamiento...

David Correa HoraPe las tablas seran mas grandes pues el ipv6 ocupa mas

Horacio J. Peña el problema mayor de las tablas de ruteo enormes es el tiempo de convergencia, con lo que pasa a ser un problema de computación distribuida, no solucionable meramente tirando RAM y CPU. Sí, eso hará falta tb, pero no es el problema principal

David Correa veo

Antonio Verdejo aja

Horacio J. Peña actualmente las tablas de ruteo DFZ (las de backbone) tienen unas 100.000 rutas

David Correa digo, veo lo de la convergencia

Horacio J. Peña la idea de IPv6 es aumentar enormemente la agregación y encontrar métodos de multihoming que se adapten a esto para ello hay un grupo de trabajo del ietf (multi6 o algo así, no recuerdo exactamente el nombre) abocado a buscar estos métodos

Antonio Verdejo y lo mismo, intuyo, pasara con el dns... los problemas de propagacion pueden ser terribles...

Horacio J. Peña para poder limitar la cantidad de rutas en las tablas DFZ la idea es que no se asignaran bloques con prefijos mayores a un /16 esto significa que solo unas 64 mil organizaciones podrán tener direcciones asignadas directamente desde los RIR y el resto deberán pedírselas a sus upstreams

David Correa isp's?

Horacio J. Peña por ello, debe -entre otras cosas- ser muy fácil renumerar, para evitar la enorme dependencia en los upstreams que generaría esto

Antonio Verdejo parece pues que lo de "islas ipv6" tiene un sentido oculto mucho mas real del que parece, vistos los problemas con el rutado y la resolucion de nombres...

Horacio J. Peña cron: sí, alrededor de 64 mil ISPs MUY GRANDES recibiran direcciones propias el resto las tomará de esos ISPs

David Correa veo

Horacio J. Peña no entiendo las implicaciones para DNS, ni mucho menos lo del setido oculto de "isla ipv6" :-)

Ricardo J. Cardenes Medina ISP's que supongo que actuarán básicamente dando conectividad muy gorda

Horacio J. Peña Ricardo: los ISPs que reciban esas direcciones tendrán que cumplir unos requisitos bastante complicados. No se lo darán a los primeros 64 mil que los pidan (aunque llegar primero va a dar ventaja lo mismo :-)

David Correa los ruteadores en compañias pequenas que usan BGP4 solo necesitan la tablas de las rutas de los isp, no de el internet completo

Horacio J. Peña puedes aclarar lo de los DNS

Antonio Verdejo con la cantidad de direcciones posibles en IPv6, y por tanto de posibles dispositivos a los que acceder (necesariamente con un nombre, vista la dificultad de las direcciones IPv6)la cantidad de incorporaciones al dns pueden ser del orden de... no se, X por dia

Horacio J. Peña cron, sí, pero toda empresa que hace multihoming publica una ruta adicional, lo que genera una carga en toda la red, no solo en su propia red

Antonio Verdejo teniendo en cuenta los problemas que has comentado del rutado, y el, o eso imagino, derivado de la propagacion de esas nuevas maquinas de los nombres de esas nuevas maquinas, quiero decir

Horacio J. Peña w8: sí, pero ese no es problema de la red sino de los servers de dns de los que dependa cada dispositivo, por lo que es procesamiento en paralelo, que sí se puede mejorar con mas RAM y CPU. El dns no se propaga... por lo que no tiene convergencia ni problemas de ese estilo :-)

Antonio Verdejo pueden haber verdaderas "islas ipv6" (no se si se ha entendido ahora)

Horacio J. Peña (a lo que llamamos "propagación" en dns es al envejecimiento de los datos de cache en sistemas

Horacio J. Peña que ya han consultado esos registros)

Antonio Verdejo ha sido un termino mal utilizado por mi parte, cierto

Horacio J. Peña así que no creo que ese sea un gran problema

Antonio Verdejo aja

Antonio Verdejo y otra: podrias comentar, aunque fuera someramente, los problemas de seguridad a los que hacias referencia en la solucion "apropiativa"?

David Correa las tablas de DNS no "propagan" a todos los DNS de el internet, solo a los DNS especificados (creo)

Horacio J. Peña cron: dos partes, cada zona (dominio) tiene ciertos dns que son autoritativos sobre ella (ie, sus respuestas deben aceptarse como válidas e indiscutibles) cuando modificas una zona, estos servidores tienen que enterarse y poner sus tablas en sincronía. Pero normalmente son pocos por zona, y no es un problema grave hacerlo

Antonio Verdejo (en la que servers ipv6/ipv4 pueden escuchar en el mismo socket, the buggy ones solution en tu doc)

Horacio J. Peña la segunda parte es que cuando algún equipo pide datos sobre un registro el resolver usado guarda información sobre las respuestas en una cache

David Correa esos son los que se configuran para que sean esclavos de el pricipal

David Correa (los primeros)

Horacio J. Peña la actualizacion de estas cache es lo que se llama 'propagación' en dns, pero no tiene problemas respecto de ipv6

Horacio J. Peña Antonio, imagina el siguiente caso: instalas un servidor de web en un equipo que se liga al comodín de IPv6 cuando tu te conectas al puerto de web en la dirección ipv4 de esa máquina supones que te atenderá tu servidor pero si otra aplicación se liga al mismo puerto en ipv4 y le roba a la tuya las conexiones web de ipv4 cuando tu te conectes no lo harás a donde tu crees sino a la segunda aplicación

Antonio Verdejo ya...

David Correa HoraPe desde el punto de vista de el programador, hay que definir el socket que sea ipv6 en la aplicacion? no recuerdo de monento haver definido sockets tipo ipv4 (explicitamente) en los pocos programas que he echo que usan servidores

Horacio J. Peña cron, revisa tu código y verás que probablemente lo has hecho... :-) socket se define así:

  #include 
        #include 
        int socket(int domain, int type, int protocol);

David Correa ok AF_INET

David Correa y ipv6?

Horacio J. Peña AF_INET6

David Correa oks

Horacio J. Peña pero eso solo si programas con el metodo al que yo me opongo :-)

David Correa hace sentido

Horacio J. Peña programando con independencia del protocolo la respuesta que te da getaddrinfo entre otras cosas te indica con qué parametros llamar a socket

David Correa el otro metodo usa solo AF_INET para ambos?

Horacio J. Peña no, es algo así:

 hints.ai_flags = AI_PASSIVE;
 hints.ai_family = AF_UNSPEC;
 hints.ai_socktype = SOCK_STREAM;
 
 if(getaddrinfo(NULL, "telnet", &hints, &res) != 0)
    die();
 ressave = res;
 for(n = 0; (n < MAX_AF) && res ; res = res->ai_next) {
         listenfds[n] = socket(res->ai_family, res->ai_socktype,
                     res->ai_protocol);
         if(listenfds[n] < 0)
           continue; /* libc supports protocols that kernel don't */
         if(bind(listenfds[n], res->ai_addr, res->ai_addrlen) != 0)
       die();
         if(listen(listenfds[n], 10) != 0)
       die();
         n++;
         }

Horacio J. Peña esto lo que hace es: llamar a getaddrinfo diciendole que quieres la información para un server (AI_PASSIVE), sin especificar que protocolo usar (AF_UNSPEC) pero de tipo stream (SOCK_STREAM), para proveer el servicio "telnet". Esto te devuelve una lista enlazada que debes atravesar creando un socket para cada protocolo y ligandolos según corresponda luego con select o poll detectas a qué socket corresponden las conexiones que se crean

Horacio J. Peña alguna pregunta más?

David Correa HoraPe el trabajo es ipresionante, le deseo suerte

David Correa impre...

Antonio Verdejo bueno, pues en nombre de todos, muchas gracias por todo horape :)

TODOS:
plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas
plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas

Horacio J. Peña Christian Lazo comentará la experiencia que hay en el 6bone en Hispanoamerica, dentro de 70 minutos.