[LACNIC/Politicas] Politicas para el foro publico

[CHRISTIAN O'FLAHERTY]

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.