[LACNIC/Politicas] Politicas para el foro publico
CHRISTIAN O'FLAHERTY
christian.oflaherty at gmail.com
Tue May 2 16:00:05 BRT 2006
Hola Francisco, para simplificar la discusión sobre el cambio de valor
de HD ratio tal vez sea suficiente con mencionar la mejor eficiencia
conseguida. En la presentación se pueden mostrar ambos porcentajes
segun el tamaño de asignación mínimo utilizado.
No es conveniente atar una politica a otra. Por otro lado, subir aun
mas el valor de HD ratio seria realizar otra propuesta diferente que
requerirá mas debate. Tal vez esta propuesta no haya sido analizada en
profundidad por la comunidad para ser votada en el Foro Público. Qué
opinas?
Es posible hacer solo la presentación (sin votarla) en el Foro si
consideran que el tema no fue suficientemente discutido en la lista.
Christian
On 5/2/06, Francisco Obispo <fobispo at nic.ve> wrote:
> -----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