Conferencia

Ricardo J. Cárdenes Medina Bienvenidos un día más a las jornadas 6FEVU.
Les presentamos hoy a Javier Fernández-Sanguino Peña de SGI - GMV Sistemas S.A. empresa en cuyo área de seguridad logica trabaja. Como anécdota (no tiene mucho que ver con su conferencia de hoy), comentar que es desarrollador de Debian desde hace unos años :-) Y nos va a hablar hoy de los problemas de interoperabilidad de NAT

Javier Fernández-Sanguino Hola, buenas noches a todos... Como ha comentado Ricardo, el tema que voy a presentar son los problemas de interoperabilidad de NAT.
NAT es Network Address Translation, es decir, traducción de direcciones.
NAT es el método por el que una dirección de IP se convierte en otra, y su introducción en IPv4 (RFC 1631) se debe a la necesidad de resolver dos problemas:
- la escasez de direcciones en el espacio de direccionamiento de IPv4
- la interconexión de redes que no siguen el RFC 1918 con redes públicas

No voy a entrar en todos los detalles de la presentación, que teneis (en inglés, la traducire al castellano, posiblemente) en el servidor de UNINET

http://6fevu.uninet.edu/text/IPSEC-NAT.SGML.html

Javier Fernández-Sanguino NAT en realidad no es un único método de traducción de direcciones
En realidad hay cuatro distintos: NAT Basico (Tradicional), NAT Bidireccional, Doble NAT y NATP.
NAT es una solución a corto plazo, pero de uso muy extendido.
Sin embargo su introducción en el despliegue de IPv4 ha introducido algunos problemas.
Para decirlo de una forma rápida, NAT no interopera todo lo bien que debiera con protocolos ya definidos en IPv4. Ejemplos: RPC, FTP, X-windows...
La razón? Estos protocols incluyen, en algunos casos, información de la cabecera TCP/IP(que es la que NAT altera) dentro del intercambio de información entre equipos.
NAT rompe, por tanto, el concepto universal en Internet: comunicaciones extremo a extremo.

La dirección IP ya no es un identificador único, una misma dirección IP puede, en realidad, ser utilizada por múltiples hosts con un servidor (dispositivo NAT) realizando la multiplexación. Todos los protocolos que he indicado anteriormente, junto con algunos otros (por ejemplo, Voz sobre IP, VoIP) se basan en este concepto de extremo a extremo.
Sin embargo, estos protocolos pueden, generalmente, resolverse con la introducción de ALG (Application Level Gateway).
La idea general es que en el dispositivo NAT se introduce un proxy que hace las modificaciones necesarias a la "carga" de los paquetes para que funcionen a través de un dispositivo NAT.
Os pongo un ejemplo, si en FTP el cliente utiliza el comando PORT para indicar el puerto en el que va a esperar la conexión de datos del servidor.
El ALG de FTP lo que hará sera inspeccionar el contenido de los paquetes enviados por el cliente, de forma que si ve una directiva PORT la modifique para que funcione tras la traducción.
También hay problemas generales por el uso de NAT en TCP/IP aunque pueden considerarse algo más "esotéricos". Uno de ellos es el caso de que se utilice fragmentación de paquetes, como se comenta en el RFC 3027.
Sin embargo, aún así, habrá protocolos que no funcionen ni con un ALG.
Esto sucede, por ejemplo, cuando el dispositivo NAT no puede modificar el contenido de los paquetes y éstos incluyen información dependiente de las cabeceras.
¿Cuando sucede esto?
Cuando se utiliza cifrado a nivel de aplicación, por ejemplo, o cuando, con IPsec se utiliza a nivel de red.
Como quiera que la parte de IPsec es en la que me centraré, quizás es conveniente que de un pequeño barniz de qué es IPsec y que intenta resolver.
Bien, IPsec es un estandar que se definió originariamente para IPv6, pero que sin embargo se decidió incorporar a IPv4
IPsec es el estandar de seguridad para la capa de aplicación, que permite el cifrado del contenido de los paquetes de forma que la comunicación, extremo a extremo, entre dos servidores, sea lo más segura posible.
Ipsec ofrece servicios de control de acceso, autenticación y confidencialidad.
Evidentemente, estos mismos servicios se pueden dar en otras capas de TCP/IP
Por ejemplo, en el nivel de aplicación (SSL o TLS)
Sin embargo, aunque se introduzca parte de esta funcionalidad en estas capas, si la capa de red no es segura, seguirá habiendo posibilidad de ataques sobre éstos.
Os pongo un ejemplo, que se basa en el concepto de seguridad de que una cadena es tan débil como el eslabón más débil...
Si se utiliza SSL para establecer una comunicación cifrada contra un servidor una vez establecida, un atacante podría intentar romper la conexión mediante el envío de paquetes IP falsos con dirección IP origen la del cliente real pero introduciendo códigos de redundancia falsos, que harán que se descarten.
Si consigue "engañar" al sistema operativo (capa de red) de que el cliente remoto no opera bien, podría conseguir romper la comunicación extremo a extremo.
Evidentemente, esto no es tan secillo como lo resumo aquí, pero os puede dar una idea.
IPsec tiene dos métodos para garantizar estos servicios: AH y ESP
El primero de ellos garantiza la autenticidad de los paquetes TCP/IP
y hace esto mediante la generación de un hash cifrado que "protege" la cabecera TCP/IP
Esta información se incluye en todos los paquetes, así, si el servidor remoto observa que, tras descrifrar el hash y compararlo con el que genera él del paquete son distintos, entonces descarta el paquete, porque alguien lo ha manipulado.
Claramente, AH no funciona con NAT
Supongo que adivinareis por qué :)
Si NAT modifica el paquete, y IPsec-AH se protegue contra estas modificaciones, el resultado es interoperabilidad 0 (siempre y cuando claro, la operación de NAT se haga *después* de la de IPsec) ESP (Encapsulating Security Payload, RFC 2406) ofrece cifrado para el contenido del paquete IP.
De forma que garantiza la confidencialidad de la comunicación la cabecera IP se mantiene (en modo normal, no em modo túnel) sin embargo, el contenido se cifra.
(es decir, a partir de las opciones de IP, esto incluye la carga TCP/UDP/ICMP, etc.., el nivel transporte)
ESP tiene problemas con NAT, aunque funciona en algunos casos (como es el modo túnel).
Por la sencilla razón de que, como el contenido de los paquetes está cifrado, y el dispositivo NAT puede tener que cambiar esta información, los paquetes no salen "bien".

Por ejemplo, si cambia la dirección IP, cambia el CRC del paquete TCP y como el paquete esta cifrado, el dispositivo NAT no puede (en principio) descifrarlo, volverlo a generar, y cifrarlo de nuevo.

O, en otro caso, si el dispositivo NAT tiene que cambiar el puerto TCP(cuando se usa NATP) el hecho de que no pueda modificarlo significa que el paquete no sale del dispositivo.
Si quereis entenderlo un poco más, he puesto unas gráficas en el URL
http://www.dat.etsit.upm.es/~jfs/debian/doc/ipsec-nat/
Por último, en IPsec hay que considerar IKE, que es el protocol que se utiliza para el intercambio de claves entre los servidores que establecen el tunel de cifrado.
El hecho de que el intercambio de claves no funcione significa que ¡ni siquiera se puede establecer la comunicación IPsec!
Dos razones para que falle IKE:
1.- Algunas implementaciones de IKE sólo funcionan si origen y destino utilizan el puerto UDP 500 (por tanto si el dispositivo NAT cambia el puerto, nada que hacer)
2.- Si IKE utiliza como mecanismo de autenticación alguno de los propuestos basados en dirección IP, si ésta cambia, entonces estamos en la misma situación.
Creo que esto resume un poco todos los problemas.
Soluciones? Pocas.
En realidad hay varios drafts del IETF (por cierto, www.ietf.org :) que hablan de los problemas de interoperabilidad de IPsec y NAT y , que yo conozca, sólo hay una propuesta que funcione, en todas las situaciones, extremo a extremo. Se conoce como NAT-T (Nat Traversal).
Existe una propuesta de implementación parcial basada en FreeSwan, que también se encuentra entre los estándares.
Como sustituto general de NAT, existe un draft, conocido como el protocolo RSIP (Realm Specific IP) que podría llegar a ofrecer conectividad extremo a extremo.
El protocolo es complejo, pero quizás se puede resumir en que es un NAT "acordado" es decir, los dispositivos que realizan la traducción de direcciones le comunican la dirección con la que va a salir al servidor origen.
De esta forma, cuando envíe paquetes al servidor remoto, puede "prepararlos" para que no sufran los efectos del cambio de dirección.
Por ejemplo, puede calcular el CRC de los paquetes, en lugar de en base a su dirección actual, a la dirección final con la que sale.
En cualquier caso RSIP es todavía un estándar, pero que podría resolver, a corto-medio plazo, todos los problemas extremo-a-extremo en protocolos que no interoperen con NAT (IPsec incluido).
Aunque esto significa cambiar las pilas de protocolos de los sistemas operativos, e introducir elementos de interconexión que incluyan este protocolo.
Creo que puedo terminar ya, no se si me he excedido.
Unos últimos comentarios, NAT ha sido la "salvación" para IPv4 a corto plazo, no cabe la menor duda, y es el origen de su gran popularidad.
Sin embargo, con el tiempo se han detectado problemas con muchos protocolos, el hecho de que IPsec sea uno de ellos no es de extrañar, ya que NAT rompe la premisa en la que se basa precisamente IPsec (y que intenta mantener)
Actualmente IPsec no está tan extendido como podría estarlo, aunque la culpa no es sólo de NAT (los problemas de despliegue de las infraestructuras de claves públicas influyen) y, generalmente, uno se lo encontrará asociado a un dispositivo de NAT.
De forma que la traducción de direcciones se haga *antes* que el cifrado.
Hay casos, sin embargo, en los que ésto no podrá ser así. Por ejemplo, uno en el que estoy actualmente trabajando, como es el hecho de que los proveedores de servicios de conectividad a Internet puedan decidir introducir a sus usuarios en redes privadas (direccionamiento que sigue el RFC 1918)
Los detalles los dejo para la ronda de preguntas.
Creo que eso es todo, espero no haberos cansado demasiado con este tema (reconozco que es un tanto farragoso :)
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 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

Ricardo J. Cárdenes Medina Al contrario :) ha sido muy interesante :)

Javier Fernández-Sanguino Ahora os toca a vosotros :)

Javier Fernández-Sanguino Preguntas? O he dejado KO a todos?

María Jesús Coma: muchas gracias ..... nos costara digerirlo, pero desde luego, se agradece!

Erven Coronado Padilla muy aclaradora charla....bravo!!!!

Javier Fernández-Sanguino Si quereis que entremos en detalle en algún problema no teneis más que preguntar...

David Correa jfs podrias hablar un poco mas de el nuevo projecto de freeswan y un ejemplo practico de esta implementacion?

Javier Fernández-Sanguino Umm... no tengo muchos detalles que daros. Ya sabía que algunos iban a saltar con esta mención :) Sobre FreeSWAN, de momento soporta sin problemas NAT e IPsec en el modo túnel. La implementación que se propone es VMA (Virtual Masquerade Assist), en ella se introducen una serie de cambios para que pueda operar IKE sin problemas, no intenta, sin embargo, arreglar los problemas con IPsec-AH (hay mucha gente que considera que IPsec-ESP ofrece lo mismo que IPsec-AH y es por tanto redundante). El draft lo ha desarrollado una persona de Lucent Technologies y, si no me equivoco, ha sido incorporado a la base de código de FreeSWAN.

giantux después explica que es "FreeSWAN"

David Correa giantux www.freeswan.org

Juan Pedro Paredes Crees que NAT sera util con tantas direcciones IP disponibles

Javier Fernández-Sanguino Ok. Te refieres a IPv4 o a IPv6?

Juan Pedro Paredes en IPv6 todo esto va sobre IPv6 espero

Javier Fernández-Sanguino Ipsec en realidad es una implementación que originalmente salió para IPv6 pero sin embargo ahora mismo está desplegada en IPv4. Así que, la respuesta sería. Con IPv6 NAT no tiene sentido (ya se ha hablado de esto en alguna otra conferencia :) Pero con IPv4 sí que lo tiene. Además, debido al lento despliegue de IPv6 actualmente pues nos toca vivir con IPv4 hasta dentro de un tiempo, todo esto solo para el fangoso y angosto camino de conversion, supongo.

Esto significa que si uno quiere conectividad segura extremo a extremo actualmente, tiene que basarla sobre IPv4 (en la mayoría de los casos), Además te puedo decir que muchos operadores de red que definen ahora su negocio y su infraestructura para empezar a operar en el futuro, la están basando en IPv4.

weaah de la lectura no me quedó claro si RSIP es o no estándard hoy

haixis juampe : como accedes desde una lan con ips privadas a inet sin nat o un proxy para cada protocolo?

David Correa juampe NAT tambien tiene la ventaja de que puedes usar IP no ruteables detras de cortafuegos

David Correa jfs eso es por que son menos digitos que memorizar XD

Juan Pedro Paredes No lo veo mal IPv4 y si le "sobran" direcciones Javier Fernández-Sanguino cron: también es porque hay menos conocimiento actualmente de IPv6

Javier Fernández-Sanguino Esperemos que iniciativas como este congreso ayuden a su despegue.

Juan Pedro Paredes muchas gracias

ChArLiToS jfs.. puedo hacer una pregunta?

Javier Fernández-Sanguino si, dime

ChArLiToS a ver... realmente hasta hace poco tiempo ipv6... aunke nos duela... habia estado mas muerto que vivo quizas porque los fabricantes no estaban excesivamente interesados crees tu que... este nuevo interes en ipv6 esta basado fundamentalmente en la nueva revolución del acceso a internet mobil es decir, nuevos tipos de dispositivos de acceso a la red y por tanto mas ips. Crees que el interes esta fundamentado en esta nueva necesidad?

David Correa MJesus demanda por mas IP's

Javier Fernández-Sanguino Sí, puede ser una razón, pero en cualquier caso, al ritmo de crecimiento y debido a la mala asignación inicial (organizaciones con más IPs de las que tenían necesidad)

David Correa jfs eso es cierto, pero es la "necesidad" de la industria de producir mas $$ lo que esta empujando eso ahora David Correa ChArLiToS yo pronostico que eso de wireless tambien tendra su limite natural debido a causas de demanda y oferta. En realidad, el espacio de direccionamiento se acabaría agotando en un futuro, con o sin dispositivos móviles

ChArLiToS si, pero es ke me ha sorprendido mucho este nuevo resurgir del ipv6 cuando mucha gente dejo de apostar por el ahora hay un interes mas patente

David Correa ChArLiToS es de esperar, pues hay muchos $$ invertidos en "crear" la necesidad de eso (consumerismo)

Javier Fernández-Sanguino yo creo que más bien la gente lleva trabajando con IPv6 mucho tiempo.... No se, no lo tengo muy claro.

ChArLiToS aja bueno pues.... jfs, para tí, ¿cuales son las razones básicas de ese interes?

Javier Fernández-Sanguino ChArLiToS: ¿del resurgimiento de IPv6?

ChArLiToS aja

Javier Fernández-Sanguino Ok.

Javier Fernández-Sanguino Pues yo creo que las razones básicas es que, como en el euro, la gente empieza a verle "las orejas al lobo" y prefiere ponerse en movimiento. La iniciativa en el ámbito científico siempre ha estado ahí

ChArLiToS si, si eso lo tengo claro. El ipv6 lleva tiempo , pero ha sido cosa de minoria y cuestion de entornos de investigacion

Javier Fernández-Sanguino pero quizás los que ahora están también empujando son los fabricantes, que empiezan a ver que, hay que poner muchos remiendos a IPv4 (NAT) y que las cosas buenas no se pueden desplegar sin problemas (IPsec)

ChArLiToS gracias por tu respuesta jfs :) y felicidades por la charla

David Correa jfs gracias por la conferencia

Ricardo J. Cárdenes Medina Bueno :-)

María Jesús Coma: NAT rompe el modelo de conexión entre extremos, ante esto tenemos dos posibilidades: recuperarlo (mediante IPv6) o programar las aplicaciones de forma que no asuman este modelo y tener en cuenta las limitaciones existentes (por ejemplo, evitando enviar información de direcciones en la carga de los paquetes); cual de los dos métodos crees mejor, desde los puntos de vista tanto técnicos como economicos, y qué crees que pasará en los próximos años?

Javier Fernández-Sanguino MJesus: el problema es que siempre tienes las "legacy applications". Es decir, tan costoso puede ser cambiar todas las aplicaciones antiguas como desarrollar unas nuevas. Pero, si ya con las nuevas (Voz sobre IP es decir H323, o IPsec) tienes problemas y no puedes rediseñarlas o cambias el concepto de Internet, eliminas el extremo-a-extremo, o cambias a una solución que te permita seguir adelante. Mi opinión es que la renovación es más "sana" y además permite eliminar defectos del pasado a la par que introducir nuevas posibilidades.

ChArLiToS es evidente las ventajas de utilizar ipv6, lo que pasa es que la migracion sera bastante dura. Es un cambio que implica tantos niveles...

Javier Fernández-Sanguino Sí, no lo dudo.

Javier Fernández-Sanguino ¿Dudas sobre Ipsec y NAT antes de que nos metamos en otras discusiones?

María Jesús Coma: Javier, me gustaria saber si si esa opinión es personal, y si debian y sgi opinan de la misma manera ¶:Þ

Javier Fernández-Sanguino Ah! Y mis opiniones son mías, ni Debian ni SGI tienen "opinión" al respecto :)

ChArLiToS jaja... siento haberme ido del tema :) Ricardo J. Cárdenes Medina hombre... Supongo que ahora podríamos aprovechar para coger algunos "legacy protocols" y hacerlos más acordes a las características nuevas de la red :) Javier Fernández-Sanguino ChArLiToS: no cambia tantos niveles en realidad sólo uno, y "acomoda" al viejo. Más bien el cambio es de infraestructura y de equipamiento, y, al mismo tiempo, todos los stacks de TCP/IP de todos los ordenadores :)

ChArLiToS con niveles no me referia a los de la pila de protocolos sino que es un cambio que implica tanto clientes finales como dispositivos de enrutado a eso me referia... me exprese mal :)

Javier Fernández-Sanguino Sí, es un cambio estructural grande. En cualquier caso hay alternativas de coexistencia, de forma que los backbones puedan migrar a IPv6 y mantener IPv4 en los clientes finales hasta que estos migren también (aunque tampoco soy un experto :)

Horacio J. Peña hmmm, he de notar que tanto debian como sgi participan de los proyectos de ipv6 :-) Debian tiene un grupo que está intentando que el sistema sea capaz de manejarse bien con ipv6, y sgi participa del 6bone

Juan A. Campo nu se, yo veo un coste exagerado, y a las multis no les gustan los cambios

Javier Fernández-Sanguino netlag: Pues yo creo que cuando hay oportunidad de negocios, de nuevos servicios, los cambios sí se implementan, y rápido. Fijate en España en los últimos dos años, el cambio en operadores (telefonía móvil)

Horacio J. Peña netlag: europa dice que antes del 2005 habrá completado la transición

ChArLiToS tambien se decia en muchos sitios que UMTS estaria disponible este verano, y eso no es asi. Muchas veces... la cosa se alarga ... y mucho

Javier Fernández-Sanguino Bueno, yo te puedo decir de un operador *gordo* que empezará a operar en toda Europa en el 2003 que está definiendo su red sobre IPv4.

María Jesús Coma: osea, que llegara tarde y mal

Juan A. Campo lo de europa no tenia ni idea, supongo que lo habran estudiado bien (y mejor que la inflaccion y el euro), y en cuanto a los moviles, es verdad han despegado mucho es un nuevo negocio tb.. sip, de acuerdo, si hay negocio, seguro que se expande

weaah no me quedo claro si RSIP es un estandard?

Horacio J. Peña weaah: es mas bien una propuesta que un standard

Javier Fernández-Sanguino weaah: no, está en el proceso de estandarización en el IETF, actualmente es un draft (mira en el chapter de NAT de www.ietf.org)

Juan A. Campo pero ahora estan todas las tecnologicas con perdidas..

Javier Fernández-Sanguino Bueno, también estaban el año pasado con ganancias multimillonarias

Juan A. Campo no se si querran invertir en algo no-seguro-pero-futuro

María Jesús Coma: puedo aportar una cosa ?

Javier Fernández-Sanguino Sí :)

María Jesús Coma: A modo de comentario: el trabajo presentado ayer por el grupo IPv6 de uninet ya está siendo discutido en el ipngwg, y se han generado varias sugerencias adicionales de modificacion de la RFC en esta discusión. A estas alturas... ese operador llega tarde no, tardisimo, porque para entonces.... media red uninet esta ya sobre ipv6, y abriendo brecha !

Horacio J. Peña un comentario más a lo de mjesus, gente de Sun nos ha recomendado presentarlo como un internet draft. > que es un internet draft ?

Javier Fernández-Sanguino MJesus: www.ietf.org

Horacio J. Peña mjesus, es el paso anterior a una rfc

Horacio J. Peña que es algo así como un standard de internet

ChArLiToS bueno ... mjesus... puedo comentar algo sobre tu respuesta ?

ChArLiToS yo creo que un operador que opere en ipv4 quizas no sea tan fracaso, porque no hará gastos que los otros que esten migrando si haran y quizas en corto plazo consiga muchos beneficios hoy dia... invertir en futuro ... te puede costar caro

Javier Fernández-Sanguino ChArLiToS: sí pero los gastos los tendrá en un futuro más cercano, le puede salir caro a la larga. No es igual desplegar con una cosa que cambiarlo a medio camino....

ChArLiToS jfs a lo que me referia, eso que dices de que sale caro a la larga... es que quizas si invierte demasiado... no llegue a la larga sino que muchas se queden en el camino bueno... no me quiero extender en este tema... no soy ningun antiipv6 solo soy un pelin esceptico en el tema :)

Juan A. Campo una cosa mas, la convivencia de ipv6 con ipv4 durara un tiempo (supongo que bastante), como decias, los nodos centrales funciando a ipv6, y los demas a ipv4 son los que favoreceran la convivencia de las dos tecnologias?. Esto, si se ve que funciona, animaria a la transición. O el modelo a seguir, va a ser el de primero una red academica como rediris cuando empezo, bajo ipv6, y luego que el entorno privado se vaya apuntando? Juan A. Campo ups, que chapa ;)

ChArLiToS Supongo que las redes academicas son modelos a seguir por los fabricantes y operadores digamos... plataformas de pruebas

Javier Fernández-Sanguino No lo tengo muy claro, pero parece más lógico un backbone en IPv6. La red académica en RedIris funciono y se expandió porque fue la primera. Sin embargo los experimentos a gran escala (tanto en redes academicas como en 6bone) dan la experiencia y el know-how para los cambios en el otro nivel.

Horacio J. Peña netlag: el camino a ipv6 no necesariamente lo den desde el backbone y no necesariamente desde las redes academicas. Es muy probable que las redes de los operadores de telefonía movil sean las que impulsen ipv6, son al menos aquellas que empujaron a la union europea a dar la directiva de la que hablabamos antes

Cristian Lazo Ok invitemos ChArLitos a ser un nodo IPV6 .

ChArLiToS XD. No hace falta invitarme, porque ya estoy en uno de los nodos de ipv6 de RedIris. No de redIris propio, sino de una de las instituciones conectadas. Aun asi... sigo siendo ipv6 esceptico

Cristian Lazo entonces mejor ahun... ayudanos a sacar Ipv4.

Juan A. Campo ahhh, gracias ChArLiToS, jfs, HoraPe

Juan A. Campo asi que va a ser todo a la vez? Horacio J. Peña netlag: la presión va a ser hecha desde distintos lugares a la vez

ChArLiToS HoraPe... estoy totalmente de acuerdo con la afirmacion de antes ;) los operadores mobiles tiene mucho que decir

Horacio J. Peña sí, quieren meter en internet un montón de equipos conectados permanentemente, necesitan muchas direcciones, les hace falta ipv6 Juan A. Campo bien :), una cosa mas, no existe alternativa al crecimiento de internet que no sea ipv6, no? o si la hay?

ChArLiToS pronto hasta mi tostadora tendra ip X)

Horacio J. Peña netlag: en este momento no se ven muchas alternativas

ChArLiToS bueno... muchos dispositivos.. tampoco necesitan comunicaciones extremo a extremo, pueden salir facilmente por proxys de aplicacion.

Horacio J. Peña hace dos años cuando nosotros empezamos todavía sí, pero ya se ve un encaminamiento hacia IPv6 muy decidido

Horacio J. Peña ChArLiToS: estamos en lo que yo pregunté antes entonces

Juan A. Campo bien HoraPe, me hare la idea de poner ipv6 enable en el kernel dentro de poco :)

Cristian Lazo 5Propongo reinventar Internet pero con IPV6

Horacio J. Peña si preferimos adaptarnos a que el modelo de conexión entre extremos no vale más, IPv4 da para mucho, pero si queremos conservar el modelo debemos saltar a ipv6 y pronto

ChArLiToS si, estoy de acuerdo. Supongo que depende de las aplicaciones que se quieran utilizar, se necesita la idea de extremo a extremo, porque por ejemplo, no hace falta que un mobil descargue un archivo via FTP, de forma directa, si lo puede hacer por proxy

Horacio J. Peña pero si queremos conectarnos a un movil necesitamos poder direccionarlo univocamente, es la forma mas elegante de hacerlo ChArLiToS pero por ejemplo, para videoconferencia si que es necesario, pero... de verdad es necesario direcionarlo univocamente?

Juan A. Campo no se tio.. tampoco se creo internet para paginas "calentorras" y mira ahora como estan :)

ChArLiToS porque normalmente es un dispositivo cliente inicia todas las peticiones

Horacio J. Peña no, de ninguna manera. Cuando dos moviles se comunican (para una llamada, por ejemplo) uno hace de cliente y otro de servidor

ChArLiToS pero a ver... este es un caso de una llamada de telefono, pero para enviar un archivo por ejemplo de un mobil a otro estamos hablando de usar IP como base de toda la red movil. Supongo que hay otras formas que no direccionarlo de forma directa

Horacio J. Peña sí, formas rebuscadas de sortear limitaciones del sistema,

ChArLiToS si, pero quizas alguna de esas formas rebuscadas implique costos quasinulos

Horacio J. Peña pero ya ip no sería ip Horacio J. Peña ip está diseñado sobre la base del modelo de conexion entre extremos. No son costos casi nulos, fijate los problemas que tienes si quieres ipsec sin que valga ese modelo, son altos los costos, quizá no tanto como hacer toda la transicion de la red, pero dedicidamente no son casi nulos, ni siquiera bajos

Juan A. Campo uhm, habran hecho estudios sobre el posible uso de los moviles.. supongo que se usaran como los ordenadores de mano, tan de moda, empiezas con cuantro aplicaciones, y enseguida ves que puede dar mucho mas de si, y se convierten en aparatos muy utiles, asi que los servicios seran similares a los que necesita un pc ahora

ChArLiToS bueno... a todo esto... alguien puede aportar alguna URL o documento que hable sobre estrategias de despliege en una migracion ipv6?

Horacio J. Peña ChArLiToS: hay varios, mirate las paginas del ngtrans

Javier Fernández-Sanguino Bueno chicos, lo siento pero voy a tener que dejaros. Tengo un sólo teléfono en casa y no están muy contentos con que lo acapare (en un futuro, a ver si me pongo ADSL para la próxima conferencia)

ChArLiToS ok jfs... gracias x tu charla

Horacio J. Peña jfs: nos vemos la proxima, muchas gracias por haber venido

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 plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas plas

ChArLiToS ha sido un debate muy agradable Javier Fernández-Sanguino ok.

ChArLiToS por desgracia yo tambien me tengo que marchar

ChArLiToS felicidades a los organizadores