[LAC-TF] Fwd: BCP 157, RFC 6177 on IPv6 Address Assignment to End Sites

[Arturo Servin]

	Si soy usuario residencial me importa más la velocidad de bajada, el costo y lo que tenga de cap en GB que el número de redes en v6. O sea, 65k redes vs 256 me resulta totalmente irrelevante al día de hoy. 

	Si soy usuario corporativo posiblemente ya tengo un /48 delegado del PA de mi proveedor o tengo PI. Así que no veo el problema.

	Regresando a los números. Jugar con ellos es peligroso, te pueden dar diversos resultados (contestando el correo de Jordi y Antonio) dependiendo de tu punto de vista y como trates el problema:

	Si asignamos por default /48, entonces nos quedamos con un protocol de 48 bits, solo 16 más que IPv4.

	Y en asignaciones.

	Un ISP asignando /48 a residenciales facilmente podría requerir /18 o menor (suponiendo /24 para 16 millones de clientes residenciales y otro tanto para corporativos, los cuales seguro les querran dar /40s o /32 -ya que estamos siendo proactivos- y otro tanto para telefonía móvil). Así que tenemos 2^18 posibles ISPs , sin embargo el espacio unicast por el momento es /3, así que tenemos 2^15 posibles ISPs (~32k). 

	Del /12 de LACNIC se podría asignar 2^6 de estos ISPs (64) y regresar a IANA y justificar que ya se acabó el espacio. Si LACNIC tiene suerte entonces podria tener mas /12s (recordemos que solo hay 512) y después pedir al IETF que libere los otros /3s cuando otros RIRs hagan lo mismo. Todo esto en cuanto tiempo, 5 años, 200 como dicen?

	Posiblemente estoy haciendo alguna operación equivocada, si es así culpo a la falta de cafeína y sueño. Pero si no, cómo que ya no se ve tan grande, no?

Slds,
-as

On 30 Mar 2011, at 10:28, JORDI PALET MARTINEZ wrote:

> Si, comprendido, pero sigo pensando que aunque el resto de modificaciones
> del documento respecto del RFC3177 me parecen correctas (no tiene sentido
> hoy en dia entregar un /128, por ejemplo), no comparto que sea una buena
> recomendación "no recomendar" un /48. Insisto en lo que decia ayer. Un ISP
> les dira a sus clientes que actualemten utilizan 6to4 o Tunnel Brokers,
> que tienen que renumerar y tener menos direcciones ?
> 
> Saludos,
> Jordi
> 
> 
> 
> 
> 
> 
> -----Mensaje original-----
> De: Arturo Servin <arturo.servin at gmail.com>
> Responder a: <lactf at lac.ipv6tf.org>
> Fecha: Wed, 30 Mar 2011 09:59:28 +0200
> Para: <lactf at lac.ipv6tf.org>
> Asunto: Re: [LAC-TF] Fwd: BCP 157, RFC 6177 on IPv6 Address Assignment to
> End Sites
> 
>> 
>>   El documento no dice que no puedas usar un /48 para clientes
>> residencias. Simplemente el consenso técnico es que que no se puede
>> recomendar en este momento. Lo cual es un decisión bastante sensible en
>> mi opinión y mejor que tratar de predecir el futuro.
>> 
>> 
>> -as
>> 
>> On 30 Mar 2011, at 09:37, JORDI PALET MARTINEZ wrote:
>> 
>>> Todos los documentos representan la opinion del IETF, y en teoria el
>>> consenso, pero un BCP no tiene mayor rango que un STD ni un
>>> Informational.
>>> 
>>> De hecho, yo discuti que no habia consenso en este documento, y lo sigo
>>> manteniendo y no soy el unico. Ultimamente en IETF falla el tema del
>>> consenso. Las objecciones no se toman suficientemente en cuenta y si te
>>> fijas, precisamente por eso este documento ha llevado creo que mas de
>>> 4-5
>>> años en sacarse adelante.
>>> 
>>> Saludos,
>>> Jordi
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -----Mensaje original-----
>>> De: Fernando Gont <fernando at gont.com.ar>
>>> Responder a: <lactf at lac.ipv6tf.org>
>>> Fecha: Tue, 29 Mar 2011 11:26:44 -0300
>>> Para: <lactf at lac.ipv6tf.org>
>>> Asunto: Re: [LAC-TF] Fwd: BCP 157, RFC 6177 on IPv6 Address Assignment
>>> to
>>> End Sites
>>> 
>>>> No solo eso. Es un BCP. Es decir, representa laopinion de la IETF en
>>>> tal
>>>> materia.
>>>> 
>>>> Un abrazo,
>>>> Fernando
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 29/03/2011 11:06 a.m., Arturo Servin wrote:
>>>>> 
>>>>>   RFC.
>>>>> 
>>>>>   6177
>>>>> 
>>>>> -as
>>>>> 
>>>>> On 29 Mar 2011, at 16:02, Jorge Villa wrote:
>>>>> 
>>>>>> y que haya este draft pues es una primera piedra en funcion de
>>>>>> revisar
>>>>>> estos temas.
>>>>> 
>>>>> _______________________________________________
>>>>> LACTF mailing list
>>>>> LACTF at lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>>>> 
>>>> 
>>>> -- 
>>>> Fernando Gont
>>>> e-mail: fernando at gont.com.ar || fgont at acm.org
>>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> LACTF mailing list
>>>> LACTF at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/lactf
>>> 
>>> 
>>> 
>>> **********************************************
>>> IPv4 is over
>>> Are you ready for the new Internet ?
>>> http://www.consulintel.es
>>> The IPv6 Company
>>> 
>>> 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.
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> LACTF mailing list
>>> LACTF at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lactf
>> 
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lactf
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
> 
> 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.
> 
> 
> 
> _______________________________________________
> LACTF mailing list
> LACTF at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lactf