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

Mon Aug 30 12:33:20 BRT 2004

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. 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.

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".

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.

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. Quizás si pudiera tener en el próximo encuentro LACNIC un 
panel o "track" de discusión sobre eso?

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
-------------- next part --------------

---
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