[LACNIC/Politicas] Politicas para el foro publico
Francisco Obispo
fobispo at nic.ve
Tue May 2 13:10:07 BRT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hola Chrisian,
Tenemos que tener cuidado como se "aprueban" las políticas.
Porque si aprobamos el cambio de asignación de IPv6 para usuarios
finales, de /48 fijo a tamaño variable mayores a /56, ( utilizando este
ultimo para el cálculo del HD-Ratio), y luego aprobamos que se cambiará
el HD-Ratio de IPv6 de 0.8 a 0.94, entonces la justificación para
aprobar el cambio no sería válido.
Tendríamos en este caso de cambiar de 0.94 a 0.96 para poder justificar
el 51.41% de utilización de recursos.
Crees que sería conveniente discutir las políticas en ese orden, y
modificar la propuesta de cambio de HD-Ratio en IPv6 para que se ajuste
según el tamaño de usuario final aprobado en asamblea?
Saludos
CHRISTIAN O'FLAHERTY wrote:
> 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
>
>
- --
~~
Francisco Jose Obispo Semidey
Jefe de Oficina de NIC-VE - NIC-VE Manager
Centro Nacional de Tecnologias de Informacion - http://www.nic.ve
Caracas - Venezuela
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEV4RfGs0zZ5KMmSMRAkUIAKCnLLArW15yu2xUasJOU2eF/Kk89QCbBXNy
A93+Zhj2hcJElpfRL2neaJg=
=2TZf
-----END PGP SIGNATURE-----
More information about the Politicas
mailing list