[LAC-TF] Fwd: BCP 157, RFC 6177 on IPv6 Address Assignment to End Sites

[Jorge Villa]

Fernando, como estas?

Los que estamos en este foro, intentamos que IPv6 sea una realidad en 
nuestra region, y creo que todos estos debates son muy utiles para poder 
esclarecer aspectos en duda, y el contraste de opiniones nos permite 
rectificar puntos de vista y hacernos una mejor opinion en muchos aspectos, 
y en otros consolidar posiciones.

Como bien dices, llevamos 15 añitos de espera (creo que son demasiados), 
pero bueno... seguimos en la batalla.

Mi comentario anterior estaba relacionado con una percepcion puramente 
subjetiva que he encontrado en algunas personas en todo este tiempo, que de 
cierta manera siguen viendo "determinada experimentalidad" en IPv6, y en 
consecuencia no siempre toman en serio su adopcion. IP (ya sea v4 o v6) es 
un protocolo vivo, y por tanto sujeto a constantes cambios, pero no 
olvidemos a los detractores de v6 que tenemos sueltos por ahi. Esta 
"experimentalidad" esta dada entre otros aspectos, por la existencia de 
multiples mecanismos de transicion, los propios debates respecto a NAT en el 
IETF y la industria, y ahora tambien puede sumarse a esa percepcion, este 
nuevo cambio en el tema de direccionamiento. Por eso pienso que es 
importante para los que tratemos de promover el tema, actualizar estas cosas 
y por demas explicarlas coherentemente. Coincido contigo en que hay que 
convivir con este periodo de inestabilidad en la red. Es un mal necesario. 
;-)

Hay un parrafo de la RFC6177 que permite preveer nuevas modificaciones en 
este sentido (acorde a la experiencia que se vaya obteniendo):

   This document does not make a formal recommendation on what the exact
   assignment size should be.  The exact choice of how much address
   space to assign end sites is an issue for the operational community.
   The IETF's role in this case is limited to providing guidance on IPv6
   architectural and operational considerations.  This document provides
   input into those discussions.  The focus of this document is to
   examine the architectural issues and some of the operational
   considerations relating to the size of the end site assignment.

Respecto a las implementaciones que mencionaba, la gran mayoria (para no ser 
absoluto, ya que siempre aparecen sorpresas) de las implementaciones de 
6to4, siguen la RFC3056, y en consecuencia asignan /48 y no /56. La RFC6177 
hace obsoleta la RFC3177, pero no actualiza la RFC3056. Como quiera que son 
componentes fundamentalmente de software, pienso que no sea grave lograr una 
actualizacion.

Un abrazo,
Jorge

----- Original Message ----- 
From: "Fernando Gont" <fernando at gont.com.ar>
To: <lactf at lac.ipv6tf.org>
Cc: "Jorge Villa" <villa at reduniv.edu.cu>
Sent: Wednesday, March 30, 2011 8:07 PM
Subject: Re: [LAC-TF] Fwd: BCP 157, RFC 6177 on IPv6 Address Assignment to 
End Sites


> On 30/03/2011 12:11 p.m., Jorge Villa wrote:
>
>> Aun cuando la idea puede ser acertada, pienso que puede provocar
>> tambien un retraso en la adocpcion de IPv6 como estandar de facto.
>
> Por que habria de retrasar esto la adopcion de v6? -- Anyway... ya
> esperamos mas de 15 años... :-)
>
>
>> Aun la red no es IPv6 estable (en el sentido de masividad en su
>> empleo) y ya estamos modificando reglas basicas.
>
> Este caso particular seria lo de menos.
>
> Antes de ser desplegado, se han hecho ya millones de parches, desde las
> reglas para seleccion de direcciones, a modificaciones en la
> arquitectura de direccionamiento, deprecacion del Routing Header, etc.
>
>
>
>> Tambien hay que ser cuidadosos con esto, porque hay diversas
>> implementaciones actuales que no contemplan estos cambios,
>
> Cual es el cambio que no contemplan?
>
>
>> y muchos pueden suponer "un periodo de inestabilidad" y pretender
>> mostrar cautela y seguir explotando IPv4 hasta que no les quede mas
>> remedio, y asi dar tiempo a que el mundo IPv6 llegue a una postura
>> unica respecto a estos temas.
>
> La red IPv6 va a tener un grado de "inestabilidad" no en si por este
> tema, sino por su complejidad (tecnologias de transicion, NATs, tuneles,
> etc.), implementaciones inmaduras, y falta de paridad de features entre
> equipos IPv6 e IPv4.
>
> Hay que aprender a convivir con esta idea.... y aceptarla. Y hacer,
> dadaslas circunstancias, lo mejor que se pueda.
>
> 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
>
>
>
>
>
> PREVENCIÓN ES SALUD. TODOS PODEMOS LOGRARLO.
> 


PREVENCIÓN ES SALUD. TODOS PODEMOS LOGRARLO.