[LAC-TF] Fwd: [NCUC-DISCUSS] Numbering issues

marcelo bagnulo braun marcelo at it.uc3m.es
Tue Aug 31 05:43:07 BRT 2004


Hola Carlos,

la verdad que estoy un poco perdido...

El 30/08/2004, a las 17:33, Carlos Afonso escribió:

> Caro Marcelo, gracias muchas por tus comentarios muy relevantes.
>
> Una de las preocupaciones es que, en el "último km", bienes públicos 
> dejen de serlo porque pasan a ser comercializados, en general por un 
> monopolio o cartel privado con fines de lucro (regulado o no).
>
> Nota bene: cobrar por un servicio de distribución no significa 
> necesariamente que el bien siendo distribuido deje de ser público -- 
> hay un obvio costo de mantenimiento y operación que tiene que ser 
> cubierto por la misma comunidad que se beneficia de este bien.

Yo creo que no hay ninguna duda que las direcciones IP (tanto en IPv4 
como en IPv6) son un bien de la comunidad y que los RIRs lo administran 
siguiendo las politicas definidas por la comunidad (te animo a que si 
alguna de las politicas vigentes no te convencen o si se te ocurre otra 
nueva que necesitemos, envies tus comentarios a la lista de politicas 
del lacnic , siempre estamos necesitados de discusiones apasionantes 
:-)

>  Pero cuando un rango de bloques IP pasa a ser cobrado al usuario 
> final a valores astronómicos para generar lucros, este bien público 
> pasa a ser apropiado por intereses comerciales.

Tu inquietud es que los precios que cobran los RIRs son muy altos y no 
corresponden con los costos de operacion? O que los precios de los ISPs 
son muy altos?

Con respecto al tema de los RIRs, creo que el tema costes es bastante 
transparente, pero yo no soy un miembro, asi que tampoco sigo el tema 
muy de cerca.

>
> Entiendo que, por los errores de criterio de alocación de bloques en 
> el "principio de los tiempos" (más o menos motivados por algo parecido 
> a Gates cuando dijo "quién va un día necesitar de más de 640 KB?"), se 
> creó una situación (o más bien una noción) de bien escaso mucho antes 
> de lo que debería ocurrir.
>
> Sin embargo, esto es relativo -- solo los 91 bloques /8 aún reservados 
> por IANA corresponden a 1.4 mil millones de números, y el consumo 
> anual aproximado es del orden de 4 a 6 bloques /8 (algo como 80-100 
> millones al año), sin que eso signifique que entren en uso efectivo, 
> claro. Menos de 25 /8s han sido alocados por el conjunto de los RIRs 
> en cinco años - y ya pasamos por la burbuja y su explosión hace 
> tiempo. (datos de RIPE, basados en info aportada por todos los RIRs e 
> IANA.)
>
> Pero se ha, digamos, creado la noción de escasez desde hace años, y 
> eso dió obviamente margen a la prevalencia de comercialización en el 
> "último km".
>

No entiendo mucho la relacion que tienen estos tres parrafos con lo 
anterior...

> Mi punto es: no es necesario pensar en una política que busque 
> minimizar o eliminar eso cuando tengamos "velocidad de crucero" en 
> IPv6? No queremos cometer la misma "naivete" del "principio de los 
> tiempos", creo yo.

Podes definir "eso" de forma mas concisa? estoy un poco perdido...

>
> Bueno, esta discusión no es nueva - veo mensajes en las listas de IANA 
> desde el 1998 tratando de discutir el asunto.
>
> Entiendo que el énfasis en la lista LAC-TF es mucho más de "casa de 
> máquinas" - que es fundamental, claro - que de políticas de ese tipo - 
> que también lo son.

Politicas es lo que se discute en el LACNIC

> Quizás si pudiera tener en el próximo encuentro LACNIC un panel o 
> "track" de discusión sobre eso?
>

Me gustaria entender un poco mas el problema en cuestion.
Cual es exactamente el problema y si es que existe, la solucion 
propuesta

gracias, marcelo

> Por favor, tiren mis orejas si estoy diciendo tonterías o 
> trivialidades... :)
>
> []s frats
>
> --c.a.
>
> At 05:28 30/08/2004, you wrote:
>
>> Hola Carlos,
>>
>> Hasta lo que yo se, las direcciones IP ya son un patrimonio de la 
>> comunidad (tanto en IPv4 como en IPv6) y la comunidad los administra 
>> a traves de los RIRs, quienes ejecutan las politicas definidas por la 
>> comunidad.
>> En IPv4, el problema es que es un patrimonio de la comunidad, pero es 
>> escaso, por lo que hay que recurrir a NATs. Pero eso lo decide asi la 
>> propia comunidad basada en criterios tecnicos.
>> En IPv6, no hay tal limitacion, por lo que se pueden evitar esos 
>> dispositivos.
>> Sin embargo, tanto en IPv6 como en IPv4, la unica forma de preservar 
>> la escalabilidad del sistema de rutas es la agregacion por proveedor. 
>> Eso significa, que un sitio final debe ontener direcciones de su 
>> proveedor. ahora bien, esto no es un tema comercial, pero es un tema 
>> tecnico. simplemente no sabemos como preservar la escalabilidad del 
>> sistema de rutas de otra manera (las nuevas ideas son bienvenidas :-)
>>
>> Esto implica que los sitios finales pueden llegar a tener una 
>> dependencia de sus proveedores ya que cambiar de proveedor signiffica 
>> renumerar y esto puede ser costoso (sobre todo para un sitio grande). 
>> En IPv6, se ha tratado que la renumeracion sea mas simple, pero 
>> todavia tiene un costo no nulo.
>>
>> Espero que esto sirva para inicar el tema que planteas para discusion,
>> saludos, marcelo
>>
>> El 27/08/2004, a las 20:41, Carlos Afonso escribió:
>>
>>> Caríssimas y carísssimos,
>>>
>>> El mensaje abajo del compa Harold menciona asunto de gran 
>>> importancia sobre
>>> los criterios de distribución de números (y bloques de números) IPv6.
>>>
>>> En mi visión, tal como los ccTLDs, números IP deberían ser 
>>> considerados
>>> patrimonio de la comunidad ("assets of the commons" o bienes 
>>> públicos), no
>>> "commodities". No es así con muchos de los ccTLDs, y sabemos que la
>>> distribución de IPs por proveedores es un comercio como cualquier 
>>> otro.
>>>
>>> Ahora estamos en un nuevo paradigma, el de IPv6, en que hay 
>>> abundancia y no
>>> escasez de este recurso (argumento usado por algunos para que se 
>>> comercialize
>>> la cosa) -- más razón todavía para que sea considerado y tratado 
>>> como un bien
>>> público.
>>>
>>> Me gustaría debatir un poco el asunto en el ámbito de LACNIC como en 
>>> el ámbito
>>> de la gestión de esos recursos en Brasil.
>>>
>>> []s fraternos
>>>
>>> --c.a.
>>>
>>> ----------  Mensagem encaminhada  ----------
>>>
>>> Subject: [NCUC-DISCUSS] Numbering issues
>>> Date: Thursday 26 August 2004 14:15
>>> From: Harold Feld <hfeld at MEDIAACCESS.ORG>
>>> To: NCUC-DISCUSS at LISTSERV.SYR.EDU
>>>
>>> Hi everyone!
>>>
>>> I am back from a fantastic conference on community wireless 
>>> networking.  In
>>> the United States, there is increasing interest by non-commercial
>>> organizations to use unlicensed spectrum access to provide free or 
>>> low-cost
>>> Internet connectivity to poor urban neighborhoods and rural 
>>> communities.
>>>
>>> At the conference, I discovered that there is an urgent need for more
>>> address space.  Nearly all community wireless networks are deployed 
>>> behind
>>> NAT boxes, which creates difficulties for those trying to foster
>>> independent community media projects or voice over IP for community 
>>> networks.
>>>
>>> The issue is purely financial.  Community networks cannot afford v6 
>>> blocks
>>> of address space.    While address blocks are modestly priced by 
>>> commercial
>>> standards, they are beyond the reach of community wireless projects.
>>> I had
>>> one administrator tell me that the cost of a v6 block would be 
>>> higher than
>>> the cost of his entire network combined.  What is worse, because it 
>>> is an
>>> annual registration fee, v6 space would constitute a continuing
>>> expense.  Even if a network can raise the money for an initial 
>>> registration
>>> via a grant, there is a problem of sustainability.
>>>
>>> In any event, what is needed is not a one shot cure for a single 
>>> network,
>>> but a systemic way of addressing the issue.  I would very much like 
>>> to talk
>>> to people in the RIR community about this issue in the hopes of 
>>> working out
>>> a solution (I have some ideas).  But I do not know who in the RIR 
>>> community
>>> or the broader ICANN community would be interested and sympathetic 
>>> to the
>>> issue.
>>>
>>> I suspect this issue goes beyond the scope of the NCUC, since this 
>>> is the
>>> naming side of the street. However, I expect that access to address 
>>> space
>>> has been a long standing issue outside of the U.S., and would be 
>>> very eager
>>> to hear from anyone outside the U.S. what problems getting affordable
>>> address space you have and what solutions (other than NAT) are 
>>> available.
>>>
>>> Finally, if there is a sense within the Consticuency that numbering 
>>> issues
>>> are appropriately addressed here (since there is no other place 
>>> within the
>>> ICANN structure to raise issues of unique concern to the 
>>> noncommercial
>>> community), please let me know.
>>>
>>> Harold Feld
>>>
>>> -------------------------------------------------------
>>>
>>> --
>>> Carlos A. Afonso
>>> diretor de planejamento e estratégia
>>> Rits - Rede de Informações para o Terceiro Setor
>>> Rua Guilhermina Guinle 272 - sexto andar
>>> 22270-060 Rio de Janeiro BRASIL
>>> telefone +55-21-2527-5494
>>> telefax  +55-21-2527-5460
>>> http://www.rits.org.br
>>>
>>>
>>> _______________________________________________
>>> LACTF mailing list
>>> LACTF at lac.ipv6tf.org
>>> http://lacnic.net/mailman/listinfo/lactf
>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lac.ipv6tf.org
>> http://lacnic.net/mailman/listinfo/lactf
>>
>>
>
>
> ===
> Carlos A. Afonso
> diretor de planejamento e estratégia
> Rede de Informações para o Terceiro Setor - Rits
> Rua Guilhermina Guinle 272 - sexto andar
> 22270-060 Rio de Janeiro Brasil
> telefone +55-21-2527-5494
> telefax +55-21-2527-5460
> rits at rits.org.br
> http://www.rits.org.br
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.744 / Virus Database: 496 - Release Date: 24/08/2004
> _______________________________________________
> LACTF mailing list
> LACTF at lac.ipv6tf.org
> http://lacnic.net/mailman/listinfo/lactf




More information about the LACTF mailing list