[LACNIC/Politicas] Cambios en la política de IPv6 - 2

Thu Apr 6 15:41:49 BRT 2006

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hola Christian.

Estoy deacuerdo.. de hecho, son dos temas distintos... ahora bien.. lo
que creo que si estamos en sintonía, es que el HD-Ratio de 0.8 es _muy_
bajo para IPv6... solo quedaría analizar, que dependiendo  de que
vayamos a utilizar /48s o /56s para usuarios finales, (como una segunda
propuesta), tendríamos que evaluar cual sería el HD-Ratio más adecuado,
si 0.94 o 0.96...

Saludos

ARG-O'FLAHERTY, CHRISTIAN wrote:
> Francisco/Sebastian, tal vez podamos separar el tema en dos. Por un lado el cambio en el tamaño del bloque mínimo que propone Sebastian y que ya fue presentado anteriormente. Por otro lado analizar cual es el valor de HD ratio que deseamos utilizar para IPv6. 
> 
> Tal vez Sebastian puedas quitar de la propuesta la mención en el último párrafo al HD ratio para que los cambios de redacción necesarios no impliquen la modificación de otra parte de la politica como es el valor usado para HD-ratio. 
> 
> Qué les parece?
> 
> Christian
> 
> -----Original Message-----
> From: politicas-bounces at lacnic.net [mailto:politicas-bounces at lacnic.net] On Behalf Of Francisco Obispo
> Sent: Miércoles, 05 de Abril de 2006 10:59 a.m.
> To: politicas at lacnic.net
> Subject: Re: [LACNIC/Politicas] Cambios en la política de IPv6 - 2
> 
> Hola Sebastián.
> 
> 
> Bajo esta premisa, no recomendaría el HD Ratio de 0.94, ya que con ese valor, ya que solo se alcanzaría una utilización de 36.86% de los recursos disponibles, 16.777.216 /56s por cada /32!
> 
> Para lograr obtener al menos un 50% sería necesario utilizar un HD Ratio de 0.96, el cual -en el caso de mantener la política del /48- aumentaría el requerimiento a un 64.17% de utilización de los recursos.
> 
> Ahora bien... en Venezuela somos alrededor de 25millones de personas, y existen un gran numero de ISPs que prestan servicios.... supongamos que fuesen 10..
> 
> Suponiendo que todos implementaran IPv6, y que dieran servicios a usuarios finales.. (aún no lo hacen), estamos hablando de 160.777.216 de /56s...  que probablemente no llegemos a utilizar en un futuro cercano.. :-S
> 
> Esto podría traer como consecuencia que solicitar bloques adicionales a LACNIC se hiciera sumamente eventual, por lo cual, podríamos ponernos en una situación dificil al solicitar bloques adicionales al IANA, poniendonos posiblemente en desventaja con el resto de los RIRs.
> 
> Si bien estoy deacuerdo con evitar el derroche de direcciones, tenemos que revisar el panorama global, para asegurarnos que no quedemos en desventaja.
> 
> Saludos y un abrazo
> 
> 
> 
> 
> Sebastian Bellagamba wrote:
> 
> 
>>>Estimados,
>>>
>>>El segundo cambio de propongo tiene que con las provisiones que se 
>>>establecen en Políticas de registración para la asignación y 
>>>adjudicación de direcciones IPv6 respecto al tamaño de las 
>>>asignaciones que deben realizar los LIRs.
>>>
>>>El punto 5.4.1 Asignación del espacio de direcciones establece que:
>>>
>>>
>>>
>>>"Las asignaciones deben ser realizadas de acuerdo con las 
>>>recomendaciones existentes [RFC3177,RIRs on 48], las cuales resumimos 
>>>aquí como:
>>>
>>>/48 en el caso general, excepto para suscriptores muy grandes /64 
>>>cuando cuando se conoce por diseño que una y solo una subred es 
>>>necesaria /128 cuando se conoce absolutamente que uno y solo un 
>>>dispositivo se está conectando."
>>>
>>>De esto se desprende que la política establece que la asignación 
>>>mínima para un sitio final por defecto es un /48, y las otras son sólo 
>>>excepciones.
>>>
>>>De esta manera, un usuario de banda ancha, una pequeña empresa o una 
>>>gran corporación obtendrían como asiganción inicial un /48.
>>>Separando de los 128 bits que componen una dirección IPv6 los últimos 
>>>64 bits (que están reservados a la interfase), cada uno de estos 
>>>usuarios podrían utilizar el espacio asignado para generar hasta 65536 
>>>subredes (2^16, siendo los 16 bits los que surgen de 64-48). Entiendo 
>>>que pocos de esos usuarios finales tienen efectivamente una necesidad 
>>>de manejar 65536 subredes, por lo que realizar esta asignación 
>>>conlleva un alto grado de ineficiencia en la distribución de 
>>>direcciones con el consiguiente desperdicio.
>>>
>>>Por lo tanto, propongo que se modifique la política de manera tal que 
>>>permita a los LIRs la asignación de /56s para el caso de usuarios 
>>>finales que sean pequeñas y medianas empresas, residenciales o redes 
>>>personales, donde el número de subredes potenciales exceda 1 pero no 
>>>exceda 256. Además, propongo que se cambie el párrafo referente a las 
>>>asignaciones /48, de manera que refiera específicamente a asignaciones 
>>>a grandes empresas y entornos corporativos finales cuyo requerimiento 
>>>es superior a 256 subredes. Tambiém, propongo que se tome como por 
>>>defecto la asignación /56, tanto para la definición de Utilización 
>>>(Punto 2.7) como para el cálculo del HD Ratio.
>>>
>>>Es de notar aquí que, de aprobarse este cambio, numerosas correcciones 
>>>deberán realizarse al texto de esta política, dada la reiterada 
>>>aparición del /48 como tamaño por defecto de asignación.
>>>
>>>Saludos
>>>
>>>Sebastián Bellagamba | Director www.ssatelital.com.ar
>>>
>>>Tel: 5411 6334 1000 | Fax: 5411 6334 1010 Tte. Gral. J. D. Perón 949, 
>>>5º Piso, C1038AAS, Buenos Aires, Argentina
>>>
>>>sbellagamba at ssatelital.com.ar
>>>
>>>_______________________________________________ Politicas mailing list 
>>>Politicas at lacnic.net http://www.lacnic.net/mailman/listinfo/politicas
>>>
>>>
> 
> 
> 
> --
> ~~
> Francisco Jose Obispo Semidey
> Jefe de Oficina de NIC-VE - NIC-VE Manager Centro Nacional de Tecnologias de Informacion - http://www.nic.ve Caracas - Venezuela
> 
> 
> 
> --
> ~~
> Francisco Jose Obispo Semidey
> Jefe de Oficina de NIC-VE - NIC-VE Manager Centro Nacional de Tecnologias de Informacion - http://www.nic.ve Caracas - Venezuela 

_______________________________________________
Politicas mailing list
Politicas at lacnic.net
http://www.lacnic.net/mailman/listinfo/politicas

Esta comunicación es confidencial y puede contener información cuya
divulgación esté restringida por la ley o en virtud de obligaciones de
confidencialidad asumidas por acuerdos escritos. Si usted no es su
destinatario, por favor advierta que cualquier divulgación, distribución
o copia de esta comunicación le está estrictamente prohibida. Si usted
recibió este mail por error, agradeceremos tenga a bien informar esa
circunstancia al remitente mediante comunicación a la dirección de
e-mail o al número telefónico : (5411) 5170-0000, y le solicitamos
asimismo que por favor proceda a borrarlo de su computadora. Por favor
no copie ni use la información contenida en este mail para ningún
propósito y no divulgue su contenido a ninguna otra persona.

This communication is confidential and may contain information that is
exempt from disclosure by law or pursuant to confidentiality obligations
assumed by written agreement. If you are not the intended recipient,
please note that any dissemination, distribution, or copying of this
communication is strictly prohibited. If you receive this e-mail in
error, please notify the sender immediately at the electronic mail
address or phone number : (5411) 5170-0000  and delete the information
from your computer. Please do not copy or use it for any purpose nor
disclose its contents to any other person.

- --
~~
Francisco Jose Obispo Semidey
Jefe de Oficina de NIC-VE - NIC-VE Manager
Centro Nacional de Tecnologias de Informacion - http://www.nic.ve
Caracas - Venezuela
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFENWDtGs0zZ5KMmSMRAtK+AJ9+c3vwKzS6e2V8jT/wm9TeOy1UyACdExJY
tNar0woaU38Tbk4P2RI0srM=
=w2nN
-----END PGP SIGNATURE-----