[LACNIC/Politicas] Fwd: [ipv6-wg at ripe.net] Policy forallocation of IPv6 address space from IANA to RIRs

Thu Aug 12 12:00:14 BRT 2004

Contesto debajo.

---- Original Message ----
From: "marcelo bagnulo braun" <marcelo at it.uc3m.es>
To: "JORDI PALET MARTINEZ" <jordi.palet at consulintel.es>
Cc: <politicas at lacnic.net>
Sent: Thursday, August 12, 2004 2:02 PM
Subject: Re: [LACNIC/Politicas] Fwd: [ipv6-wg at ripe.net] Policy
forallocation of IPv6 address space from IANA to RIRs 

> El 12/08/2004, a las 13:36, JORDI PALET MARTINEZ escribió:
> 
>> Hola Marcelo,
>> 
>> En parte estoy de acuerdo contigo, empezando porque el HD-ratio
>> tendria que ser modicado ...
>> 
> 
> ok
> 
>> Pero conociendo detalles que no puedo dar de lo que estan pensando
>> varios grandes operadores (mas grandes que Telia, que por cierto es
>> mas grande que lo que parece), creo que su estrategia es correcta y
>> ademas buena para la agregacion.
>> 
> 
> Si, si para la agregacion es muy bueno, lo que me preocupa son las
> direcciones

Haciendo numeros veras que no hay de que preocuparse ;-)

Es mas, estoy seguro que habra una proxima version de IP, pero no por el tema de espacio, sino posiblemente para solucionar muchas mas cosas ... pero quedan muchos mas años para eso (cuando nosotros nos jubilemos, posiblemente !).

> 
>> Te pongo un ejemplo con un /32, solo podrian tener 65535 clientes
>> asignando /48.
>> Solo en ADSL Telia tiene varios millones. Pero si ademas contamos GPRS
>> y 3GPP, ya no te digo como sale la cuenta. Telia quiere usar /48 para
>> TODOS sus clientes (aunque sean telefonos moviles),
> 
> esto me parece una locura
> Asignarles un /64 todavia (aunqque lo razonable seria un /128)

La recomendacion tanto 3GPP como IETF (RFC3177) es al menos un /64.

> 
>>  y creo que es acertado, porque ademas de facilitar enormemente la
>> gestion de la red
> 
> si esta claro que para ellos es mucho mas facil, y ademas ya tienen
> muchas direcciones por si acaso las cosas despues no van tan bien :-)

No te creas, su calculo, yo lo he visto, y excepto por el error impuesto por el HD-ratio, no es exagerado en absoluto para los proximos 3-4 años (SOLO). Lo que posiblemente no sabes es lo "grande" que es Telia y como gestiona el direccionamiento de sus "ISPs" asociados, ademas de otros muchos detalles. Creeme, no es nada exagerado.

> 
>>  y ofrecer un buen servicio
> 
> en que mejora el servicio?

Simplemente el hecho de evitar la renumeracion si surgen nuevas subredes en un cliente, me parece mas que un muy buen motivo.

> 
>> y posiblidades de crecimiento a largo plazo a los clientes (evitando
>> renumeraciones si mas adelante necesitan hacer subredes, cosa que por
>> lo general en un hogar no es necesario - hoy), permiten que los
>> telefonos sean routers.
> 
> 
> Ok, si el telefono es un router, con un /64 seria suficiente,
> un /48 es para cuando no solo el telefono es un router pero cuando
> ademass hay routers detras del telefono, lo cual no me parece muy
> comun, nii siquiera en Suecia :-)

Si es un router es facil que tanga varias subredes ... (no hace falta que haya otros routers)

> 
> ademas, que problema hay en renumerar si se necesitan mas direcciones?
> digo, yo entiendo que un sitio con un millon de nodos y muchas
> aplicaciones le pueda resultar un problema renumerar, pero a un
> telefono movil, te parece que es tanto problema renumerar? ademas con
> dhcp stateless autoconfiguration y demas facilidades, no te parece que
> renumerar un solo nodo deberia ser facil?

Si hay servicios registrados en DNS, aunque solo sea uno (el propio telefono por ejemplo), ya es un trastorno. No solo es cuestion de direcciones, sino de los nombres que asociamos a ellas, precisamente para no usar las direcciones ;-)

> Creo que se ha creado un monton de FUD alrededor de los evenetos de
> renumbering y parece que es un argumento usado para que incluso una red
> increiblmenete simple como la de un par de nodos pueda usarlo.
> Lo lamento, yo no compro este argumento, una red que consiste en un
> telefono movil puede ser renumerada muy facilmente.
> 

De todos modos te insisto en que solo con las xDSL y resto de accesos de Telia casi justifican ese prefijo, aun cuando solo contaramos con /64 para cada telefono.

> 
>>  Lo cual me parece correcto (aunque la recomendaciones es /64 en este
>> caso pero como "minimo").
>> 
> 
> Las recomendaciones para un solo nodo son un /128, ya asignarle un /64
> es una exageracion

No en el caso de 3GPP (RFC3177 y documentso 3GPP, ademas de otros docs IETF).

> 
>> Soy partidario de no malgastar, pero tampoco de que el ahorro excesivo
>> sea contraproducente.
>> 
> 
> Ya he escuchado comentario que sera necesario cambiar el /48 y luego el
> /64 porque no sera posible mantener el ritmo de asignacion, si ademas
> despilfarramos direcciones, la cosa va ir muy justa .-)

Me parece muy fuerte ...

De todos modos te aseguro que lo que ha costado conseguir el /20 a Telia, no muchos Telcos estan dispuestos a sufrirlo ... salvo que sea realmente necesario.

> 
> Mi comentario en todo esto esto es: las asignaciones esta siendo
> desproporcionadas y dudo que sea posible mantener este ritmo
> Deberiamos cambiar el criterio del HD ratio y cerrar la canilla

En eso estoy de acuerdo. En su momento hice unas cuentas rapidas y me salieron como 5 bits perdidos, que son muchos ... Si te apuntas nos lanzamos a por un ID !

> 
> Saludos, marcelo
> 
>> Saludos,
>> Jordi
>> 
>> ---- Original Message ----
>> From: "marcelo bagnulo braun" <marcelo at it.uc3m.es>
>> To: "JORDI PALET MARTINEZ" <jordi.palet at consulintel.es>
>> Cc: <politicas at lacnic.net>
>> Sent: Thursday, August 12, 2004 1:07 PM
>> Subject: Re: [LACNIC/Politicas] Fwd: [ipv6-wg at ripe.net] Policy
>> forallocation of IPv6 address space from IANA to RIRs
>> 
>>> El 12/08/2004, a las 12:43, JORDI PALET MARTINEZ escribió:
>>> 
>>>> Hola,
>>>> 
>>>> Quizas es importante entender la problematica ...
>>>> 
>>>> Hasta ahora, IANA para asignar prefijos a los RIR, se esta basando en
>>>> una norma que solo permite bloques /23, y que ademas era temporal y
>>>> experimental (si no mal recuerdo el RFC2450).
>>>> 
>>>> Lo que esta ocurriendo es que algunos ISPs que necesitan prefijos mas
>>>> grandes que /32, estan teniendo problemas/demoras en obtenerlos por
>>>> este motivo. Ejemplo el /20 que se ha asignado a Telia (que se ha
>>>> tenido que hacer con varios /23 consecutivos !), el que esta pidiendo
>>>> el DoD, y otros operadores en Europa, etc.
>>>> 
>>> 
>>> Bueno capaz que el problema que deberiamos tratar primero es el tamaño
>>> de las asignaciones.
>>> Digo, si TELIA necesita un /20 que es lo que necesita un operador
>>> grande en Brasil o en Mexico, o en China?!!!
>>> No se cuan buena idea es abrir la canilla ahora, cuaando parece haber
>>> una duda razonable que las asignaciones son un poco desproporcionadas.
>>> Yo diria que primero se deberia arreglar el tamaño de las asignaciones
>>> y luego simplificar este otro tema.
>>> 
>>> Saludos, marcelo
>>> 
>>>> En RIPE generamos una discusion por este tema y parece que lanzamos
>>>> la
>>>> "pelota".
>>>> 
>>>> Quizas os resulte interesante esta presentacion que explica algunos
>>>> casos
>>>> http://www.potaroo.net/iepg/august2004/
>>>> deployment_plans_behind_larger_ipv6_allocations_v6.pdf.
>>>> 
>>>> Saludos,
>>>> Jordi
>>>> 
>>>> ---- Original Message ----
>>>> From: "Raúl Echeberría" <raul at lacnic.net>
>>>> To: <politicas at lacnic.net>
>>>> Sent: Thursday, August 12, 2004 12:32 PM
>>>> Subject: Re: [LACNIC/Politicas] Fwd: [ipv6-wg at ripe.net] Policy
>>>> forallocation of IPv6 address space from IANA to RIRs
>>>> 
>>>>> German Valdez, nuestro Gerente de Políticas, esta preparando el
>>>>> texto
>>>>> en
>>>>> español para enviarlo a la lista.
>>>>> 
>>>>> El objetivo de esta politica global es el de establecer reglas y
>>>>> criterios
>>>>> claros en base a los cuales la IANA le deberá asignar bloques de
>>>>> direcciones IPv6 a los Registros Regionales (RIRs). Ya existe una
>>>>> politica
>>>>> que fue aprobada en todos los RIRs, en relacion a IPv4.
>>>>> 
>>>>> La propuesta no es exactamente del NRO, sino que el NRO lo que ha
>>>>> hecho es
>>>>> habilitar la discusion de esta propuesta cuyo texto corresponde a
>>>>> APNIC.
>>>>> 
>>>>> Lo importante es identificar cuales son los aspectos importantes a
>>>>> discutir: tamaño de la asignacion inicial de IPv6 de la IANA a un
>>>>> RIR,
>>>>> como se califica para una asignacion adicional, de que tamaño debe
>>>>> ser la
>>>>> asignacion adicional, etc.
>>>>> 
>>>>> La propuesta actual intenta solo traer estos puntos a la mesa.
>>>>> Nuestra
>>>>> comunidad debe sentirse libre para discutir esto, en el sentido que
>>>>> no hay
>>>>> que limitarse a discutir SI o NO a esta propuesta, es solo una
>>>>> propuesta
>>>>> indicativa.
>>>>> 
>>>>> Saludos
>>>>> 
>>>>> Raul
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> At 05:51 12/08/2004, marcelo bagnulo braun wrote:
>>>>>> Hola a todos,
>>>>>> 
>>>>>> en la lista de RIPE se ha enviado esto,
>>>>>> 
>>>>>> saludos, marcelo
>>>>>> 
>>>>>> Inicio mensaje reenviado:
>>>>>> 
>>>>>>> De: leo vegoda <leo at ripe.net>
>>>>>>> Fecha: 9 de agosto de 2004 17:38:03 GMT+02:00
>>>>>>> Para: address-policy-wg at ripe.net
>>>>>>> Cc: ipv6-wg at ripe.net
>>>>>>> Asunto: [ipv6-wg at ripe.net] Policy for allocation of IPv6 address
>>>>>>> space
>>>>>>> from IANA to RIRs
>>>>>>> 
>>>>>>> Dear Colleagues,
>>>>>>> 
>>>>>>> The Number Resource Organisation (NRO) has published a proposal
>>>>>>> for
>>>>>>> a
>>>>>>> policy for the allocation of IPv6 address space from the IANA to
>>>>>>> the
>>>>>>> RIRs. It is intended that this proposed policy should be agreed by
>>>>>>> all
>>>>>>> RIRs' open policy fora and then approved by the ASO and ICANN as a
>>>>>>> global policy.
>>>>>>> 
>>>>>>> The proposal is available on our web site at:
>>>>>>> 
>>>>>>> http://www.ripe.net/ripe/draft-documents/ipv6.html
>>>>>>> 
>>>>>>> Comment on the proposal is sought.
>>>>>>> 
>>>>>>> Kind regards,
>>>>>>> 
>>>>>>> --
>>>>>>> leo vegoda
>>>>>>> Registration Services Manager
>>>>>>> RIPE NCC
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Politicas mailing list
>>>>>> Politicas at lacnic.net
>>>>>> http://www.lacnic.net/mailman/listinfo/politicas
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Politicas mailing list
>>>>> Politicas at lacnic.net
>>>>> http://www.lacnic.net/mailman/listinfo/politicas
>>>> 
>>>> 
>>>> **********************************
>>>> Madrid 2003 Global IPv6 Summit
>>>> Presentations and videos on line at:
>>>> http://www.ipv6-es.com
>>>> 
>>>> This electronic message contains information which may be privileged
>>>> or confidential. The information is intended to be for the use of the
>>>> individual(s) named above. If you are not the intended recipient be
>>>> aware that any disclosure, copying, distribution or use of the
>>>> contents of this information, including attached files, is
>>>> prohibited.
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Politicas mailing list
>>>> Politicas at lacnic.net
>>>> http://www.lacnic.net/mailman/listinfo/politicas
>> 
>> 
>> **********************************
>> Madrid 2003 Global IPv6 Summit
>> Presentations and videos on line at:
>> http://www.ipv6-es.com
>> 
>> This electronic message contains information which may be privileged
>> or confidential. The information is intended to be for the use of the
>> individual(s) named above. If you are not the intended recipient be
>> aware that any disclosure, copying, distribution or use of the
>> contents of this information, including attached files, is prohibited.
>> 
>> 
>> 
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> http://www.lacnic.net/mailman/listinfo/politicas

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.