[LACNIC/Politicas] Asignación inicial IPv6

Tue May 31 12:06:14 BRT 2005

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

Hola,

Creo que el punto del /64 no es discutible... Hacerlo implicaría
muchas mas cosas, además del simple hecho de "cuantos" dispositivos
personales se pueden conectar.

1) Los protocolos de "autoconfiguración" tendrían que ser cambiados,
ya que no sería posible enmascarar el MAC address con un espacio
limitado, por lo cual los modos de autoconfiguracion "stateless"
desaparecerían, tendríamos que atarnos a un esquema "stateful", estilo
DHCPv6 para la configuracion, tal cual lo hacemos con IPv4 hoy dia.

2)¿ Cuantos disposivitos puede tener una persona? - la respuesta es
simple.. no lo sabemos!! por eso no podemos "limitarlo", hoy en día el
número de dispositivos que soportan IP (ipv6 mas aun), en un hogar
promedio es muy limitado, pero no podemos estár seguros que mañana
alguien tenga  un jardin botánico y se le ocurra colocar en cada hoja
de cada planta un dispositivo que soporte IPv6, que mida la necesidad
de esta de agua, y sea capaz de enviar una instrucción para que el
disposivito que controla el regado, riegue ese sector.

En pocas palabras, el uso de IPv6 no solo representa un punto en
cuanto a que es una "nueva tecnología", también implica un "cambio" de
paradigma en cuanto a lo que conocemos de redes...

Si bien nos parece "grande" un /32 en este momento, no puedo
garantizar que dentro de 5 años sea muy "pequeño".

Esta es mi opinion ..

saludos

Sebastian Bellagamba wrote:

| Marcelo,
|
| creo que es muy interesante tu planteo, me parece que enriquece
| mucho el punto. Estoy de acuerdo en que los tres puntos son parte
| del mismo fenómeno, y bien podríamos expandir la discusión para
| abarcar a los tres. El asignar un /48 para un móvil, lo mismo que
| la recomendación del IAB (RFC 3177) de asignar el mismo bloque a un
| usuario hogareño que esté conectado por banda ancha ("always-on")
| es una enormidad. POr más devices y gadgets que querramos poner a
| una PAN, a una LAN hogareña, a una LAN de un SOHO, inclusive a una
| mediana empresa, me parece que la necesidad de subredes de cada una
| de esas redes es seguramente muy inferior a 65536 subredes (2^16) y
|  que los hosts que pueden necesitar cada una de esas subredes es
| también muy inferior a 2^64 (algunos millones de millones de
| millones). Necesito un argumento muy fuerte para convencerme de que
| no estamos realizando un derroche fenomenal de direcciones IPv6
| asignando de esta manera. El tema del HD-ratio es también muy
| pertinente. Mantener el 0.8 parece una locura. He leído documentos
| donde se establece que en un /20 de IPv6, manteniendo el HD-ratio
| de 0.8, el nivel de utilización efectivo al llegar a ese 0.8 es del
| 1% del total de direcciones asignadas. Aparentemente, seguimos con
| el derroche.
|
| Creo que los tres son temas que debemos seguir discutiendo. Mi
| punto en términos generales es que debemos ser conservadores al
| principio para garantizarle a IPv6 una larga vida.
|
| Saludos a todos
|
| SB
|
| -----Mensaje original----- De: politicas-bounces at lacnic.net
| [mailto:politicas-bounces at lacnic.net] En nombre de marcelo bagnulo
| braun Enviado el: martes, 31 de mayo de 2005 10:20 Para: Sebastian
| Bellagamba CC: politicas at lacnic.net Asunto: Re: [LACNIC/Politicas]
| Asignación inicial IPv6
|
|
| Hola Sebastian,
|
| comparto contigo las inquetudes en lo que se refiere a la
| conservacion del espacio de direcciones IPv6. Creo que hay tres
| frentes en los que se puede actuar (al menos), a saber:
|
| - el bloque se asignacion a los LIRs (/32) - el tamaño de
| asignacion a los sitios (/48) - el criterio usado para medir la
| utilizacion (HD ratio)
|
| La verdad, es que personalmente, el que me parece menos critico es
| el /32. Mis razones para esto es un tema simplemente del numero
| esperado de LIRs, versus el impacto potencial de los otros
| factores.
|
| El /48 me preocupa fuertemente, sobre todo desde que escucho que
| los operadores de moviles van a considerar cada telefono movil un
| sitio (porque se pueden crear PANs detras de estos) y que entonces
| piensan asignar un /48 a cada telfono movil, lo cual me parece
| excesivo.
|
| El otro tema que tambien me preocupa es el espacio despediciado con
| el HD ratio, que parece resultar en asignaciones
| desproporcionadamente grandes, lo que, si lo juntas con el tema de
| cada telefono movil es un sitio, implica las asignaciones
| desproporcionadas que estamos viendo ultimamente en RIPE
|
| Estos dos temas el /48 y el HD ratio estan siendo fuertemente
| discutidos en el IETF y se estan elaborando documentos sobre el
| tema que parecen al menos interesantes.
|
| Saludos, marcelo
|
|
| El 30/05/2005, a las 23:44, Sebastian Bellagamba escribió:
|
|> Quisiera proponer un cambio de política: la asignación inicial de
|> un /32 en IPv6 me parece muy grande y sugiero que sea reducida.
|>
|> El motivo por el que propongo este cambio es el de la
|> conservación; el hecho de que el espacio de direcciones IPv6 sea
|> muy grande, no lo transforma en infinito. Y ya hemos tenido
|> experiencias en el pasado, con IPv4, sobre políticas de
|> asignación demasiado "generosas".
|>
|> Si lo comparamos con la asignación mínima que hoy utilizamos para
|>  IPv4, vemos que la política vigente hoy otorga una asignación
|> mínima de un /20 en un espacio de 32 bits, o sea que el ISP
|> administra 12 bits. Con la política vigente en IPv6, tomando que
|> de los 128 bits los últimos 64 están reservados para los hosts,
|> estamos entregando 32 bits al ISP, lo que significa 2,66 veces
|> más bits que los que hoy se entregan en IPv4.
|>
|> Si tomamos en cuenta la recomendación del IAB de que los ISPs
|> asignen en IPv6 por defecto a sus clientes un /48 (asignación que
|> también parece enorme), los ISPs contarían con direcciones
|> suficientes para entregar 65536 /48s, producto de los 16 bits que
|> separan un /32 de un /48. Cada uno de esos clientes tendría un
|> total de 2^80 direcciones IPv6 (algo así como
|> 1208925819614629174706176 ips); o bien cada ISP podría contar con
|>  4294967296 redes (2^32) y cada una de ellas podría contener algo
|> así como 18446744073709551616 (2^64) hosts.
|>
|> No les parece una exageración?
|>
|> Propongo, por lo tanto, que discutamos por un lado si un /32 es
|> justificado como asignación mínima y, por el otro, si la
|> recomendación de un /48 como asignación por defecto por parte de
|> los ISPs nos parece correcta.
|>
|>
|> Saludos a todos
|>
|>
|> 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
|>
|
| _______________________________________________ Politicas mailing
| list Politicas at lacnic.net
| http://www.lacnic.net/mailman/listinfo/politicas
|
|
| _______________________________________________ Politicas mailing
| list Politicas at lacnic.net
| http://www.lacnic.net/mailman/listinfo/politicas
|
|

- --
~~~~~~~~~~~~~~~~~~~~~~~~~~
Francisco Obispo
Coordinador del NIC-VE (ccTLD .VE)
(http://www.nic.ve)
GPG Fingerpring: 347C 3FA7 4615 675B 0784  2067 1ACD 3367 928C 9923
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnH1mGs0zZ5KMmSMRAplzAKCY6Rl7lQAPt/lQ12wY9O4NvmylMwCglBcY
0XYrdVfVLUZKhpjHfcwGq24=
=Qasx
-----END PGP SIGNATURE-----