[LACNIC/Politicas] Nueva propuesta de pol í tica (modificacion de la existente de asignaci =?ISO-8859-1?B?8yA=?=n y adjudicaci =?ISO-8859-1?B?8yA=?=n de IPv6)

Mon Jun 5 16:03:50 BRT 2006

Hola Marcelo,

Como siempre gracias por los comentarios.

Contesto debajo, entre lineas.

Saludos,
Jordi

> De: marcelo bagnulo braun <marcelo at it.uc3m.es>
> Responder a: <marcelo at it.uc3m.es>
> Fecha: Mon, 5 Jun 2006 12:55:15 +0300
> Para: <jordi.palet at consulintel.es>
> CC: <politicas at lacnic.net>
> Asunto: Re: [LACNIC/Politicas] Nueva propuesta de pol í tica (modificacion de
> la existente de asignaci ó n y adjudicaci ó n de IPv6)
> 
> Hola Jordi,
> 
> una primera observacion es que creo que esta propuesta trata diversos
> puntos, relacionados, pero muchos y diversos, por lo que no se si no
> seria mejor dividir la discusion en items mas especificos para no
> liarnos...

El fondo de la propuesta es el mismo: Legitimar una situacion de uso de la
politica que hoy por hoy no es coherente con su formulacion, y afecta a los
puntos mencionados de forma directa, con lo cual separarlo no tendria
sentido.

Es el caso de hacer PI como PA, tal y como se propuso tambien en RIPE NCC
como alternativa a PI, solo que como digo en LACNIC lo estamos haciendo en
algunos casos de un modo no muy claro (según la politica).

No se si seguiste la discusion en Guatemala, pues en parte se explico alli
el fondo de la cuestion.

Esta misma politica se presento ya antes en RIPE NCC, y ayer mismo tambien
en AfriNIC y APNIC (pendiente de envio a la lista por los chairs del WG, que
es paso previo en esa region, igual que en ARIN ocurre con el AC).

> 
> en cualquier caso, algunos comentarios...
> 
> El 05/06/2006, a las 1:35, JORDI PALET MARTINEZ escribió:
> 
>> Hola a todos,
>> 
>> Tal y como comente en la pasada reunion, adjunto el texto propuesto.
>> 
>> Por otro lado, me gustaria saber como se procedera para la
>> modificacion del
>> procedimiento de aprobación de politicas que fue sugerido, pues cada
>> vez me
>> parece mas evidente que es imprescindible no esperar a las reuniones
>> presenciales siempre y cuando se logre el consenso en la lista.
>> 
>> Saludos,
>> Jordi
>> 
>> 
>> LACNIC Propuesta de Política 2006-xx
>> 
>> 
>>   Número:   2006-xx
>>   Título de la propuesta de política:   Política de registración para
>> la
>> asignación y adjudicación de direcciones IPv6
>>   Autor:     Jordi Palet Martinez
>>  Consulintel
>>   Versión:   1.0
>>   Fecha de envío:   04/06/2006
>>   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:   El equivalente actual
>>   Draft APNIC Document :   n/a
>> 
>> Sumario de la Propuesta:
>> 
>> La modificación de la política actual propuesta esta diseñada para
>> proporcionar una solución a las largas discusiones que estan teniendo
>> lugar
>> en diversas regiones al respecto de las políticas de IPv6 existentes.
>> Tambien toma en consideración los cambios que ya han tenido lugar en
>> otros
>> RIRs.
>> 
>> Es también una solución alternativa a las propuestas existentes para
>> asignaciones intependientes del proveedor (PI).
>> 
>> A menudo, algunas organizaciones requieren realizar asignaciones
>> internas.
>> Sus redes pueden estan constituidas por un número de sitios, cada uno
>> de los
>> cuales tiene su propia infraestructura nivel 2. En algunos casos, las
>> organizaciones pueden tener un reducido número de sitios, pero aún asi
>> requieren su propio bloque, de tal forma que puedan evitar futuras
>> renumeraciones, en caso de cambios de su(s) proveedor(es) de tránsito
>> o si
>> identifican la necesidad de multihoming.
>> 
>> Un ejemplo podría ser una gran universidad que tiene varios campus y
>> facultades, cada uno de los cuales con sus propias necesidades de
>> direcciones IPv6. Podría tener uno o varios proveedores de tránsito. La
>> universidad, posiblemente necesitará asignar direcciones IPv6 del mismo
>> bloque a sus sitios y al mismo tiempo, ser capaz de utilizar uno o
>> varios
>> proveedores de tránsito. La red de la universidad se comporta por
>> tanto como
>> un ISP interno de la universidad con respecto a cada uno de sus sitios
>> finales.
>> 
>> De hecho, esta propuesta aclara una situacion de adjudicación a este
>> tipo de
>> clientes que es ya procedimiento ³de facto² en la region.
>> 
>> 
>> 
>> 
>> Borrador del Texto de la Política:
>> 
>> Sección 2.9. actual:
>> 
>> 2.9. End Site
>> 
>> Un end site es definido como un usuario final (suscriptor) que tiene
>> una
>> relación de negocios con un proveedor de servicios que involucra:
>>   * al proveedor de servicios asignando un espacio de direcciones al
>> usuario
>> final
>>   * al proveedor de servicios otorgando un servicio de tránsito para el
>> usuario final hacia otros sites
>>   * al proveedor de servicios transportando el tráfico del usuario
>> final
>>   * al proveedor de servicios anunciando un prefijo de ruta agregado
>> que
>> contiene la asignación del usuario final
>> 
>> Texto sustitutivo propuesto:
>> 
>> 2.9. End Site (Sitio Final)
>> 
>> Un end site es definido como un usuario final (suscriptor) que tiene
>> una
>> relación de negocios o legal (misma o entidades asociadas) con un
>> proveedor
>> de servicios que involucra:
>>   * al proveedor de servicios asignando un espacio de direcciones al
>> usuario
>> final
>>   * al proveedor de servicios otorgando un servicio de tránsito para el
>> usuario final hacia otros sites
>>   * al proveedor de servicios transportando el tráfico del usuario
>> final
>>   * al proveedor de servicios anunciando un prefijo de ruta agregado
>> que
>> contiene la asignación del usuario final
>> 
>> 
> 
> a ver si entiendo... la modificacion propuesta en este parrafo es
> 
> s/relación de negocios/relación de negocios o legal (misma o entidades
> asociadas)
> 
> y solo eso, no?

SI.

Una universidad que necesite espacio y que tenga varios upstreams, NO tiene
otro remedio que ser LIR, y sin embargo, la definicion actual se end-site,
teoricamente le impide la funcion de ISP (dentro de su propia entidad).

> 
> la verdad es que sin la explicacion del prologo,no entiendo mucho a que
> se refiere, en particular, lo de misma o entidades asociadas no queda
> nada claro para mi...

Puedo intentar aclararlo mas ... Pero era por no hacerlo mucho mas largo.

> 
> la idea es permitir que proveedores internos sea calificados como
> proveedores, no?

Si, justo.

> 
> pero tampoco me queda claro si sigue siendo necesario y relevante
> definir un edn-stie, considerando que la condicion de no ser un
> end-site no aparece mas en los requissitos para obtener un bloque de
> direcciones...

Si, es necesario, porque la alternativa seria modificar el texto en toda la
politica casi cada vez que se menciona end-site. Parece mas facil asi, no
crees ?

> 
> digo, porque cambiar esta definicion y tambien los criterios de
> asignacion inicial? no seria suficiente con cambiar solo uno de ellas?
> o cambiamos lo que quiere decir end site o cambiamos los criterios para
> asignacion inicial, pero las dos no parece ser necesario...

No por lo que digo antes, en varios puntos de la politica, no hacer el
cambio de la definicion de end-site no "cuadra".

> 
>> Sección 5.1.1. actual:
>> 
>> 5.1.1. Criterio de adjudicación inicial
>> 
>> Para calificar para la adjudicación inicial de un espacio de
>> direcciones
>> IPv6, una organización debe:
>> 
>> a)    ser un LIR o ISP;
>> b)    not ser un sitio final (usuario final);
>> c)    Documentar un plan detallado sobre los servicios y la
>> conectividad en
>> IPv6 a ofrecer a otras organizaciones (clientes)
>> d)    Anunciar en el sistema de rutas inter-dominio de Internet un
>> único
>> bloque, que agregue toda la asignación de direcciones IPv6 recibida,
>> en un
>> plazo no mayor de 12 meses
>> e)    Ofrecer servicios en IPv6 a clientes localizados físicamente en
>> la
>> región del LACNIC en un plazo no mayor de 24 meses
>> 
>> Texto sustitutivo propuesto:
>> 
>> 5.1.1. Criterio de adjudicación inicial
>> 
>> Para calificar para la adjudicación inicial de un espacio de
>> direcciones
>> IPv6, una organización debe:
>> 
>> a)    Ser un LIR o ISP;
>> b)    Documentar un plan detallado sobre los servicios y la
>> conectividad en
>> IPv6 a ofrecer a otras organizaciones (clientes) o a sus
>> propios/relacionados(as) departamentos/entidades/sitios, a los cuales
>> asignará /48s.
>> c)    Anunciar en el sistema de rutas inter-dominio de Internet un
>> único
>> bloque, que agregue toda la asignación de direcciones IPv6 recibida,
>> en un
>> plazo no mayor de 12 meses.
>> d)    Ofrecer servicios en IPv6 a clientes o entidades
>> propias/relacionadas
>> (incluyendo departamentos y/o sitios) localizados físicamente en la
>> región
>> de LACNIC en un plazo no mayor de 24 meses.
>> 
> 
> esto basicamente quiere decir que cualquier que quiera/pueda pagar la
> membresia de ser un LIR puede obtener su propio bloque /32

No cualquiera, sigue teniendo que justificar un plan, y ahí esta el criterio
del hostmaster, que creo que es lo suficientemente bueno y probado hasta
ahora.

> 
> la barrera de entrada en este caso ya no pasa por la condicion de
> proveedor de servicios o el tamaño sino simplemente por el dinero....

No, creo que el plan es mas importante, dado que justifica la red, y no
calificas por mucho que quieras pagar si no es apropiado.

> 
> la verdad que no me convence mucho... sobre todo porque el parametro
> utilizado para definir el numero de bloques asignados (el precio de la
> membresia) escapa el control de esta lista. Con esta politica, el
> precio de membresia afecta el numero de entradas en la tabla global de
> rutas... es un poco raro me parece a mi

Como digo no es el caso, bajo mi punto de vista.

> 
>> Sección 5.5. actual:
>> 
>> 5.5. Micro-Asignaciones en IPv6
>> 
>> LACNIC podrá realizar micro-asignaciones en casos de proyectos e
>> infraestructuras de redes claves o críticas para el funcionamiento, y
>> desarrollo de IPv6 en la región como son IXP (Internet Exchange
>> Point), NAP
>> (Network Access Point), RIR, proveedores de DNS ccTLD, entre otros.
>> Dichas
>> asignaciones se realizarán en bloques menores o igual a un /32 pero
>> siempre
>> mayores o iguales a un /48.
>> 
>> Texto sustitutivo propuesto:
>> 
>> 5.5. Micro-Asignaciones en IPv6
>> 
>> LACNIC podrá realizar micro-asignaciones en casos de proyectos e
>> infraestructuras de redes claves o críticas para el funcionamiento, y
>> desarrollo de IPv6 en la región como son IXP (Internet Exchange
>> Point), NAP
>> (Network Access Point), RIR/NIR, root servers, proveedores de DNS TLD,
>> entre
>> otros. Dichas asignaciones se realizarán en bloques /32 (o mayores si
>> se
>> jusitifica convenientemente), excepto en el caso de que con seguridad
>> se
>> sepa que no tiene que ser anunciados, en cuyo caso se podrán utilizar
>> bloques mayores o iguales a un /48.
>> 
> 
> estoy de acuerdo con darle un /32 a los TLDs, y capaz que a los RIRs
> (si consideramos que las bases de datos que tiene son criticas para
> elfuncionamiento)
> por otra parte, no entiendo porque es necesario darles un /48 a los IX
> y NAPs. Digo, el direccionamiento de estos es interno, correcto. Digo
> quienes se conectan a estos puntos tiene sus propios bloques, por que
> razon es critico que los equipos del IX/NAP sean accesibles desde el
> resto de la internet? es mas, creo que seria deseable que no lo
> fuera...

Aquí no he cambiado nada (para los IX/NAP), al contrario, indico claramente
que sea un /48 si no se anuncia, que es lo habitual.

Otra cosa es que discrepes con lo que ya habia ;-)

> 
> 
>> 
>> Texto adicional a ser eliminado de la política actual:
>> 
>> 1.1. Alcance
>> 
>> Esta política es considerada interina. Será revisada en el futuro,
>> cuando se
>> disponga de mayor experiencia en la administración de IPv6.
>> 
> 
> no veo porque eliminar esta parte... creo que todaia estamos
> aprendiendo y claramente las reglas lazas de asignacion inical indican
> que esto deba ser revisado en un futuro...

Creo que discrepo. Ya hemos aprendido, ya somos "bastante mas mayores" con
IPv6, y este comentario sobra. Si hay que revisar la politica, se revisa
siempre que sea preciso, y sin este comentario. Luego simplifiquemos el
texto y no seamos ingenuos.

> 
>> 
>> 5.4.2. Asignación de multiples /48s a un solo site
>> 
>> Cuando un solo end site requiere un bloque de direcciones de /48
>> adicional,
>> debe pedir la asignación con documentación o materiales que
>> justifiquen el
>> pedido. Los pedidos de bloques múltiples o adicionales de /48s serán
>> procesados y revisados (ej: evaluación de la justificación) al nivel
>> de los
>> RIR/NIR.
>> 
> 
> porque quieres quitar esto? por lo de las asignaciones de /56? no
> habria que sustituirlo con un comentario en la misma linea pero con
> /56? capaz que eso ya esta en otra parte tal vez...?
> 
> saludos, marcelo
> 

No tieen nada que ver con el tema del /56, al menos no mientras no se
apruebe que no es el caso por el momento. Lo que digo es que no tiene ningun
sentido a estas alturas, sea cual sea el tamaño del prefijo que un LIR
entrega al cliente, que lo tenga que evaluar el RIR. Es el ISP el que lo
evaluara y registrara en el whois para que le cuente de cara a su proxima
peticion al RIR.

> 
>> Nota: No hay experiencia en el presente con la asignación de múltiples
>> /48s
>> a un mismo end site. Se prevee que la necesidad de que el RIR revise
>> todas
>> estas asignaciones sea una medida temporaria hasta tanto se adquiera
>> algo de
>> experiencia y que se hallan desarrollado algunas políticas comunes.
>> Además,
>> el trabajo adicional de definir políticas en este espacio
>> probablemente será
>> llevado a cabo en un futuro cercano.
>> 
>> 
>> 
>> 
>> Justificación:
>> a. Argumentos a favor de la propuesta
>> 
>> Ya ha habido claros ejemplos y discusiones en diferentes regiones
>> acerca de
>> la necesidad de esta modificación y además es una reflejo de la
>> realidad de
>> la adjudicación que se viene realizando en algunos casos.
>> 
>> Las dificultades que algunas grandes entidades encuentran en recibir
>> espacio
>> de direcciones IPv6 es una clara barrera para su despliegue.
>> 
>> Por medio de esta modificación de la política, evitaríamos crear una
>> situación de injusticia entre diversar regiones de servicio RIR. Otros
>> RIRs
>> ya han modificado la política común original de IPv6 para evitar
>> algunas de
>> estas barreras.
>> 
>> b. Argumentos en contra de la propuesta
>> 
>> Un posible efecto contrario a esta propuesta podría ser el crecimiento
>> de
>> las tablas de routing globales. Esto solo puede ocurrir si
>> efectivamente se
>> hacen adjudicaciones bajo esta modificación de la propuesta, aunque
>> posiblemente esto ocurriría de otras formas mediante desagregación, y
>> en
>> cualquier caso se producira a través del efecto de políticas de PI ya
>> aprobadas en otras regiones.
>> 
>> 
>> 
>> 
>> Reconocimientos:
>> 
>> Desearía reconocer a todos aquellos que han contribuido durante muchos
>> años
>> al debate de las modificaciones aquí sugeridas a la política existente.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>> 
>> Barcelona 2005 Global IPv6 Summit
>> Slides available at:
>> http://www.ipv6-es.com
>> 
>> 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
>> http://www.lacnic.net/mailman/listinfo/politicas
>> 
> 

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

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

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.