[LAC-TF] FAQ: Grupo2 - Pregunta "a"

[Jorge Villa]

Hola a tod at s, como estan?

Pues como que se quedo en el aire la respuesta de la nueva pregunta del FAQ, 
luego de la ultima respuesta de Fernando haciendo referencia a la RFC5461.

La pregunta a responder es la siguiente:

¿Es posible estimar la inversión de dinero requerida para actualizar 
aplicaciones, de manera que funcionen correctamente sobre IPv6?

Pienso que se han aportado muchos elementos acerca de que seria necesario 
modificar o de aspectos tecnicos de implementacion, pero seguimos sin 
responder exactamente la pregunta.

Yo creo que NO es posible estimar la inversion de dinero que se requiere 
para actualizar aplicaciones IPv4, de manera que funcionen correctamente 
sobre IPv6, producto que ello dependera de varios factores. Entre ellos, 
creo fundamentales los siguientes:

- arquitectura de la aplicacion
- tecnologias empleadas
- calidad del codigo fuente
- capacitación del personal
- sistemas operativos
- arquitectura de red

La arquitectura de la aplicacion se relaciona con si la aplicacion es 
monolitica, o es una aplicacion cliente-servidor (basadas o no en web), y 
por supuesto de la modularidad con que haya sido diseñada la aplicacion. En 
algunos casos puede necesitarse rehacer un modulo, pero en otros casos puede 
necesitar rehacerse un porciento significativo del producto. Si la 
aplicacion tiene clientes Web, entonces sera necesario rehacer solo el 
servidor, pero si tiene un cliente personalizado, con seguridad habra que 
trabajar tanto en el cliente como en el servidor.

Tambien existen multiples tecnologias con las que puede construirse una 
aplicacion. Algunas son mas simples y otras mas complejas. En muchos casos 
se emplean bibliotecas estandares y en otras bibliotecas diseñadas a la 
medida. Puede suceder que tambien alguna de las tecnologias con que se ha 
construido una aplicacion se haya descontinuado por sus fabricantes, y por 
tanto haya que rehacer el producto con base en una nueva plataforma.

Los codigos fuentes son otro dolor de cabeza para muchas aplicaciones, ya 
que en algunos casos estos no estan disponibles, otras veces estan 
disponibles pero no estan hechos con calidad o no estan comentados 
adecuadamente, y eso complica la legibilidad del codigo, sobre todo cuando 
quien tiene que actualizar la aplicacion no fue su diseñador original.

El personal que participa en el proceso tiene que estar bien capacitado. Hay 
programadores que no dominan ni siquiera aceptablemente la tecnologia IP, y 
logran hacer aplicaciones que funcionen en red adecuadamente confiando en 
las librerias de comunicacion de los paquetes de desarrollo de aplicaciones. 
Para entender correctamente la RFC5461 y algunos de los otros draft al 
respecto, hay que saber de tecnologia IP. Por lo general, en este proceso de 
actualizacion debe intervenir un equipo multidisciplinario.

Los sistemas operativos tambien influyen, segun la calidad de la 
implementacion del stack IPv6 en los mismos. Tambien puede existir un costo 
asociado a sistemas operativos, ya que si la aplicacion actual se ejecuta en 
Windows 98 o 2000, en W98 no hay soporte IPv6 y en W2K hay soporte limitado, 
por tanto habra que crear al menos a nivel experimental, una infraestructura 
basada en XP o Vista.

La arquitecturas de red puede complicar en mayor o menor medida el proceso 
de desarrollo de aplicaciones. Es mucho mas facil crear un entorno de 
desarrollo y/o actualizacion a nivel local (para aplicacion para Internet 
desde PCs) que cuando hablamos de aplicaciones para dispositivos moviles, 
donde hay otros aspectos a tener en cuenta.

Como quiera que tras cada aplicacion hay un cerebro diferente, las formas de 
pensar y de llegar a las soluciones difieren y por esto es muy dificil 
cuantificar el proceso (a grosso modo). Tambien las condiciones tecnicas en 
que se desarrolle el proceso influyen, y por supuesto que la inversion en 
capacitacion es fundamental.

Bueno, hasta aqui mi respuesta a la pregunta A del grupo 2 del FAQ. Que siga 
la ronda.

Saludos,
Jorge
----- Original Message ----- 
From: "Fernando Gont" <fernando at gont.com.ar>
To: <lactf at lac.ipv6tf.org>
Sent: Monday, March 02, 2009 1:34 PM
Subject: Re: [LAC-TF] FAQ: Grupo2 - Pregunta "a"


> Hola, Nicolás,
>
> Comentarios entre lineas....
>
>
>> Le había echado un vistazo hace un tiempo a la RFC que tu propusiste.
>> La consulta que te hago es sobre que es lo que te parece que
>> tendríamos que agregar o tener en cuenta, en particular para las
>> aplicaciones.
>> ¿Te referís en estos casos a entornos mixtos IPv4-IPv6, donde por
>> ejemplo, una aplicación debe "lidiar" con los errores derivados de
>> time-outs,
>
> En aquellos casos en que una se publican RRs (resource records) AAAA
> apra un determinado nombre de dominio, y la conectividad IPv6 es
> limitada, se corre el peligro de caer en el escenario de "grandes
> esperas antes de poder establecer una conexion" que se describe en el
> RFC mencionado. Para el caso de aplicaciones interactivas, esto es
> directamente intolerable (ver referencias en el RFC.. aunque tambien
> puedo aportar otras).
>
>
>
>> que no sean manejados directamente por los módulos que
>> manejan las conexiones correspondientes o por ejemplo para
>> aplicaciones de tiempo real o similares?
>
> Esta cuestion es muy dificil de manejar. En primer lugar, porque
> tradicionalmente NO se maneja a nivel TCP, entonces termina siendo
> responsabilidad de la aplicación. EN segundo lugar, porque la mayoria de
> las aplicaciones no imponen timeouts apra el establecimiento de conexión.
>
> Ajeno al workaround explicado en RFC 5461 (que puede NO funcionar, en
> caso que no se generen mensajes ICMP), hay algunas otras alternativas,
> como las descriptas en este I-D:
> http://tools.ietf.org/id/draft-gont-tcpm-connection-delays-00.txt
> Si bien recuerdo, la gente de Mac hace algo de esto.
>
> En cualquiera de los casos, todavia no existe una solucion completa a
> esta cuestion, y conozco de proveedores de Internet que han encontrado
> grandes problemas debido a esta cuestión. Por ej., la gente de NTT Japón
> incluso ha hecho presentaciones sobre esta cuestión en algunas
> conferencias (si alguien las desea, puedo buscar las diapositivas
> correspondientes).
>
>
>
>> Creo que tu aporte y tus conocimientos al respecto aportarán mucho en
>> esta fase de las FAQ.
>
> En "alto nivel", la cuestion es que publicar registros AAAA apra nombres
> de dominio que tambien son accesibles mediante IPv4 puede llevar a
> grandes demoras en el establecimiento de conexion, que apra aplicaciones
> interactivas resultaria directamente inaceptable.
>
> En lo que se refiere al workaround propuesto/descripto en RFC 5461, apra
> que funcione se necesitan dos cosas:
>
> * Que las implementaciones de TCP funcionen como lo describe el
> documento (Windows *no* lo ahce asi, por ejemplo... aunque LInux y e.g.
> NetBSD *si* lo hacen)
>
> * Que en aquellos puntos de la red donde se limita la conectividad IPv6,
> se generen errores ICMPv6 cuando se tenga queo que rutear algun paquete
> IPv6, pero no se pueda hacerlo por falta de conectividad, etc.
>
>
> En lo que hace a las "conexiones paralelas" descriptas en
> http://tools.ietf.org/id/draft-gont-tcpm-connection-delays-00.txt, esto
> deberia implementarse a nivel aplicacion, lo que agergaria complejidad a
> las aplicaciones (y ajeno a eso, la mayoria de las aplicaciones NO hacen
> esto).
>
> Cualquier cosa en la que pueda ayudar, estoy a tus ordenes.
>
> Un abrazo,
> -- 
> Fernando Gont
> e-mail: fernando at gont.com.ar || fgont at acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>
>
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.