[LACNIC/Politicas] Politicas para el foro publico
German Valdez
german at lacnic.net
Wed May 3 13:39:38 BRT 2006
Hola Christian
Faltaria agregar la propuesta hecha por Carlos Martinez el 25 de Abril que
corresponde a LAC-2006-03
http://www.lacnic.net/pipermail/politicas/2006-April/000691.html
Esta propuesta se refiere a la politica de LACNIC de asignar espacio
adicional suficiente para la operacion de 3 meses del solicitante.
La propuesta en concreta realizada por Carlos es
1. Modificar la politica relevante de LACNIC para aumentar el período de
tres meses y llevarlo a 12 meses.
En segundo termino propone
2. Solicitar a LACNIC que eleve una propuesta de "tender a la uniformidad de
criterios" entre RIRs a los efectos de compatibilizar estas estimaciones.
Los detalles de la justificacion pueden encontrarlo en el link del mensaje
Saludos
German Valdez
LACNIC
> -----Mensaje original-----
> De: politicas-bounces at lacnic.net
> [mailto:politicas-bounces at lacnic.net] En nombre de CHRISTIAN
> O'FLAHERTY
> Enviado el: Martes, 02 de Mayo de 2006 12:47 p.m.
> Para: politicas at lacnic.net
> Asunto: [LACNIC/Politicas] Politicas para el foro publico
>
> Estimados, durante los próximos días podremos hacer
> comentarios a las políticas que han sido discutidas en esta
> lista durante los meses anteriores.
>
> Para no tener que buscar entre los mails el texto de cada
> una, les envío todas las propuestas recibidas en este mail.
>
> Saludos,
>
> Christian
>
> Indice:
>
> LAC-2006-01 Privacidad WHOIS
> LAC-2006-02 Recuperacion de Recursos
> LAC-2006-03 Periodo de Analisis Tamanho Asignaciones Adicionales
> LAC-2006-04 ASN 32 bits
> LAC-2006-05 HD Ratio IPv6
> LAC-2006-06 HD Ratio IPv4
> LAC-2006-07 Tamano de asignaciones IPv6
> LAC-2006-08 Asignacion IPv6 a Usuarios Finales
>
> Propuestas:
>
> LAC-2006-01 Privacidad WHOIS
>
> Política propuesta "Filtrado de la Información del WHOIS de LACNIC "
>
> Los ISP suministran a LACNIC información clasificada de las
> delegaciones de los bloques hechas a los clientes, cuyo rango
> sea mayor a 8 direcciones (prefijo /29). Esta información
> será publicada a través de la nueva base de datos WHOIS, en
> donde se han modificar y eliminar aquellos campos de los
> contactos y usuarios que podrían constituir información de
> carácter privado.
>
> LACNIC tendrá la potestad de solicitar más información (de
> carácter publico o información autorizado por el cliente) a
> los ISPs, sobre las delegaciones realizadas. A su vez, ISPs
> puede solicitar que la información suministrada no sea de
> carácter público .
>
> 1. Los datos pedidos actualmente para una asignación son:
>
> • Nombre
> • Responsable
> • Dirección Postal
> • Código Postal
> • Ciudad
> • Estado
> • País
> • Teléfono
> • Id del contacto
>
> 2. Para un contacto del ISP la información pedida es:
>
> • Nombre
> • E-mail
> • Direcc. Postal
> • Código Postal
> • Ciudad
> • Estado
> • País
> • Lengua
> • Teléfono
>
> LACNIC hará público en el WHOIS los siguientes datos para
> cada bloque siempre:
>
> • Nombre cliente
> • Bloques de direcciones
> • A pedido del RI, LACNIC eliminará del WHOIS los
> siguientes datos
> del cliente:
> • Id del contacto
> • Dirección Postal
> • Código Postal
> • Ciudad
> • Estado
> • País
> • Teléfono
>
> Los datos del contacto podrán ser datos de una persona real o
> los de un grupo de personas responsables de la
> administración de red. Esos datos deben existir siempre y es
> responsabilidad de la entidad que lo registra mantenerlos
> actualizados.
> --------------------------------
>
> LAC-2006-02 RECUPERACIÓN DE RECURSOS
>
> POLÍTICA DE RECUPERACIÓN DE RECURSOS DE INTERNET NO UTILIZADOS
>
> Propuesta
>
> Se considera que el término "recursos de Internet no utilizado"
> refiere a aquellos recursos administrados por LACNIC, no
> visibles en la tabla de enrutamiento global de Internet por
> más de un año y de los cuales no hay constancia de su utilización.
>
> Cuando los recursos no están utilizados y:
>
> 1. Se localiza el contacto de la organización pero este no
> esta de acuerdo en regresar los recursos:
> en este caso la organización se queda con los bloques.
>
> 2. El contacto no responde o ya no tiene ninguna relación con
> la organización que los pidió y:
>
> a. Se comprueba que la organización existe y
>
> b. No se puede conseguir información sobre el estado de la
> organización:
> enlistar en una página los nombres de las organizaciones de
> las que se tiene duda. De la misma manera crear un boletín de
> distribución, tal vez mensual, de forma que toda la comunidad
> se convierta en un "aliado" potencial.
>
> 3. Se comprueba que la organización ya no existe más (sea que
> el contacto responda o no) y
>
> a. La organización deja de existir porque fue comprada por
> otra y los recursos no son más utilizados:
> Se recuperan los recursos (LACNIC los puede reasignar)
>
> b. La organización deja de existir porque fue comprada por
> otra y se puede justificar que servicios o usuarios que
> utilizan dichos recursos fueron también transferidos:
> En este caso LACNIC acepta la transferencia de los recursos
> en un plazo no mayor de 90 días
>
> c. La organización desapareció, no tiene más operación. Los
> recursos ya no se utilizan:
> Si no hay mas servicios ofrecidos los recursos son
> recuperados por LACNIC.
>
> d. La organización desapareció, no tiene más operación. Los
> recursos todavía son utilizados:
> La nueva organización debe hacer su solicitud formal de
> asignación de recursos ante LACNIC en un plazo no mayor de 90
> días a partir de la fecha de notificación. En caso de no
> solicitar la asignación de recursos en 90 días o si no
> cumple con todos los requisitos establecidos en las políticas
> para la asignación de recursos de
> Internet: LACNIC procederá la recuperación de dichos recursos.
>
> La recuperación de recursos implicará la eliminación del
> registro de los recursos en la base de datos WHOIS.
>
> LACNIC recomienda que los ISP de la región verifiquen la
> existencia del registro de los recursos de numeración de
> Internet en la base de datos WHOIS antes de implementar su
> anuncio en sus tablas de Internet.
>
> --------------------
>
> LAC-2006-04 ASN 32 bits
>
> 1. Policy Proposal Name:
>
> 4-Byte AS Number Policy Proposal
>
> 2. Author:
>
> Geoff Huston
> gih at apnic.net
> APNIC
>
> 3. Proposal Version:
>
> 1.0
>
> 4. Submission Date:
>
> 9 December 2005 (resubmitted on the 30th December)
>
> 5. Proposal Type:
>
> New
>
> 6. Policy Term:
>
> Temporary (1 January 2007 ¬ 1 January 2010)
>
> 7. Policy Statement:
>
> This policy proposal nominates 3 dates for changes to the
> current AS Number allocation policy for the registry:
>
> 1. On 1 January 2007 the registry will process applications
> that specifically request 32-bit only AS Numbers and allocate
> such AS Numbers as requested by the applicant. In the absence
> of any specific request for a 32-bit only AS Number, a 16-bit
> only AS Number will be allocated by the registry.
>
> 2. On 1 January 2009 the registry will process applications
> that specifically request 16-bit only AS Numbers and allocate
> such AS Numbers as requested by the applicant. In the absence
> of any specific request for a 16-bit only AS Number, a 32-bit
> only AS Number will be allocated by the registry.
>
> 3. On 1 January 2010 the registry will cease to make any
> distinction between 16-bit only AS Numbers and 32-bit only AS
> Numbers, and will operate AS number allocations from an
> undifferentiated 32-bit AS Number allocation pool.
>
> No other changes in AS number allocation policy are implied
> by this proposal.
>
>
> 8. Rationale:
>
> Recent studies of AS number consumption rates indicate that
> the existing pool of unallocated 16-bit AS Numbers will be
> exhausted sometime in the period between 2010 and 2016,
> absent of any concerted efforts of recovery of
> already-allocated AS Numbers [1] [2].
> Standardization work in the IETF has produced a document that
> is currently being submitted as a Proposed Standard that will
> expand the AS Number space to a 32-bit field [3].
>
> It is noted that some advance period may be required by
> network operators to undertake the appropriate procedures
> relating to support of 32-bit AS numbers, and while no flag
> day is required in the transition to the longer AS Number
> field, it is recognised that a prudent course of action is to
> allow for allocation of these extended AS numbers well in
> advance of an anticipated 16-bit AS Number exhaustion date.
>
> This policy proposal details a set of actions and associated
> dates for RIR AS Number allocation policies to assist in an
> orderly transition to use of the 32-bit AS Number space.
>
> The essential attributes of this policy proposal are to
> facilitate the ease of transitional arrangements by equipment
> vendors, network managers and network operations staff, to
> provide the industry with some predictability in terms of
> dates and associated actions with respect to registry
> operational procedures for AS Number allocations.
>
> Nomenclature
>
> It is proposed to identify 32-bit AS Numbers using a syntax
> of <high order 16 bit value in decimal>.<low order 16 bit
> value in decimal>.
> Accordingly, a 32-bit AS number of value 65546 (decimal)
> would be identified as "1.10".
>
> Terminology
>
> "16-bit only AS Numbers" refers to AS numbers in the range 0 – 65535
>
> "32-bit only AS Numbers" refers to AS Numbers in the range 1.0 –
> 65535:65535 (decimal range 65,536 - 4,294,967,295)
>
> "32-bit AS Numbers" refers to AS Numbers in the range 0.0 –
> 65535.65535 (decimal range 0 – 4,294,967,295)
>
> References
>
> [1] Daily AS Number Report, http://www.potaroo.net/tools/asns
> [2] ASNs MIA: A Comparision of RIR Statistics and RIS
> Reality, http://www.nanog.org/mtg-0510/wilhelm.html
> [3] BGP Support for Four-octet AS Number Space,
> draft-ietf-idr-as4bytes-12.txt
>
> 9. Timetable for implementation:
>
> Procedures to support this proposal need to be implemented by
> 1 January 2007
>
> --------------------------
>
> LAC-2006-07 Tamaño de asignaciones IPv6
>
> Se propone que se modifique la política de asignación de IPv6
> de manera tal que permita a los LIRs la asignación de /56s
> para el caso de usuarios finales que sean pequeñas y medianas
> empresas, residenciales o redes personales, donde el número
> de subredes potenciales exceda 1 pero no exceda 256.
>
> Se propone que se cambie el párrafo referente a las
> asignaciones /48, de manera que refiera específicamente a
> asignaciones a grandes empresas y entornos corporativos
> finales cuyo requerimiento es superior a 256 subredes.
>
> Se propone que se tome como por defecto la asignación /56,
> tanto para la definición de Utilización (Punto 2.7 de la
> política) como para el cálculo del HD Ratio.
>
> ----------------------------
>
> LAC-2006-05 HD Ratio IPv6
>
> Se propone que se cambie el valor del HD Ratio de 0.8 a 0.94,
> de manera de aumentar los niveles de eficiencia.
>
> A modo de ejemplo, con un HD Ratio de 0.94 el nivel de
> utilización requerido para una asignación adicional de un /32
> pasa del ya mencionado 10,9% a un 51,4%
>
> ------------------------
>
> LAC-2006-08 Asignaciones IPv6 Independientes del Proveedor (PI)
> para Organizaciones-Usuario-Final
>
> Resumen:
>
> 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, esta
> propuesta sugiere 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.
>
> 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 /32, aunque un
> bloque mayor podria ser asignado si se documenta y justifica
> convenientemente.
>
> 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.
>
> Expiracion de las asignaciones:
> Los bloques asignados mediante esta propuesta como solucion
> para multihoming, deben ser devueltos a LACNIC en un plazo
> maximo de tres años.
> El periodo de tres años comienza una vez que haya una
> solucion tecnicamente valida y desplegable que sea aceptada
> por la comunidad Internet. Cualquier organización que desee
> evitar renumerar podria optar a convertirse en LIR, si
> cualifica para ello, y le seria adjudicado el mismo prefijo.
>
> Argumentos soportanto la propuesta
>
> 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. Al
> mismo tiempo, los bloques podrian ser facilmente
> identificables como pertenecientes a un "super-bloque"
> especial. Esto podria tambien permitir a estas organizaciones
> convertirse en LIR y evitar la renumeracion.
>
> 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. Todas las organizaciones que opten por este PI, estaran
> en igualdad de situacion una vez que la comunidad haya
> aceptado una solucion tecnica a mas largo plazo, y tendran
> que bien moverse a dicha nueva situacion o bien convertirse
> en LIR, si cualifican para ello.
> Las nuevas organizaciones estaran por tanto en la misma situacion.
> Algunas organizaciones no optaran por PI bajo esta politica,
> porque realmente no lo necesitan, y la politica impide que
> esten en una situacion desventajosa.
>
> Aquellos que no creen en posibles soluciones alternativas,
> pero en su lugar prefieren una solucion de politica
> permanente de PI, no tienen razones validas para oponerse a
> esta propuesta, dado que el plazo de expiracion solo entra en
> efecto una vez que una solucion valida ha sido aceptada. Esta
> propuesta, por tanto, no interfiere con sus planes.
>
> Algunas organizaciones podrian cualificar en este momento
> para ser LIR y evitar usar esta politica de asignacion
> temporal. Sin embargo, si la unica razon para convertirse en
> LIR es obtener un bloque PI, en este caso es mejor facilitar
> el control de las tablas de encaminado en el largo plazo,
> mediante el uso de la opcion ofrecida por esta propuesta.
> Esto seria mas justo con toda la comunidad Internet.
>
> La naturaleza "temporal" de esta asignacion debe de ser
> entendida como un largo plazo, dado que esperamos soluciones
> alternativas que puedan estar disponibles en tres o cuatro
> años. Este plazo no incluye el periodo de transicion. Por lo
> tanto, pidiendo un cambio tras un periodo de seis o siete
> años, deberia de ser totalmente aceptable para todos.
>
> Argumentos oponiendose a la propuesta
>
> El posible efecto de esta propuesta es el crecimiento de las
> tablas de encaminado hasta niveles que, junto a los
> existentes y previstos en IPv4, podria crear problemas muy
> importantes para operadores, salvo que los fabricantes
> pudieran proporcionar productos que solventen los mismos. Aun
> cuando dichas soluciones tecnicas fueran halladas, la
> propuesta aun tendria un impacto importante en el coste y/o
> periodod de amortizacion de las inversiones en infraestructura.
>
> Por esta razon, esta propuesta tiene un plazo de caducidad,
> pero respecto de una fecha en la que una solucion alternativa
> tecnica valida sea aceptada por la comunidad de Internet.
>
> Una asignacion temporal /32 no deberia de ser vista como un
> desperdicio de direcciones. Traeria consigo la ventaja de
> evitar la necesidad de filtros especiales, asi como la de
> renumeracion de aquellos que lleguen a ser LIR.
>
> Reconocimientos: Deseo reconocer los comentarios recibidos a
> la primera version de esta propuesta por parte de Marcelo
> Bagnulo y Lea Roberts.
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> http://www.lacnic.net/mailman/listinfo/politicas
>
More information about the Politicas
mailing list