[LACNIC/Politicas] Sumary Week 23th May - 29th May - Resumen Semana del 23 al 29 de Mayo - Sumário Semana 23 ao 29 de maio.

Roque Gagliano roque at lacnic.net
Tue Jun 9 16:45:31 BRT 2009

Português abaixo.
Español a continuación.

Summary of Public Policy List discussions from 24 May to 31 May, 2009

[LACNIC-2007-01] Modification of the IPv6 Block Announcement Policy

The following is a summary of the comments received in relation to this
policy. The full text of the policy can be found at the following  


[Pedro Torres - 25 May 2009] - The Portuguese and Spanish versions of  
text make it clear that a single block which aggregates the entire
assignment must be announced (via BGP). This does not exclude the
possibility of announcing more specific prefixes. For example, a /32
accompanied by two /33s or several /48s. Is this the object of rule? The
English version of the text does not say exactly this. My suggestion  
is that
a future revision of the policy excludes such recommendation which,  
from my
point of view, is merely operational.

[Nicolás Antoniello - 25 May 2009] - A proposal for modifying the  
policy and
eliminating this requirement already exists.

[Pedro Torres - 25 May 2009] - The proposal refers to section,  
4.5.4. I would like to see the proposal applied to the entire policy  
mainly to section 4.5.4).

[Francisco Arias - 26 May 2009] - Reply to Pedro Torres’s comments:

According to two good sources that I show below, the verb "shall" is
equivalent in strength to "must":


And yes, the proposal of Nicolas (LAC-2007-01) is about LIRs and you
comment was about the section on End-users.

[Nicolás Antoniello - 29 May 2009] - I believe we should work together  
on a
revision of the IPv6 block assignment policy with the aim of removing
routing aspects from said policy.

A proposal similar to the one presented at RIPE, which I mentioned on
Wednesday during the presentation of the LACNIC-2007-01 policy, can be  
at the following address:


The arguments are similar in many aspects to those that were raised  
the discussion the other day.

I believe we could divide the arguments in two parts: one for the  
arguments, the other for the political arguments. In light of the
discussions we have had during these past three years regarding this  
I also think that we should focus on the political aspect, i.e. the  
that an assignment policy should not include technical routing  
least of all when it can be inferred from the policy itself that RIRs  
do not
have the tools for monitoring their compliance. In addition, I  
believe that the routing issue should be left up to the relationships
between LIRs, ISPs, carriers, etc.

[Jordi Palet - 29 May 2009] - It is important to observe that the  
of a policy proposal in a specific region (in this case RIPE) does not  
that it will be accepted. At this moment, although there are many  
in favor of accepting this policy, consensus has NOT been achieved and  
are well-founded opinions indicating that if this modification is  
IT NECESSARILY FOLLOWS that many aspects and texts referring to  
routing have
to be changed in many other policies, and I doubt that this can be  
done with
“improper timing”.

On the other hand, I insist on one of the aspects I mentioned during the
meeting: If we change this only at LACNIC, who will guarantee that the
operators in other regions will respect this disaggregation and  
that our traffic will not be filtered??? I believe that this would be  
serious, and it has been proven that there are still operators that  
/48s originating from PI IPv6 space in other regions and it takes  
months, if
not years, to get these restrictions lifted.

I believe disaggregation is bad and, because technical solutions  
exist, it
is preferable to adopt them before reaching a future situation where the
number of routes becomes unacceptable for many ISPs, specially small and
medium-sized ISPs, which would need to make huge investments for using
routers that in today's world do not even exist.

Clearly this type of changes in network operation only benefits larger
companies who do not mind multiplying the cost of their routers by  
hundred thousand; in the end, such changes are paid by all operators and
Internet users, simply for not having invested more resources for the
operation of networks with MORE cooperation or, in short, being "better

Our efforts in attempting to introduce this type of policy modifications
would be put to better use in attempting to increase cooperation in  
operation, a better implementation of better protocols (if you'll  
excuse the
repetition), for example by having the work carried out at the IETF
regarding LISP become operational as soon as possible.

[Luis Carlos Solano - 29 May 2009] - Disaggregation is very bad, it is  
However, I think that in IPv6, because a /48 is so large, it lends  
itself to
disaggregation at commercial levels.

It could be the case that a large customer and/or a particular service
require an exclusive STM-4 link. Considering that a /48 may be  
for that customer, commercial reasons (differentiated service) appear to
indicate that said /48 should be routed through a particular link.

Evidently, an ISP that announces a /48 would be considered an enemy of  
community (this is an extreme example) but, because the minimum unit  
is so
large, perhaps each one of these minimum units could generate enough  
to fill a BGP session of an ISP.

Thus, it is my humble opinion that everything related to routing  
should be
eliminated from every policy. Best practices will dictate the size of
routing filters so that "bad neighbors" will be at risk of being  

[Pedro Torres - 29 May 2009] - I would like to stress the fact that the
current policy already allows disaggregation.

Current policy text:

"Announce a single block on the Internet inter-domain routing system,
aggregating the total IPv6 address allocation received, within a  
period not
longer than 12 months."

I understand that the current policy allows fragmentation, as long as a
single block that aggregates all prefixes is announced together with the
smaller prefixes. The text says nothing about more specific prefix
announcements not being allowed together with the announcement of the  

My proposal is to remove all operational requirements; what we must  
is a recommendation stating that fragmentation should be avoided.

[Ricardo Patara - 29 May 2009] - A comment on the Portuguese wording  
of the

The phrase "Anunciar no sistema de roteamento inter-domínio da  
Internet um
bloco único" has a very different meaning than "Anunciar no sistema de
roteamento inter-domínio da Internet um _unico_ bloco."

The Spanish text is worded as follows:

"Anunciar en el sistema de rutas inter-dominio de Internet un único  

[Jordi Palet - 29 May 2009] - If you have a customer who is large  
enough to
have to announce its /48, the most logical thing would be for that  
to receive that /48 (or the corresponding prefix size) directly from  
(as PI IPv6), because most probably that customer already has several  
to the Internet (with one or more providers). Thus it would not be  
to disaggregate that prefix from yours, but rather it would be a  

If we eliminate this restriction from the policy, as long as this does  
happen in the other regions, a situation might occur where "all" LACNIC
region operators could be considered "bad neighbors".

[Luis Carlos Solano - 29 May 2009] - This is correct. What is not  
clear to
me in this scheme of things is what the benefit for the global routing  
would be. If this were to happen, the global routing table would have  
a /32
(that of the ISP) and a /48 (that of the client). I think that the end
result would be the same.

However, what is clear to me is that a "bad" ISP may negatively  
with thousands of /48s, whereas individual /48 assignments may be  
easier to

[Scott Leibrand - 29 May 2009] FYI, a new proposal (Open Access To  
IPv6) was
just posted to the public policy mailing list (PPML) in ARIN that would
(among other things) remove "by advertising that connectivity through  
single aggregated address allocation" from article 3 of section

In my personal opinion, LACNIC would not be considered a "bad  
neighbor" if
you were to do the same.

[Pedro Torres - 29 May 2009] - Portuguese term "único" meaning  

In any case, we will work to propose that operational aspects not be
discussed in the policy.

- -------------------------
Sumário das discussões na Lista Pública de Políticas desde o dia 23 de  
até o dia 31 de maio de 2009.

[LACNIC-2007-01] Modificação à  política de publicação de blocos IPv6

A seguir  são sumarizados os comentários que houve acerca dessa  
Veja texto completo da mesma em:

[Pedro Torres - 25 maio 2009] – A versão do texto em português e  
deixa claro que um bloco único que agregue toda a designação deve ser
anunciado (via BGP).  Isso não exclui a possibilidade de que sejam
anunciados prefixos mais específicos. Por exemplo, um /32 acompanhado de
dois /33 ou alguns /48s. É esse o objetivo da regra? A versão em  
inglês não
disse exatamente isso. Minha sugestão é que numa próxima revisão da  
essa recomendação seja excluída já que, segundo meu ponto de vista, é
puramente operacional”.

[Nicolás Antoniello - 25 maio 2009] - Existe uma proposta de  
modificação da
política que propõe eliminar esse requerimento.

[Pedro Torres - 25 maio 2009] – A proposta refere à seção e não
4.5.4. Gostaria de ver a proposta aplicada à política completa (e
principalmente ao ponto 4.5.4).

[Francisco Arias - 26 maio2009] - De acordo com duas boas fontes ao  
modal “shall” é equivalente em tenacidade ao “must”. Ver:


Francisco concorda que a proposta de Nicolas (LAC-2007-01) se refere aos
LIRs e ISPs porem os comentários de Pedro Torres são sobre a seção de
usuários finais.
[Nicolás Antoniello - 29 maio 2009] – Concordo com a proposta de Pedro e
acredito que devemos trabalhar em parceria numa revisão da política de
designação de blocos IPv6 com o objetivo de remover os aspectos de
roteamento da mesma. Na seguinte URL:


está disponível a proposta similar de RIPE à que fiz referência na
apresentação da política LACNIC-2007-01 na quarta-feira.

Os argumentos são similares em vários aspectos aos aportados na  
discussão do
outro dia.

Acredito que poderíamos separar os argumentos em duas partes, uma com os
argumentos técnicos e outra com os argumentos políticos. Também acho  
que à
luz da discussão que tivemos sobre esse assunto nesses últimos três  
deveríamos focar-nos no aspecto político, isto é, no argumento de que  
política de designação não deveria incluir imposições técnicas de  
e menos ainda quando da mesma política desprende-se que os RIRs não  
ferramentas para controlar seu cumprimento. Além disso fica claro que na
minha opinião que o assunto do roteamento deve deixar-se  às relações  
LIRs, ISPs, Carriers, etc...

[Jordi Palet - 29 maio 2009] – É importante dar-se conta de que uma  
de política em uma determinada região (neste caso RIPE) não implica  
que será
aceita. Neste momento, na lista de discussão ainda que existam muitas  
a favor de que essa política seja aceita, NÃO HÁ consenso, e há  
opiniões bem
fundadas de que se for aceita essa mudança, também forçosamente haverá  
mudar muitos aspectos e textos referidos ao roteamento em muitas outras
políticas, e duvido que isso possa ser feito “a destempo”.

Do outro lado insisto em um dos aspectos que salientei na reunião: se  
o mudarmos no LACNIC, qual vai ser a garantia de que os operadores das
outras regiões vão respeitar essa desagregação e portanto nosso  
tráfego não
vai ser filtrado??? Acredito que isso seria muito grave, e são casos
provados que ainda há operadores que filtram /48 procedentes de IPv6  
PI em
outras regiões e demora meses ou melhor, anos em conseguir que isso  

Acredito que a desagregação é ruim, e existindo soluções técnicas, é  
adotá-las antes de chegar a uma situação futura em que o número de rotas
seja inaceitável para muitos ISPs, principalmente para os pequenos e  
que teriam que fazer investimentos enormes em usar routers que ainda nem
sequer existem.

É claro que esse tipo de mudanças na operação das redes somente  
aos grandes que não têm problemas em multiplicar por milhares o preço do
custo de seus routers, e essa mudança no final somos nós, os  
operadores e
usuários da Internet que acabamos pagando somente por não investir mais
recursos em operar as redes com MAIS cooperação, definitivamente sendo
“melhores Interent-citizens”.

Os esforços que realizamos em tentar este tipo de modificações nas
políticas, estariam melhor utilizados em incrementar a cooperação na
operação das redes, implementar melhor melhores protocolos (valha a
redundância), como por exemplo em conseguir que o esforço realizado no  
ao respeito de LISP seja operativo o mais rápido possível.

[Luis Carlos Solano - 29 maio 2009] – A desagregação é muito ruim, com
certeza, mas eu acredito que em IPv6, por ser um /48 tão grande, se  
para a desagregação, a níveis comerciais.             Poderia  
acontecer que
um cliente/ grande/ e/ ou/ serviço particular precise somente para  
ele, um
enlace STM-4. Em vista de que um /48 pode ser suficiente para esse  
pareceria que por motivos comerciais (serviço diferenciado) esse /48  
ser roteado por um enlace em particular.

Evidentemente, um ISP que anuncie um /48 seria um inimigo da  
comunidade (e é
um exemplo extremo) mas sendo a unidade mínima tão grande, cada uma  
unidades mínimas poderia gerar suficiente tráfego para encher uma  
sessão BGP
de um ISP.

Na minha humilde opinião é que em todo o relativo ao roteamento deve
eliminar-se qualquer política. As melhores práticas vão impor o  
tamanho dos
filtros nos roteadores de modo que os /maus vizinhos/ se exponham a  

[Pedro Torres - 29 maio 2009] – Gostaria de enfatizar que a política  
já permite desagregação.

Texto da política atual:

"Anunciar no sistema de roteamento inter-domínio da Internet um único  
que agregue toda a alocação de endereços IPv6 recebida, em um prazo  
até 12

Na política atual, entendo que a fragmentação é permitida, desde que,  
com a fragmentação seja anunciado um bloco único que agregue todos os
O texto não comenta nada de que junto com o anúncio do bloco único não
possam existir anúncios de prefixos mais específicos.
A minha proposta é  de removermos qualquer imposição operacional, o que
  devemos colocar é uma recomendação de que a fragmentação deve ser  

[Ricardo Patara - 29 maio 2009] - Um comentário do idioma:

"Anunciar no sistema de roteamento inter-domínio da Internet um bloco  

tem um significado bastante diferente do que:

"Anunciar no sistema de roteamento inter-domínio da Internet um _único_

No texto em espanhol temos:

"Anunciar en el sistema de rutas inter-dominio de Internet un único  

[Jordi Palet - 29 maio 2009] – Se tiver um cliente o suficientemente  
como para que precise anunciar seu /48, o mais lógico seria que esse  
recebesse do LACNIC diretamente (como IPv6 PI) esse /48 (ou o tamanho de
prefixo que corresponder) porque o mais provável é que esse cliente  
vários caminhos para a Internet (com um ou vários provedores). Assim  
que não
seria necessário desagregar esse prefixo seu mas sim outro diferente.

Se eliminarmos essa restrição da política, enquanto isso não ocorrer em
outras regiões, poderia acontecer que “todos” os operadores da região do
LACNIC puderem ser considerados “maus vizinhos”.

[Luis Carlos Solano - 29 maio 2009] – Isso está certo. O que no fica  
para mim nesse esquema são as vantagens na tabela de rotas globais. Se  
acontecer, a tabela de rotas global terá um /32  (o do ISP) e um /48 (do
cliente). O resultado final acho que seria o mesmo.

Sim tenho claro contudo, que um /mau/ ISP pode colaborar negativamente  
milhares de /48s, enquanto que podem ser mais controláveis as  
individuais de /48s.

[Scott Leibrand - 29 maio 2009]  A título de informação, foi publicada
recentemente uma nova proposta (Open Access To IPv6) na lista pública de
políticas (PPML) do ARIN que entre outras coisas eliminaria a frase “by
advertising that connectivity through its single aggregated address
allocation" do Artigo 3 da seção

Na minha opinião, o LACNIC não seria considerado um "mau vizinho" se
fizessem o mesmo.

[Pedro Torres - 29 maio 2009] - Único com significado de "singular".

De qualquer forma vamos trabalhar para propor que as questões  
não sejam tratadas na política.

- -------------------------

Resumen de las discusiones en la Lista Pública de Políticas desde el  
24 de
Mayo 2009 hasta el 31 de Mayo.

[LACNIC-2007-01] Modificación a la política de publicación de bloques  

A continuación se sumarizan los comentarios que hubo sobre esta  
Ver texto completo de la misma en:

[Pedro Torres - 25 mayo 2009] - La versión del texto en portugues y  
deja claro que un bloque único que agregue toda la asignación debe ser
anunciado (via BGP). Esto no excluye la posibilidad de que sean  
prefijos más específicos. Por ejemplo, un /32 acompañado de dos /33 o
algunos /48s. Es este el objetivo de la regla? La versión en inglés no  
exactamente eso. Mi sugerencia es que una próxima revisión de la  
excluya tal recomendación, que desde mi punto de vista es puramente

[Nicolás Antoniello - 25 mayo 2009] - Existe una propuesta de  
de la política que propone eliminar ese requerimiento.

[Pedro Torres - 25 mayo 2009] - La propuesta habla de la sección y
no 4.5.4. Me gustaría ver la propuesta aplicada a la política completa  
principalmente al punto 4.5.4).

[Francisco Arias - 26 mayo 2009] - De acuerdo con dos buenas fuentes el
verbo modal “shall” es equivalente en tenacidad al “must”. Ver:


Afirma que la propuesta de Nicolas (LAC-2007-01) se refiere a LIRs y los
comentarios de Pedro Torres son sobre la sección de usuarios finales.

[Pedro Torres - 26 de mayo 2009] - Concuerda con el comentario  
anterior de
Francisco Arias. Respecto al texto planteado en LACNIC-2009-01, observa
     que sería posible integrar el texto utilizado en ARIN/RIPE/APNIC  
por ser
muy similar.

[Nicolás Antoniello - 29 mayo 2009] - Me parece bien la propuesta de  
Pedro y
creo que debemos trabajar juntos en una revisión de la política de
asignación de bloques IPv6 con la finalidad de remover los aspectos de
routing de la misma.
En la siguiente URL:


se encuentra la propuesta similar de RIPE de la que les hablaba el  
en la presentación de la política LACNIC-2007-01.

Los argumentos son similares en muchos aspectos a los que se aportaron  
en la
discusión del otro día.

Creo que podríamos separar los argumentos en dos partes, una con los
argumentos técnicos y otra con los argumentos políticos. Pienso  
también que
a la luz de la discusión que hemos tenido en estos tres últimos años  
este tema, deberíamos centrarnos en el aspecto político, es decir, en el
argumento de que una política de asignación no debería incluir  
técnicas de routing y menos aún cuando de la misma política se  
desprende que
los RIR no poseen herramientas para controlar su cumplimiento. Además  
está, que personalmente creo que el tema de routing debe dejarse a las
relaciones entre LIRs, ISPs, Carriers, etc...

[Jordi Palet - 29 mayo 2009] - Es importante darse cuenta de que una
propuesta de politica en una determinada region (RIPE en este caso), no
implica que vaya a ser aceptada. En este momento, en la lista de  
aunque hay muchas opciones a favor de que se acepte esta politica, NO  
consenso, y hay opiniones bien fundadas que indican que si se acepta  
cambio, TAMBIEN FORZOSAMENTE, hay que cambiar muchos aspectos y textos
referidos al routing en muchas otras  politicas, y dudo que se pueda  
"a destiempo".

Por otro lado insisto en uno de los aspectos que indique en la  
reunion: Si
  lo cambiamos solo en LACNIC, quien nos garantiza que los operadores  
de las
demas regiones respeten dicha desagregacion y por tanto nuestro  
trafico no
sea filtrado ??? Creo que esto seria muy grave, y son casos probados  
que aun
hay operadores que filtran /48 procedentes de IPv6 PI en otras  
regiones y se
tarda meses, sino años, en conseguir que esto se relaje.

Creo que la desagregacion es mala, y habiendo soluciones tecnicas, es
preferible adoptarlas antes que llegar a una situacion en el futuro en  
el numero de rutas sea inaceptable para muchos ISPs, sobre todo los  
y medianos, que tendrian que hacer inversiones astronomicas en utilizar
routers que hoy por hoy, ni siquiera existen.

Esta claro que este tipo de cambios en la operación de las redes, solo
beneficia a los mas grandes, que nos les importa multiplicar por varios
cientos de miles el precio del coste de sus routers, y tal cambio al  
lo pagamos todos los operadores y usuarios de Internet, solo por no  
mas recursos en operar las redes con MAS cooperacion, en definitiva  
"mejores Internet-citizens".

Los esfuerzos que realizamos en intentar este tipo de modificaciones  
en las
politicas, estarian mejor empleados en incrementar la cooperacion en la
operación de las redes, implementar mejor protocolos mejores (valga la
redundancia), como por ejemplo en lograr que el esfuerzo que se hace  
en el
IETF al respecto de LISP, sea operativo lo antes posible.

[Luis Carlos Solano - 29 mayo 2009] - La desagregación es pésima,  
pero pienso que en IPv6, por ser un /48 tan grande, se presta para la
desagregación, a niveles comerciales.
Podría darse que un cliente /grande/ y/o servicio particular  necesite  
para él, un enlace STM-4.  En vista que un /48 puede ser suficiente  
para un
ese cliente, parecería que por razones comerciales (servicio  
ese /48 debería enrutarse por un enlace en particular.

Evidentemente, un ISP que anuncie un /48 sería un enemigo de la  
comunidad (y
es un ejemplo extremo), pero al ser la unidad mínima tan grande,  
podría cada
una de estas unidades mínimas generar suficiente tráfico para llenar una
sesión BGP de un ISP.

Mi humuilde opinión es entonces que todo lo relacionado con el  
debe eliminarse cualquier política. Las mejores prácticas dictarán el  
de los filtros en los enrutadores de modo que los /malos vecinos/ se
expongan a ser filtrados.

[Pedro Torres - 29 mayo 2009] - Me gustaria enfatizar que la politica  
ya permite desagregación.

Texto de la política actual:

"Anunciar en el sistema de rutas inter-dominio de Internet un único  
que agregue toda la distribución de direcciones IPv6 recibida, en un  
no mayor de 12 meses."

Entiendo que en la política actual la fragmentación es permitida,  
que junto con la fragmentación sea anunciado un bloque único que agregue
todos los prefijos.
El texto no comenta nada de que junto con el anuncio del bloque único no
puedan existir anuncios de prefijos mas específicos.
Mi propuesta es remover cualquier imposición operacional, lo que debemos
colocar es una recomendación de que la fragmentación debe ser evitada.

[Ricardo Patara - 29 mayo 2009] - Un comentario del idioma:
"Anunciar no sistema de roteamento inter-domínio da Internet um bloco  

tiene un significado bastante diferente se fuera:

"Anunciar no sistema de roteamento inter-domínio da Internet um _unico_

En el texto en espanol tenemos:

"Anunciar en el sistema de rutas inter-dominio de Internet un único  

[Jordi Palet - 29 mayo 2009] - Si tienes un cliente lo suficientemente
grande para que necesite anunciar su /48, lo mas logico, es que ese  
reciba de LACNIC directamente (como IPv6 PI) ese /48 (o el tamaño de  
que corresponda), porque lo mas probable es que ese cliente tenga varios
caminos hacia Internet (con uno o varios proveedores). Asi que no haria
desagregar ese prefijo del tuyo, sino que seria otro diferente.

Si eliminamos esa restriccion de la politica, mientras eso no ocurra en
otras regiones, podria darse el caso de que "todos" los operadores de la
region de LACNIC, puedan ser considerados "malos vecinos".

[Luis Carlos Solano - 29 mayo 2009] - Eso es correcto. Lo que no me  
claro en este esquema es la ganancia en la tabla de rutas global. Si eso
sucede, la tabla de rutas global tendrá un /32 (el del ISP) y un /48  
cliente). El resultado final creo que sería el mismo.

Si tengo claro no obstante, que un /mal/ ISP puede colaborar  
con miles de /48s, mientras que pueden ser más controlables las  
individuales de /48s.

[Scott Leibrand - 29 mayo 2009]  FYI, a new proposal (Open Access To  
was just posted to the public policy mailing list (PPML) in ARIN that  
(among other things) remove "by advertising that connectivity through  
single aggregated address allocation" from article 3 of section

In my personal opinion, LACNIC would not be considered a "bad  
neighbor" if
you do the same.

[Pedro Torres - 29 mayo 2009] - Único con significado de "singular".

De todos modos vamos a trabajar para proponer que no se traten  
operacionales en la política.

- -------------------------
Roque Gagliano
roque at lacnic.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <https://mail.lacnic.net/pipermail/politicas/attachments/20090609/cba014e0/attachment.sig>

More information about the Politicas mailing list