Re: [LACNIC/Politicas] Nueva propuesta de pol í tica (modificacion de la existente de asignaci ó n y adjudicaci ó n de IPv6)

[marcelo bagnulo braun]

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...

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?

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...

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

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...

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...

> 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

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....

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

> 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...


>
> 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...

>
> 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


> 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
>