[LACNIC/Politicas] Revision de politica - Asignaciones IPv6 Independientes del Proveedor (PI) para organizaciones-usuario-final

Mon Mar 19 12:50:13 BRT 2007

Hola Roque,

Yo siempre he dicho de antemano que no estaba a favor de PI, pero estoy aun
*mucho* mas en contra de que haya PI en dos regiones (ARIN y APNIC) y no en
el resto.

Pongo en la balanza mi opinion de PI y la de si unas regiones tienen que
estar pagando los "platos rotos" (entiendas coste de slots de routing) de
las otras, y no poder optar a ello, y prefiero optar a PI.

Creo que hay una diferencia importante entre PI, que es controlado y que
permite n prefijos mas en las tablas de routing, que la desagregacion que no
es controlado y permite a cada ISP desagregar sin limites.

Ademas, por lo que entiendo, es mas facil utilizar comunidades para TE que
para multihoming, al menos comercialmente parece que los upstream lo aceptan
mejor. Que conste que yo no he tenido la experiencia en mis propias carnes,
pero es lo que me han dicho varias fuentes.

Lo que pasa con shim6 es el ejemplo mas reciente de la falta de
participacion de los operadores en IETF. Se han callado durante todo el
proceso y cuando esta terminado dicen que "no sirve", pero tampoco colaboran
en mejorarlo o si hace falta hacerlo de nuevo. Creo que tendra cierto
despliegue, pero mas en end-sites/hosts que en ISPs. Siendo practicos, todo
dependera de la apuesta que pueda hacer Microsoft (por ser el SO con mas
presencia en el mercado).

El documento de ARIN, a pesar de estar publicado en el NRO, no he visto que
se haya consensuado con las otras regiones, es decir, no creo que sea mas
que una informacion mas. No digo que sea bueno o malo, pero no refleja
ninguna decision de la comunidad vista desde un punto de vista global.

En AfriNIC y en RIPE NCC se estan discutiendo politicas PI, igual o
parecidas a la que aquí he propuesto (con variaciones propias de cada region
que he tenido en cuenta dados los comentarios recibidos, "aspectos
culturales" y politicas existentes, entre otras cosas). Y creo que tardara
mas o menos, pero quizas en maximo un 12-18 meses estara disponible.

Saludos,
Jordi

> De: Roque Gagliano <rgaglian at antel.net.uy>
> Organización: ANTELDATA
> Responder a: <rgaglian at antel.net.uy>
> Fecha: Mon, 19 Mar 2007 12:29:52 -0300
> Para: LACNIC Policy mailling list <politicas at lacnic.net>
> CC: <jordi.palet at consulintel.es>
> Asunto: Re: [LACNIC/Politicas] Revision de politica - Asignaciones IPv6
> Independientes del Proveedor (PI) para organizaciones-usuario-final
> 
> debi haber dicho:
> 
> "Yo peco de NO haber seguido la discusión en otros RIR de cerca, pero me
> pregunto:"
> 
> Roque
> 
> 
>> 
> On Mon, 2007-03-19 at 13:25 -0300, Roque Gagliano wrote:
>> jordi, encuentro una contradicción entre esta propuesta y lo que has
>> establecido en la lista sobre las soluciones existentes para la
>> asignación de direcciones PA (aquí sí se aplican los documentos que has
>> citado).
>> 
>> Yo peco de haber seguido la discusión en otros RIR de cerca, pero me
>> pregunto:
>> 
>> ¿estamos tirando por la borda el esfuerzo del shim6?
>> ¿qué pasa con las alternativas planteadas por el documento de
>> multi-homing del documento que propuso ARIN como base de discusión?
>> ¿qué esta pasando en otras regiones con la asignación de direcciones PI?
>> 
>> slds
>> r.
>> 
>> 
>> On Tue, 2007-03-06 at 18:33 +0100, JORDI PALET MARTINEZ wrote:
>>> Hola a todos,
>>> 
>>> Esta es una version revisada de la ya anteriormente presentada, teniendo en
>>> cuenta comentarios recibidos, etc. Os ruego comentarios al respecto en los
>>> proximos dias, por si fuera preciso modificarla de cara a la proxima reunion
>>> y facilitar asi una redaccion mas "limpia".
>>> 
>>> 
>>> 1. Numero: (a asignar por LACNIC)
>>> 
>>> 2. Nombre de la Propuesta de Politica:
>>> 
>>> Asignaciones IPv6 Independientes del Proveedor (PI) para
>>> Organizaciones-Usuario-Final
>>> 
>>> 3. Autor:
>>>       a. name:        Jordi Palet Martinez
>>>       b. e-mail:        jordi.palet at consulintel.es
>>>       c. organisation:    Consulintel
>>> 
>>> 4. Version de la Propuesta:    2.0
>>> 
>>> 5. Fecha de envio:    6/3/2007
>>> 
>>> 6. Tipo de Propuesta:
>>>     NUEVA
>>> 
>>> 7. Plazo de la Politica:
>>> 
>>>     Permanente
>>> 
>>> 8. Sumario de la propuesta:
>>> 
>>> Esta politica se presenta como posible solucion para organizaciones que
>>> necesitan asignaciones IPv6 independientes del proveedor (en adelante PI).
>>> 
>>> Por lo general dichas organizaciones requeriran la asignacion del PI para
>>> cumplir con requisitos de multihoming en la forma tradicional utilizada con
>>> IPv4, pero puede haber otras razones detrás de dicha peticion. Por ejemplo,
>>> algunas organizations no requieren multihoming, pero aun así necesitan que
>>> sus asignaciones sean globalmente encaminables con direccionamiento estable.
>>> Podria haber el deseo de evitar la renumeracion si cambian de proveedor.
>>> Esto podria deberse a razones administrativas, politicas o de seguridad. En
>>> estos casos, parece que actualmente no hay otra solucion mas que las
>>> asignaciones de PI.
>>> 
>>> Considerando las consecuencias del medio/largo plazo que esta politica
>>> podria ocasionar en las tablas de encaminado, la anterior version de esta
>>> propuesta sugeria una fecha de expiracion de tres años para esta politica.
>>> Este periodo de tres años comenzaria a contar una vez que exista una
>>> solucion tecnicamente viable y operacionalmente desplegable, que sea
>>> aceptada por la comunidad de Internet. Tras el periodo de gracia, las
>>> asignaciones hechas con propositos de multihoming deberian de ser reclamadas
>>> y esta politica deberia de ser modificara para continuar permitiendo las
>>> asignaciones que sean requeridas para propositos diferentes al multihoming.
>>> En dicho momento, cualquier organización que requiera evitar la renumeracion
>>> podria optar a convertirse en LIR, si asi cualifica para ello, y se le
>>> adjudicaria el mismo prefijo.
>>> 
>>> El cambio introducido en esta version considera que la comunidad "no cree"
>>> en las politicas temporales, y en cualquier caso, cualquier politica puede
>>> ser derogada si es preciso por el propio proceso. Por tanto se presenta en
>>> este caso como una politica permanente.
>>> 
>>> 10. Texto de la Politica:
>>> 
>>> Cualificacion para una asignacion IPv6 PI:
>>> Para cualificar para una asignacion directa, la organización no debe de ser
>>> un LIR IPv6, y debe cualificar para una asignacion o adjudicacion IPv4 por
>>> parte de LACNIC. Esto aplica tanto si la organización tiene como si no,
>>> asignado o adjudicado dicho espacio IPv4.
>>> 
>>> Tamaño de la asignacion IPv6 PI:
>>> El tamaño minimo para la asignacion es un /48, aunque un bloque mayor podria
>>> ser asignado si se documenta y justifica convenientemente. Por ejemplo si se
>>> justifica a los hostmasters que un /48 es filtrado, se podria optar a un
>>> /32. El criterio de los hostsmasters podria ser el mismo utilizado en la
>>> politica de infraestructuras criticas, pues basicamente no tiene sentido
>>> entregar un /48 que sea filtrado, y por tanto la politica no cumple su
>>> cometido en ese caso, por lo que es preciso utilizar un /32.
>>> 
>>> Asignaciones subsecuentes:
>>> Siempre que sea posible, sucesivas asignaciones se realizarian de un bloque
>>> de direcciones adyacente, pero solo si se documenta y justifica
>>> convenientemente.
>>> 
>>> "Super-Bloque" de asignacion:
>>> Las asignaciones seran asignadas desde un "super-bloque" separado, para
>>> facilitar a los RIR el filtrado de las mismas, si fuera requerido.
>>> 
>>> 11. Justificacion:
>>> 
>>> En IPv4, hay organizaciones que cualifican para una asignacion PI, o que
>>> podrian optar a ser un LIR. Esto podria ser bien porque necesiten
>>> multihoming, o tengan otras razones administrativas o tecnicas para un
>>> bloque de direccionamiento portable.
>>> 
>>> Este no es el caso, en la actualidad, para IPv6, y se percibe como una clara
>>> barrera para su despligue por parte de algunas organizaciones. Esta propuesa
>>> de politica pretende evitar dicha barrera por medio de la asignacion directa
>>> desde LACNIC.
>>> 
>>> Cualquier organización recibiendo dicha asignacion, no podria realizar
>>> sucesivas asignaciones a otras organizaciones externas, y por tanto solo
>>> podria asignar subredes internamente dentro de sus propias entidades.
>>> 
>>> Asignar un /32 permite a estos bloques comportarse como cualquier otra
>>> asignacion adjudicada a un LIR, y por tanto seguir las practicas habituales
>>> de filtrado de rutas, pero podria ocurrir que un /48, que es un espacio
>>> suficiente para muchos casos, dejara de ser filtrado y pudiera ser por tanto
>>> adecuado para cumplir con el objetivo de la politica. Al mismo tiempo, los
>>> bloques podrian ser facilmente identificables como pertenecientes a un
>>> "super-bloque" especial.
>>> 
>>> Por medio de esta politica, evitamos la creacion de una situacion injusta
>>> entre diferentes regiones, y satisfacemos los requisitos de cualquier
>>> organización que requiera espacio PI.
>>> 
>>> 
>>> Saludos,
>>> Jordi
>>> 
>>> 
>>> 
>>> 
>>> 
>>> **********************************************
>>> 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.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>> 
>> _______________________________________________
>> 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.