[LACNIC/Politicas] Nueva propuesta de politica (ULA-central)

Sun May 13 18:49:55 BRT 2007

Hola Roque,

El unico motivo por el que el draft se detuvo en el IETF, por deseo expreso
de los autores, en su momento, fue por evitar un conflicto con los RIRs, que
de forma un tanto misteriosa y totalmente fuera de proces, en lugar de
seguir el proceso del IETF (que lor RIRs hubieran acudido a la lista del
IETF), elaboraron un documento que no se hizo publico, cosa que como digo es
bastante irregular.

En este caso, el IETF va a avanzar con el documento, e instruira a IANA que
designe, tal y como especifica el draft, una autoridad central o varias
coordinadas.

Si las comunidades de los RIRs desean no aceptar este tipo de propuestas, lo
que ocurrira sera muy sencillo: IANA no tiene mas remedio que seguir las
instrucciones del IETF, y por tanto creara el registro central por si misma
o designara (lo que parece mas probable) otra autoridad.

Creo que esto seria MUY contraproducente para el sistema de los RIRs, y es
precisamente lo que estoy intentando evitar.

Ademas, seamos consequentes. Tan pronto decimos que no debemos malgastar
espacio de direcciones con propuestas de politicas que en lugar de asignar
/32 asignan /48 o en lugar de /48 /56, y luego decidimos que algo para lo
cual ya hay un bloque reservado (la mitad del FC00::/7), no debemos de
usarlo, sino malgastar direcciones unicast, y facilitar asi que esas
direcciones sean usadas en la Internet Global, cuando precisamente se trata
de evitarlo, y por tanto que puedan competir con IPv6 PI. Creo que no es
nada razonable !

Saludos,
Jordi

> De: Roque Gagliano <rgaglian at antel.net.uy>
> Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
> Fecha: Sun, 13 May 2007 18:18:50 -0300
> Para: LACNIC Policy mailling list <politicas at lacnic.net>
> Asunto: Re: [LACNIC/Politicas] Nueva propuesta de politica (ULA-central)
> 
> Jordi,
> 
> Viendo lo que ha pasado en ARIN con la aprobación de las micro-
> asignaciones para infraestructura interna y pensando que en cada caso
> se asigna un /48. Pensando que si reservamos un /31 para este fin en
> total se tendrían 120K proveedores que serían posible atender.  ¿no
> es mejor seguir este camino que confiar que el draft será aprobado y
> que el o los RIRs podrán hacer uso del espacio reservado además de
> ponerse de acuerdo sobre cómo usarlo?
> 
> Roque
> 
> 
> On Apr 13, 2007, at 6:58 AM, JORDI PALET MARTINEZ wrote:
> 
>> Hola,
>> 
>> Esta es una nueva propuesta de politica, referida al tema de ULA-
>> central que
>> tambien he enviado ya a los demas RIRs, aunque solo en el caso de
>> AfriNIC se
>> ha publicado ya en la lista de politicas (los demas estan revisando el
>> texto, pues en esos casos los co-chairs de politicas revisan antes los
>> textos).
>> 
>> Por cierto, al revisar la politica actual, he visto, tanto en la
>> version en
>> web como en pdf, inconsistencias en la numeracion de las secciones
>> 2 y 3 ?
>> 
>> 
>> 
>> Número:   2007-xx
>> Título de la propuesta de política:   ULA-central
>> Autor:     Jordi Palet Martinez, Consulintel
>> Versión:   1.0
>> Fecha de envío:   13/4/2007
>> Estado:   Fase de Discusión
>> Grupo de trabajo sugerido para discusión y publicación:   Grupo de
>> Políticas
>> Tipo de propuesta:   Modificación
>> Termino de la política:   Permanente
>> Documento de políticas afectado:   Politica de asignaciones de IPv6
>> 
>> 
>> Sumario de la Propuesta:
>> 
>> El objetivo de esta politica es permitir la asignacion de bloques IPv6
>> dentro del prefijo denominado "Centrally Assigned Unique Local IPv6
>> Unicast
>> Addresses" (ver http://tools.ietf.org/html/draft-ietf-ipv6-ula-
>> central-01,
>> ULA-central), a personas juridicas o fisicas (organizaciones o
>> individuos,
>> respectivamente) que asi lo requieran.
>> 
>> Estas direcciones son globalmente unicas y solo para comunicaciones
>> locales,
>> usualmente dentro de un sitio o conjunto de sitios, y no se espera
>> que sean
>> encaminadas en la Internet global.
>> 
>> El prefijo FC00::/7 ya esta reservado por IANA para ULA (el bit 8
>> determina
>> si son asignadas local o centralmente, es decir si se trata de ULA o
>> ULA-central).
>> 
>> 
>> Borrador del Texto de la Política:
>> 
>> Nuevo texto, posiblemente como seccion 2.10
>> 
>> 2.10. ULA-central
>> ULA-central se refiere a direcciones unicast locales y unicas,
>> centralmente
>> asignadas, como se describe en el documento de IETF "ietf-ipv6-ula-
>> central"
>> (cualquiera que sea la ultima version disponible, bien sea Internet
>> Draft,
>> RFC o STD). El bloque ULA-central esta dentro del prefijo FC00::/7,
>> con el
>> bit 8 a 0.
>> 
>> Nuevo texto, posiblemente como seccion 5.6
>> 
>> Cualquier organización o individuo que precise un /48 del bloque
>> ULA-central, podra requerir su asignacion, una vez que el
>> correspondiente
>> contrato sea ejecutado y las correspondientes cuotas de membresia
>> hayan sido
>> satisfechas (a ser determinadas por el directorio).
>> 
>> Tengase en cuenta que en muchos casos, las direcciones ULA localmente
>> asignadas (RFC4193) son preferidas, y solo se espera que grandes
>> sitios
>> gestionados prefieran el uso de asignaciones centrales. Es importante
>> destacar tambien que el prefijo ULA (FC00::/7) no es encaminable en la
>> Internet global (y concretamente no ha sido diseñado para ser
>> utilizado como
>> espacio IPv6 PI/portable) y consecuentemente debe de ser filtrado.
>> 
>> 
>> Justificación:
>> 
>> a. Argumentos a favor de la propuesta
>> 
>> En algunas situaciones, especialmente grandes sitios en
>> organizaciones, que
>> en realidad ya tienen bloques IPv6 Unicast Globales, se podria
>> requerir un
>> bloque adicional para la infraestructura interna.
>> 
>> Este bloque adicional puede ser utilizado para varios propositos,
>> tales como
>> VPNs, comunicaciones sitio-a-sitio, evitar doble/multiple-cara en DNS,
>> soporte de aplicaciones que son sensitivas a tiempos de
>> convergencia largos
>> (tales como VoIP), etc.
>> 
>> El documento de ARIN "Micro-allocations for Internal Infrastructure"
>> (propuesta de politica 2006-2, presentada por Jason Schiller y
>> otros, y
>> disponible en http://www.arin.net/policy/proposals/2006_2.html),
>> describe la
>> necesidad de este tipo de bloque adicional para propositos de
>> re-convergencia BGP, seguridad de infraestructura interna y los
>> motivos por
>> los que las direcciones ULAs asignadas localmente (RFC4193) no son
>> apropiadas para esta mision. Esta propuesta de politica ya fue
>> aceptada por
>> ARIN y es parte de su NRMP.
>> 
>> El uso de bloques IPv6 Unicast Globales para este tipo de usos
>> podria ser
>> considerado como un desperdicio, mas aun cuando IANA ya tiene
>> reservado el
>> prefijo (FC00::/7) para este proposito.
>> 
>> 
>> b. Argumentos en contra de la propuesta
>> 
>> Ninguno previsto. Sin embargo, es necesario recalcar que el ambito
>> original
>> de ULA-central es para grandes sitios gestionados y todos los demas
>> casos
>> deberian utilizar ULAs asignadas localmente, tal y como indica el
>> RFC4193.
>> El mismo documento indica las razones por las que este prefijo no
>> es util
>> como espacio portable IPv6 (PI), y sera filtrado en la Internet
>> global.
>> 
>> 
>> Reconocimientos:
>> 
>> Deseo reconocer a los autores del documento ULA-central en IETF,
>> Bob Hinden
>> y Brian Haberman, asi como a todos aquellos que han contribuido a
>> dicho
>> trabajo.
>> 
>> 
>> Saludos,
>> Jordi
>> 
>> 
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
> 
> -------------------------------------------------------------
> Roque Gagliano
> ANTEL - URUGUAY
> rgaglian at antel.net.uy
> 
> 
> 
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.