[LACNIC/Politicas] Fwd: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
marcelo bagnulo braun
marcelo at it.uc3m.es
Sun Jul 17 07:52:02 BRT 2005
Hola Roque,
si, a mi me parece un disparate tambien
tener en cuenta que la eficiencia requerida resultante del uso del HD
ratio para un /19 es de 1,8%!!!!
ademas, en draft-narten-iana-rir-ipv6-considerations-00.txt se lantea
un ejemplo que me parece ilustrar muy bien tu preocupacion, lo
transcribo para uds.
4.1. An example: Cable Modem/DSL Service in US
In the hallway at a recent ARIN meeting, I was cornered by someone
who had done a back-of-the envelope calculation that led him to
believe the current policies needed adjustment. The argument went
like:
If I assign 4M /48Ç«÷s of IPv6 (one to each cable modem on my
network), according to the HD-ratio I am justified to obtain
something around a /20 of IPv6 addresses. In other words, I am
justified in getting 268M /48Ç«÷s even though I am only using 4M
of
them. That would be enough for me to assign at least two for
every household in the US (not just the 19M on my network).
Now if all the cable providers (e.g., Comcast, Cox, Adelphia,
Cablevision, Time-Warner, etc.) did the same for their networks;
and each of the DSL companies made a similar move (SBC, Verizon,
Quest, etc.); perhaps we could easily see the broadband market in
the US alone obtaining some 16 /20Ç«÷s of IPv6 or a total of /16.
There are only 8192 of those available in the current global
unicast space of 2001::/3.
Anyhow, you can see where this might lead...
Saludos, marcelo
PD: este tema se esta discutiendo en la lista global-v6
global-v6 mailing list
global-v6 at lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/global-v6
seria bueno que enviaramos nuestros comentarios ahi, de forma que las
opiniones del lacnic tambien se tomen en cuenta
El 17/07/2005, a las 6:56, rgaglian at adinet.com.uy escribió:
> Marcelo,
>
> Hace tiempo que queria contestarte este correo con un comentario que
> he escuchado
> más de una vez.
>
> ¿¿¿Cómo hizo D-Telecom para justificar un /19???
>
> No he estudiado mucho las políticas actuales de RIPE pero claramente
> se desprende
> del resto de los RIR por estos bloques gigantes de direcciones
> asignados
> a algunos proveedores.
>
> Un /19 se podría dividir en 539 millones de /48. Es mi impresión que
> el plan
> de numeración que utilizaron (y amparados en el RFC vigente) da un /48
> a
> cada usuario DSL y A CADA CELULAR.
>
> Lo que es interesante es que el draft, a primera vista, no estudia la
> asignación
> de direcciones para empresas celulares/moviles.
>
> Un abrazo
>
> Roque
>
>> -- Mensaje original --
>> To: lactf at lac.ipv6tf.org, politicas at lacnic.net
>> From: marcelo bagnulo braun <marcelo at it.uc3m.es>
>> Date: Wed, 13 Jul 2005 11:39:33 +0200
>> Subject: [LACNIC/Politicas] Fwd: I-D
>> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>>
>>
>> fyi
>>
>> Inicio mensaje reenviado:
>>
>>> De: Internet-Drafts at ietf.org
>>> Fecha: 12 de julio de 2005 21:50:03 GMT+02:00
>>> Para: i-d-announce at ietf.org
>>> Asunto: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>>> Responder a: internet-drafts at ietf.org
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>> Title : IPv6 Address Allocation to End Sites
>>> Author(s) : T. Narten, et al.
>>> Filename : draft-narten-ipv6-3177bis-48boundary-00.txt
>>> Pages : 8
>>> Date : 2005-7-12
>>>
>>> This document revisits the IAB/IESG recommendations on the
>>> assignment
>>> of IPv6 address space to end sites. Specifically, it indicates
>>> that
>>> changing the default end-site assignment for typical home and SOHO
>>> sites from /48 to /56 is consistent with the goals of IPv6 and RFC
>>> 3177. Although it is for the RIR community to make adjustments to
>
>>> the
>>> IPv6 address space allocation and end site assignment policies,
>>> the
>>> IETF community would be comfortable with RIRs changing the default
>>> assignment size to /56 for smaller end sites. This document
>>> obsoletes
>>> RFC 3177 and reclassifies it as historic.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis
>>> -48boundary-00.txt
>>>
>>> To remove yourself from the I-D Announcement list, send a message to
>>> i-d-announce-request at ietf.org with the word unsubscribe in the body
>>> of
>>
>>> the message.
>>> You can also visit
>>> https://www1.ietf.org/mailman/listinfo/I-D-announce
>>> to change your subscription settings.
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP. Login with the
>>> username
>>> "anonymous" and a password of your e-mail address. After logging in,
>>> type "cd internet-drafts" and then
>>> "get draft-narten-ipv6-3177bis-48boundary-00.txt".
>>>
>>> A list of Internet-Drafts directories can be found in
>>> http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>> mailserv at ietf.org.
>>> In the body type:
>>> "FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt".
>>>
>>> NOTE: The mail server at ietf.org can return the document in
>>> MIME-encoded form by using the "mpack" utility. To use this
>>> feature, insert the command "ENCODING mime" before the "FILE"
>>> command. To decode the response(s), you will need "munpack" or
>>> a MIME-compliant mail reader. Different MIME-compliant mail readers
>>> exhibit different behavior, especially when dealing with
>>> "multipart" MIME messages (i.e. documents which have been split
>>> up into multiple messages), so check your local documentation on
>>> how to manipulate these messages.
>>>
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>> Content-Type: text/plain
>>> Content-ID: <2005-7-12130012.I-D at ietf.org>
>>>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce at ietf.org
>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>>
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> http://www.lacnic.net/mailman/listinfo/politicas
>
> Ing.Roque Gagliano
> rgaglian at adinet.com.uy
>
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> http://www.lacnic.net/mailman/listinfo/politicas
>
More information about the Politicas
mailing list