From patara at lacnic.net  Wed Oct  1 11:26:27 2008
From: patara at lacnic.net (Ricardo Patara)
Date: Wed, 1 Oct 2008 11:26:27 -0300
Subject: [LACNIC/Politicas] 32 bits ASN [EN]
Message-ID: <20081001112627.03526e7a@lacnic.net>

32 bits ASN

Introduction:

Since January 1st 2007 LACNIC, along with the other RIRs, is assigning to its members Autonomous System Numbers (ASNs) of 32 bits length.

Until that date, the ASNs assigned were of 16 bits length, which allowed a maximum of about 65000 ASNs.

With the possibility of a foreseen exhaustion of the 16 bits ASNs space, in 2001 the first studies and proposals to expand ASNs space to 32 bits were initiated.

That work was concluded in 2007 when the IETF (Internet Engineering Task Force) published the document named RFC 4893. This document indicates the new ASN format, its utilization in routing protocols like BGP and also its interaction with other systems with no support to it.

Since that date, IANA has allocated to the RIRs blocks of 32 bits ASN for further assignment inside each region.


Policy:

In 2006 the first policy proposals to assign 32 bits ASN started to be discussed inside each RIR. Those proposals kept the need of multihoming connexion or a unique routing policy as the criteria to justify an ASN assignment.
Such policy also includes criteria for the transition from 16 bits ASN assignment to 32 bits ASN assignment.

The policy adopted in the LACNIC region (which is similar to the one adopted in other regions), establishes that after January 1st 2007 32 bits ASN would only be assigned when clearly expressed in the request. Otherwise, 16 bits ASN would be assigned by default.

Also according to this policy, this criterion will change after January 1st 2009. When requests for ASN will by default qualify for the assignment of 32 bits ASNs. While 16 bits ASNs will only be assigned when clearly expressed in the request.


Current Situation:

It is important to highlight that even if there is availability of 16 bits ASNs, after January 2009, they will only be assigned when clearly requested.

Specially when it is known that there are systems and equipments with no support to 32 bits ASNs yet, what would affect organizations planning to adopt redundant routing policy, who will need ASNs, and in some cases, new routing equipments as well.

Therefore, even considering this is not an urgent problem as projections indicate there will 16 bits ASNs available for 2 or 3 more years, still this is something that requires special attention.

In this current scenario we believe its is important to recommend that during new networks projects and planning to take into consideration the need for a 32 bits ASN, what could impact in decisions for new network equipments or systems acquisition.

It is also recommended that administrators of already deployed networks verify with their network equipments and systems suppliers about the support for 32 bits ASN in future versions of their products.

Although the transition mechanisms allows old systems to work with new ASN format, without any update, it is still important to support new ASN version in order to count with tools that network administrators are familiar with.

And lastly, there are some important discussions in the global community about the 32 bits ASN representation schema. Until now the representation chosen is the one named ?as-dot2? which represents a 32 bits ASN as the following: <high order 16 bits value in decimal>.<low order 16 bits value in decimal>. The utilization of this representation has been discussed due to difficulties this impose to work with regular expressions already implemented in several tools, and it is being promoted to change the  representation ?as-plain? where the 32 bits ASN would be represented as decimal value in the range 0 -  4294967295.
As a way to contribute in this debate we believe it is important to receive comments from community in our region about this discussion.

From patara at lacnic.net  Wed Oct  1 11:26:27 2008
From: patara at lacnic.net (Ricardo Patara)
Date: Wed, 1 Oct 2008 11:26:27 -0300
Subject: [LACNIC/Politicas] ASN 32 bits [PT]
Message-ID: <20081001112627.6e35291b@lacnic.net>

ASN 32 bits

Introdu??o:

Desde 1? de janeiro de 2008 o LACNIC, tal qual os demais RIRs, est? designando ao seus membros N?meros de Sistemas Aut?nomos (ASN) de 32 bits.

Anteriormente, os ASNs designados eram de 16 bits permitindo uma quantidade m?xima de aproximadamente 65 mil ASNs.

Antecipando um poss?vel esgotamento do espa?o de ASNs de 16 bits, se iniciaram em 2001 os primeiros estudos e propostas para expandir o formato do ASN para 32 bits.

Esse trabalho foi conclu?do em 2007 com a publica??o de um documento da IETF (Internet Engineering Task Force), denominado RFC 4893. Esse documento indica o novo formato de ASN, sua utiliza??o em protocolos de roteamento como o BGP e tamb?m sua intera??o com outros sistemas e protocolos que ainda n?o tenham sido atualizados para suportar esse novo formato.

Desde ent?o, a IANA designou a cada RIR um bloco de ASN de 32 bits para sua subseq?ente designa??o dentro de cada regi?o.


Pol?tica:

J? no ano de 2006 se estava discutindo dentro dos RIRs propostas de pol?ticas para designa??o de ASNs de 32 bits. As quais mantinham os crit?rios enquanto a necessidade de que a organiza??o seja ?multihomed? o que tenha uma pol?tica ?nica de roteamento para assim justificar a designa??o.
Essa pol?tica para designa??o de ASN inclui tamb?m crit?rios para a transi??o entre a designa??o de ASN de 16 bits para os de 32 bits.

A pol?tica regional adotada pelo LACNIC (que ? semelhante a das demais regi?es), estabelece que as solicita??es de ASN realizadas a partir de 1 de janeiro de 2007 devem indicar expressamente o desejo por um ASN de 32 bits. Em caso contr?rio, a designa??o por padr?o ser? de um ASN de 16 bits.

De acordo com essa mesma pol?tica, esse crit?rio deve ser modificado a partir de 1? de janeiro de 2009. A partir dessa data as solicita??es realizadas considerar?o a designa??o de ASN de 32  bits como padr?o, enquanto que ASNs de 16 somente ser?o designados quando explicitamente solicitados.


Situa??o Atual:

? importante destacar que por mais que ainda existam ASNs de 16 bits dispon?veis para designa??o, a partir de janeiro de 2009 eles ser?o designados somente a quem os solicite explicitamente.

Especialmente quando se ? de conhecimento que existem sistemas e equipamentos que n?o suportam ainda ASNs de 32 bits, o que pode afetar as organiza??es que estejam optando por uma pol?tica de roteamento redundante, para o que necessitar?o de um de ASN e, em alguns casos, de novos equipamentos de roteamento.

Portanto, se bem que n?o se trata de um problema urgente, pois as proje??es atuais indicam que ainda h? ASN de 16 bits para 2 ou 3 anos mais, ? um assunto ao qual se deve prestar especial aten??o.

Diante dessa situa??o, cremos importante recomendar que em planifica??es e projetos de novas redes se considere a poss?vel necessidade de se utilizar ASNs de 32 bits, o que pode repercutir em decis?es de compras de novos equipamentos ou sistemas de redes.

Se recomenda tamb?m aos administradores de redes j? em opera??o que verifiquem junto aos provedores de seus equipamentos e sistemas quanto ao suporte a ASNs de 32 bits em futuras vers?es de seus produtos.

Se bem que os mecanismos de transi??o s?o simples e permites que sistemas m?s antigos funcionem com esses novos ASNs sem necessidade de atualiza??o, ? importante o suporte a essa nova vers?o de ASN para contar com todas as ferramentas a que os administradores j? est?o habituados at? o momento.

Finalmente, existem tamb?m na comunidade global um debate importante sobre o tipo de representa??o para os ASNs de 32 bits. At? o momento a representa??o escolhida consistem na denominada ?as-dot2?, onde os 32 bits se representa da seguinte forma: <valor de 16 bits mais significativo em formato decimal>.<valor de 16 bits menos significativo em formato decimal>. A utiliza??o dessa representa??o tem sido questionada pois dificulta o trabalho com express?es regulares j? existentes em diferentes ferramentas, promovendo a modifica??o da representa??o para ?as-plain?, onde se toma simplesmente o valor decimal. do ASN (dentro do espa?o 0 ? 4294967295).
Como forma de contribuir ao debate que est? ocorrendo nesses momentos, em LACNIC cremos importante receber coment?rios da comunidade de nossa regi?o com respeito a esse assunto.

From patara at lacnic.net  Wed Oct  1 11:26:29 2008
From: patara at lacnic.net (Ricardo Patara)
Date: Wed, 1 Oct 2008 11:26:29 -0300
Subject: [LACNIC/Politicas] ASN 32 bits [SP]
Message-ID: <20081001112629.5bc874a3@lacnic.net>

ASN de 32 bits

Introducci?n:

Desde el 1 de enero de 2007, al igual que los dem?s RIRs, LACNIC est? asignando a sus miembros N?meros de Sistemas Aut?nomos (ASNs) de 32 bits.

Hasta ese entonces los ASNs asignados eran de 16 bits con lo que la cantidad m?xima disponible era de aproximadamente 65 mil ASNs.

Anticipando un posible agotamiento del espacio de ASNs de 16 bits, se iniciaron en 2001 los primeros estudios y propuestas para expandir el formato del ASN para 32 bits.

El trabajo concluy? en 2007 con la publicaci?n de un documento de la IETF (Internet Engineering Task Force), llamado RFC 4893. Este documento indica el nuevo formato de ASN, su utilizaci?n en protocolos de ruteo como el BGP y tambi?n su interacci?n con otros sistemas y protocolos que todav?a no han sido actualizados para soportar el nuevo formato.

Desde esa fecha, IANA asigna a los RIRs bloques de ASN de 32 bits para su subsecuente asignaci?n dentro de cada regi?n.


Pol?tica:

Ya en el a?o 2006 se estaba discutiendo a nivel de los RIRs propuestas de pol?ticas para asignaci?n de ASNs de 32 bits. En ellas se mantienen los criterios en cuanto a necesidad de que la organizaci?n sea "multihomed" o de que tuviera una pol?tica ?nica de ruteo para justificar as? la asignaci?n. 
Esa pol?tica para asignaci?n de ASN incluye tambi?n criterios para la transici?n entre la asignaci?n de ASN 16 bits para la de 32 bits.

La pol?tica regional adoptada en LACNIC (que es similar a las de otras regiones) establece que en las solicitudes de ASNs realizadas a partir del 1 de enero de 2007 se debe indicar expresamente que se desea un ASN de 32 bits. En caso contrario la asignaci?n por defecto ser? de un ASN 16 bits.

De acuerdo con esta misma pol?tica, ese criterio debe ser modificado a partir del 1 de enero de 2009. As?, a partir de esa fecha, las solicitudes realizadas considerar?n por defecto la asignaci?n de ASNs de 32 bits, mientras que ASNs de 16 bits ser?n asignados ?nicamente cuando sean expl?citamente solicitados.


Situaci?n Actual:

Es importante recordar que por m?s que a?n existen ASNs de 16 bits disponibles, a partir de enero de 2009 solamente ser?n asignados a quienes explicitamente lo soliciten.



Especialmente cuando como es sabido, existen sistemas y equipos que no soportan ASNs de 32 bits, lo que puede afectar a las organizaciones que est?n optando por una pol?tica de ruteo redundante, para lo que necesitar?n de un ASN y, en algunos casos, de nuevos equipos de enrutamiento.

Entonces si bien no se trata de un problema urgente, pues las proyecciones actuales indican que a?n existen ASNs de 16 bits para 2 o 3 a?os m?s, es un aspecto al que se le debe prestar especial atenci?n.
 
Ante esta situaci?n, creemos importante recomendar que en la planificaci?n y proyectos de nuevas redes se considere la posible necesidad de utilizar ASNs de 32 bits, lo que puede repercutir en las decisiones de compra de nuevos equipos o sistemas de redes.

Se recomienda tambi?n a los administradores de redes ya en operaci?n que verifiquen junto a los proveedores de sus equipos y sistemas, el soporte de ASN de 32 bits en futuras versiones de sus productos.

Si bien los mecanismos para transici?n son simples y permiten que sistemas m?s antiguos funcionen con estos nuevos ASN sin necesidad de actualizaci?n, es importante el soporte a esa nueva versi?n del ASN para contar con todas las herramientas a la que los administradores est?n habituados hasta este momento.

Por ?ltimo, existe en la comunidad global un debate importante sobre el tipo de representaci?n para los ASNs de 32 bits. Hasta el momento la representaci?n elegida consiste en la denominada ?as-dot2? donde los 32 bits se representan de la siguiente manera: <valor de 16 bits m?s significativo en formato decimal>.<valor de 16 bits menos significativo en formato decimal>. La utilizaci?n de esta representaci?n ha sido cuestionada pues dificulta el trabajo con expresiones regulares ya construidas en diferentes herramientas, promovi?ndose en cambio la representaci?n ?as-plain? donde se toma simplemente el valor decimal de ASN (dentro del rango decimal 0 ? 4294967295).
Como forma de contribuir al debate que est? ocurriendo en estos momentos, en LACNIC creemos importante recibir comentarios de parte de la comunidad de nuestra regi?n respecto de este tema.

From francisco at arias.com.mx  Thu Oct 16 15:24:04 2008
From: francisco at arias.com.mx (Francisco Arias)
Date: Thu, 16 Oct 2008 13:24:04 -0500
Subject: [LACNIC/Politicas] Sobre las propuestas de transferencias de
	bloques de IPs en ARIN
Message-ID: <e5de97e20810161124r48d40419l173371f8ba70fff6@mail.gmail.com>

El d?a de ayer y hoy se discutieron en la reuni?n de ARIN las dos
propuestas que hay sobre la mesa en esta regi?n sobre las
transferencias de bloques de IPs y al final de las discusiones se hace
un levantamiento de posiciones a favor y en contra:

La propuesta 2008-2
(http://www.arin.net/policy/proposals/2008_2.html); con 129
participantes; tuvo a favor, 11; en contra 45.
La propuesta 2008-6
(http://www.arin.net/policy/proposals/2008_6.html); con 129
participantes; tuvo a favor, 30; en contra, 18.

La diferencia entre las dos es que la 6, aunque tiene caracter de
temporal, es m?s liberal con pr?cticamente no requerimientos de
participaci?n de parte del staff de ARIN y tuvo m?s apoyo.

B?sicamente se percibe que es necesario tener una pol?tica con
respecto a las transferencias de bloques, pero a?n hay detalles que
definir. En general hubo muchas posiciones encontradas al respecto e
incluso alguien mencion? estar trabajando en otra propuesta de
pol?ticas.

Saludos,

-- 
fjac

From francisco at arias.com.mx  Thu Oct 16 15:40:59 2008
From: francisco at arias.com.mx (Francisco Arias)
Date: Thu, 16 Oct 2008 13:40:59 -0500
Subject: [LACNIC/Politicas] La otra propuesta (idea) sobre las
	transferencias de bloques de IPs
Message-ID: <e5de97e20810161140x7eea36afn371619c267ce0499@mail.gmail.com>

Aunque no es una propuesta formal, se acaba de enviar a la lista de
ARIN la idea que les mencionaba de otra propuesta para transferencias;
aunque al darle la primer le?da no parece hablar mucho sobre
transferencias ...


---------- Forwarded message ----------
From: Azinger, Marla <marla.azinger at frontiercorp.com>
Date: Thu, Oct 16, 2008 at 12:45 PM
Subject: [arin-ppml] Different Approach to the Transfer and Market
issue- input requested
To: "ppml at arin.net" <ppml at arin.net>, "schiller at uu.net" <schiller at uu.net>


Hello-

As promised here is an alternative proposal.  It has not officially
been submitted in order to gain community feedback and revision before
submitting.  Thank you everyone that has already shown interest in
persuing this alternative approach.  Please be advised that this is a
suggested new section to NRPM in addition to keeping the current
section 4.6 Voluntary Partial Returns and Amnesty.

If you are here at ARIN please find Marla Azinger or Jason schiller at
the breaks to discuss.  Cheers!

Name: Active Reclamation of abandoned number resources


Rational:

This policy addresses the following:

Find, reclaim and re-use unused number resources.
Give incentive to keep unused number resources out of the black market.
Assist ARIN in cleaning up the database.
Provide an incentive to self identify and return unused resources.
Increase efficient utilization of ARIN number resources.
Help ease the transition to IPv6.
Help ensure fair re-distribution of resources to those who need them.


NRPM#: Active Reclamation of abandoned number resources

ARIN will actively investigate and ensure abandoned ARIN number
resources including legacy resources that are under ARIN management
are returned to the ARIN address pool for recirculation.  Any one may
submit a report of abandonment for ARIN to investigate.  ARIN may
investigate abandonment without a report when ARIN has reason to
believe it has been abandoned.



ARIN can use their discretion to determine if someone is abusing this
policy by submitting multiple reports with poor evidence of
abandonment.  This will result in a loss of claim to all reports
currently in progress by the perceived abuser  ARIN has the right to
reject investigation requests if they deem the reporting entity is
abusing the policy.



Addresses that are squatted and efficiently used will be granted
amnesty if the addresses are self reported, back billing is reconciled
and any applicable RSA is signed.  Partial returns and amnesty can be
granted to squatted addresses under this policy.



            Management of abandoned number resources

-ARIN will keep a Lost Property Office via a direct link from the main
ARIN website.

-ARIN will publicly list all number resources that are reported
abandoned on the Lost Property Office site and the status of the
investigation.  Stats of recovered space through the abandoned number
resources will be provided bi-annually at the ARIN Members Meetings.

- ARIN will take measures to identify a chain of custody or successor
in interest to the last known POC.  If the successor is determined,
the block will be transferred to the successor under current ARIN
policy.

- If the number resources are not valid for transfer to the successor
and the original finder is not eligible to receive the number
resources then the block will be added back into the ARIN address pool
for re-use.

-The original "finder" is eligible for receipt of the addresses if
they are currently eligible per ARIN policy to receive more addresses
and the addresses are not transferred to a chain of custody that was
discovered during investigation.

- If an investigation reveals a successor who is unaware of their
number resources, ARIN can decide if there is good faith and
sufficient justification for the successor to keep the resources.
Partial returns and amnesty can be granted to sucessors for blocks
revealed in and investigation under this policy.

-Before ARIN re-uses allegedly abandoned resources ARIN will work with
ISP's to route these resources no less than 90 days in order to
validate they are not in use.

-The original "finder" will receive a "finders" compensation for the
listing when either resolution occurs.  *For example a credit could be
put towards their annual fees.

-To report an abandoned block, send a request for investigation via
the Abandoned Block Template.

            Examples of Abandoned number resources:

            - Unused Legacy (e.g. swamp)

            -Business failure and the number resources are not
currently assigned nor in use.

            -Bad recordkeeping by an otherwise functional entity.

            -Squatted space that is not self reported.



_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.



-- 
fjac