Re: [LACNIC/Politicas] Politica de microasignación Ipv6

Thu Sep 29 07:54:48 BRT 2005

Hola a todos,

creo que es importante hacer una distincion entre microasignaciones 
para NAPs y microasignaciones para ccTLDs. en particular, es relevante 
notar que lor prefijos asignados a los ccTLDs deben ser globalmente 
encaminables, ya que la funcion del servidor ccTLD asi lo require.

Sin embargo no creo que este sea el caso de asignaciones para los naps. 
Digo, creo que las aisgnaciones a los naps no requiren ser globalmente 
encaminables (ya que las direcciones de los naps deben ser usadas solo 
por los participantes del NAP y estas no tiene porque ser alcanzables 
desde fuera del NAP (corrijanme si me equivoco...)
En particular, la politica de RIPe, le asigna por defecto un /64 a los 
naps

Por ende, en el caso de los ccTLDs, creo que hay que asignar un /32, 
porque si bien los prefiijos de microasignaciones salen de un prefijo 
bien conocido que no deberia ser filtrado, creo que para esta 
infraestrcutura quqe es tan critica para el funcionamiento, se 
justifica curarse en salud y asignar un /32.

Para los naps, creo que esto no se aplica y como mucho creo que se les 
deberia asignar un /48 (si quieren podemos cambiar la politica para 
reducirlo a un /64...)

saludos, marcelo

El 28/09/2005, a las 16:35, Ricardo Patara escribió:

> Hola Jesús, como estas?
> La política de micro asignación para los IXPs, NAPs, infraestructuras
> criticas indica que se puede asignar prefijos desde el /48 hasta el
> /32.
>
> Estoy de acuerdo que si es un IXP, y por esto, el prefijo será
> utilizando solamente en la LAN de IXP, un /48 sirve. Incluso, ya hubo
> asignación asi para un IXP de la región.
>
> Ahora, hay el tema de las recomendaciones de filtrados para
> IPv6. Algunos indican que se debe aceptar anuncios de bloques con
> prefijos mas largos que /32. Y por esto, hay casos en que la
> organización puede no necesitar de un /32 pero por garantías de que
> dicho bloque sea visible en la internet, lo solicita.
>
> La idea es que las asignaciones /48 hechas por los RIRs esten todas en
> un mismo rango y que este rango este descrito en la pagina web. Asi es
> posible saber para cuales prefijos se debe aceptar anuncios de /48.
>
> Hay un draft que propone las reglas para anuncios. es el:
> draft-blanchet-v6ops-routing-guidelines-00.txt
>
> Y en el, se indica que para los bloques "Global Unicast", se debe
> aceptar anuncios de /48 o mas cortos.
>
> ricardo
>
> -- 
>   L A C N I C
>
> On Wed, Sep 28, 2005 at 10:06:49AM -0400, Jesús Martínez wrote:
> | Lo que dice Marcelo es cierto, ya esta resuelto, lo que no estoy muy 
> claro
> | es que se este aplicando como dice la política y eso es otro 
> problema, llamo
> | la atención que a los NAP o IX se les pudiera estar asignando un 
> ::/32 y
> | esas son demasiadas direcciones cuando realmente no necesitan tanto, 
> incluso
> | un ::/48 es mucho también, hay ejemplos.
> | Alguien puede revisar esto??
> | Sl2s
> | Jesús
> |
> |
> | ----- Original Message -----
> | From: "marcelo bagnulo braun" <marcelo at it.uc3m.es>
> | To: "Francisco Obispo" <fobispo at nic.ve>
> | Cc: <politicas at lacnic.net>
> | Sent: Wednesday, September 28, 2005 4:06 AM
> | Subject: Re: [LACNIC/Politicas] Politica de microasignación Ipv6
> |
> |
> | > Hola Francisco,
> | >
> | > Dentro de la politica actual de asignaciones de IPv6
> | > (http://lacnic.net/sp/politicas/ipv6.html) esta contemplada la
> | > asignacion de prefijos para infraestrcuutras criticas (ver seccion 
> 5.5)
> | > y los servidores ccTLD estan explicitamente contemplados como uno 
> de
> | > los candidatos claros, por lo que solamente tendrias que aplicar y 
> creo
> | > que deberias obtenerlo.
> | >
> | > Ademas, estas asignaciones salen de un prefijo espaicalmente 
> reservado
> | > para esto, de forma que se no sean filtrados (lo que tu llamas
> | > whitelist).
> | >
> | > De modo que creo que lo que pides esta ya disponible y solo tenes 
> que
> | > aplicar para conseguirlo
> | >
> | > Saludos, marcelo
> | >
> | > El 27/09/2005, a las 20:47, Francisco Obispo escribió:
> | >
> | > > -----BEGIN PGP SIGNED MESSAGE-----
> | > > Hash: SHA1
> | > >
> | > > Estimados,
> | > >
> | > > Estuve conversando en privado con algunos amigos miembros de la 
> lista
> | > > de politicas de LACNIC, y surgió la inquietud sobre las
> | > > microasignaciones IPv6 para infraestructuras críticas.
> | > >
> | > > En el NIC-VE queremos instalar un esquema de Anycast (v4 y v6) a 
> fines
> | > > de distribuir geográfica y topológicamente los servicios de DNS 
> del .VE
> | > >
> | > > Actualmente, el CNTI cuenta con una asignación /32, sin embargo, 
> no
> | > > puedo tomar un bloque /48 para este fin, debido a que no podría
> | > > anunciar este bloque en otros sitios que no estén conectados
> | > > directamente al CNTI, inclusive, nisiquiera podría re-anunciarlo 
> por
> | > > otro enlace debido al problema del multihomed Ipv6. Utilizar un 
> /32
> | > > para 2 o 4 servidores sería bastante irracional.
> | > >
> | > > Sin embargo, creo que LACNIC podría contribuir con un bloque (/32
> | > > quizás) designado para infraestructura crítica, de la misma 
> forma que
> | > > lo hacemos con Ipv4, de manera tal que se puedan delegar /48s a 
> este
> | > > tipo de requerimientos. (no es que un /48 sea racional, pero es 
> mejor
> | > > que un /32!)
> | > >
> | > > Ahora bien, para poder utilizarlo en la Internet, y no ser 
> bloqueados,
> | > > propondría la creación de un WHITELIST, conjuntamente con la 
> redacción
> | > > de un RFC o algo así que nos permita colocar allí estas redes de
> | > > manera tal que estos prefijos no sean bloqueados por algunos 
> routers.
> | > > (aunque no hay garantía igual, pero sería cuestión de irse 
> poniendo al
> | > > dia)
> | > >
> | > > Este Whitelist, se podría extender no solo las infraestructuras
> | > > críticas, si no también los prefijos asignados y "validos" para
> | > > efectos de LACNIC, de esta forma, podríamos contribuir con el 
> tema de
> | > > Seguridad, y  a su vez , poder "sacar" de la lista aquellos 
> bloques
> | > > que lo amerite.
> | > >
> | > > Esto podría contribuir a tener cierto control sobre lo que 
> conversamos
> | > > en el pasado foro público sobre las herramientas que tenia 
> LACNIC para
> | > > "enforzar" sus politicas. Si mañana se diseña una politica para 
> los
> | > > problemas de seguridad, SPAM, ataques DoS, etc. seía una 
> herramienta
> | > > útil para comenzar a hacer algo.
> | > >
> | > > ¿ Que opinan ustedes ?
> | > >
> | > >
> | > >
> | > >
> | > >
> | > > - --
> | > > ~~~~~~~~~~~~~~~~~~~~~~~~~~
> | > > 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.4.1 (GNU/Linux)
> | > > Comment: Using GnuPG with Thunderbird - 
> http://enigmail.mozdev.org
> | > >
> | > > iD8DBQFDOZPDGs0zZ5KMmSMRArc+AJ44hLzp3cyNathprhIk9SZY7iz7DwCePJtA
> | > > jOXqkuOJjsc/mUNrY4osaDc=
> | > > =GiIR
> | > > -----END PGP SIGNATURE-----
> | > >
> | > > _______________________________________________
> | > > 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
> |
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> http://www.lacnic.net/mailman/listinfo/politicas
>