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

Arturo Servin aservin at lacnic.net
Mon Mar 28 19:51:12 BRT 2011 

	Creo que entonces hay que trabajar en el 6177bis y decir que nos volvimos a equivocar.

	Si 6lowpan asume un /64 por dispositivo, entonces es posible que dependiendo para que se use, incluso un /48 (~65K) va a ser escaso.

Slds,
.as

On 28 Mar 2011, at 23:59, Antonio M. Moreiras wrote:

> Em certos deployments de 6lowpan, não se faz uso de um /64 por
> dispositivo? (Com route-over? Isso é realmente uma pergunta, não uma
> afirmação. Estou desatualizado no tema!)
> 
> Se isso for verdade, não seria difícil de imaginar algumas centenas ou
> mesmo milhares de /64 gastos com automação residencial.
> 
> O espírito da coisa é que deveria ser fácil para o usuário receber a
> quantidade de endereços, ou subredes, de que necessitar!
> 
> []s
> Moreiras.
> 
> Em 28/03/11 23:39, Arturo Servin escreveu:
>> 	Yo estoy de acuerdo con el RFC6177:
>> 
>> "While it seems likely that
>>   the size of a typical home network will grow over the next few
>>   decades, it is hard to argue that home sites will make use of 65K
>>   subnets within the foreseeable future ...
>> 
>>   … Hence, this document still recommends
>>   giving home sites significantly more than a single /64, but does not
>>   recommend that every home site be given a /48 either.
>> "
>> 
>> 	Sección 2.
>> 
>> -as
>> 
>> On 28 Mar 2011, at 22:52, JORDI PALET MARTINEZ wrote:
>> 
>>> Yo diria que ni uno ni otro.
>>> 
>>> Ambos son ejemplos y recomendaciones, igual que lo era el RFC3177.
>>> 
>>> Como comente el otro dia, un buen plan de direccionamiento es lo mas
>>> complejo y requiere muy buen conocimiento de la red. Ademas, tambien de
>>> los equipos, de los usuarios, de detalles del software.
>>> 
>>> Si tengo usuarios que ahora mismo obtienen con 6to4 /48, y soy un ISP que
>>> despliega IPv6 nativo, le voy a dar a los usuarios ahora un /56 ? Si yo
>>> soy usuario de ese ISP, me ire a la compentencia, y seguro que habra una
>>> compentencia mas "compentente". No hay ninguna excusa para dar menos de un
>>> /48, de hecho en alguna region se esta volviendo a discutir el cambiar de
>>> nuevo el /56 a /48 ... Ademas, hay hardware que no es muy amigable con el
>>> /56.
>>> 
>>> Pero bueno, alla cada uno con su modelo de negocio y cuando lleguen ISPs
>>> con mejores planes de direccionamiento y pierdan clientes por pensar que
>>> hay que restringir direcciones como en IPv4, aprenderan la leccion.
>>> 
>>> Saludos,
>>> Jordi
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -----Mensaje original-----
>>> De: "Harold de Dios T." <harold at telecom.noc.udg.mx>
>>> Responder a: <lactf at lac.ipv6tf.org>
>>> Fecha: Mon, 28 Mar 2011 14:41:45 -0600
>>> Para: <lactf at lac.ipv6tf.org>
>>> Asunto: Re: [LAC-TF] Fwd: BCP 157, RFC 6177 on IPv6 Address Assignment to
>>> End Sites
>>> 
>>>> Rompe o complementa lo descrito en el manual de Sander Steffann?
>>>> 
>>>> Saludos,
>>>> Harold.
>>>> El 3/27/11 1:12 PM, "Arturo Servin" <aservin at lacnic.net> escribió:
>>>> 
>>>> 
>>>> 
>>>> Creo que esto puede ser de utilidad para tomar en cuenta al momento de
>>>> hacer sus planes de direccionamiento de IPv6.
>>>> 
>>>> Como dato, este RFC y BCP sustituyen al RFC 3177.
>>>> 
>>>> Saludos,
>>>> -as 
>>>> 
>>>> Begin forwarded message:
>>>> 
>>>> From: rfc-editor at rfc-editor.org
>>>> Date: 27 March 2011 11:47:08 CEST
>>>> To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org
>>>> Cc: v6ops at ietf.org, rfc-editor at rfc-editor.org
>>>> Subject: BCP 157, RFC 6177 on IPv6 Address Assignment to End Sites
>>>> 
>>>> 
>>>> A new Request for Comments is now available in online RFC libraries.
>>>> 
>>>>      BCP 157   
>>>>      RFC 6177
>>>> 
>>>>      Title:      IPv6 Address Assignment to End
>>>>                  Sites
>>>>      Author:     T. Narten, G. Huston,
>>>>                  L. Roberts
>>>>      Status:     Best Current Practice
>>>>      Stream:     IETF
>>>>      Date:       March 2011
>>>>      Mailbox:    narten at us.ibm.com,
>>>>                  gih at apnic.net,
>>>>                  lea.roberts at stanford.edu
>>>>      Pages:      9
>>>>      Characters: 21231
>>>>      Obsoletes:  RFC3177
>>>>      See Also:   BCP0157
>>>> 
>>>>      I-D Tag:    draft-ietf-v6ops-3177bis-end-sites-01.txt
>>>> 
>>>>      URL:        http://www.rfc-editor.org/rfc/rfc6177.txt
>>>> 
>>>> RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks
>>>> in most cases.  The Regional Internet Registries (RIRs) adopted that
>>>> recommendation in 2002, but began reconsidering the policy in 2005.
>>>> This document obsoletes the RFC 3177 recommendations on the
>>>> assignment of IPv6 address space to end sites.  The exact choice of
>>>> how much address space to assign end sites is an issue for the
>>>> operational community.  The IETF's role in this case is limited to
>>>> providing guidance on IPv6 architectural and operational
>>>> considerations.  This document reviews the architectural and
>>>> operational considerations of end site assignments as well as the
>>>> motivations behind the original recommendations in RFC 3177.  Moreover,
>>>> this document clarifies that a one-size-fits-all recommendation of /48 is
>>>> not nuanced enough for the broad range of end sites and is no longer
>>>> recommended as a single default.
>>>> 
>>>> This document obsoletes RFC 3177.  [STANDARDS-TRACK]
>>>> 
>>>> This document is a product of the IPv6 Operations Working Group of the
>>>> IETF.
>>>> 
>>>> 
>>>> BCP: This document specifies an Internet Best Current Practices for the
>>>> Internet Community, and requests discussion and suggestions for
>>>> improvements. Distribution of this memo is unlimited.
>>>> 
>>>> This announcement is sent to the IETF-Announce and rfc-dist lists.
>>>> To subscribe or unsubscribe, see
>>>> http://www.ietf.org/mailman/listinfo/ietf-announce
>>>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
>>>> 
>>>> For searching the RFC series, see
>>>> http://www.rfc-editor.org/rfcsearch.html.
>>>> For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
>>>> 
>>>> Requests for special distribution should be addressed to either the
>>>> author of the RFC in question, or to rfc-editor at rfc-editor.org.  Unless
>>>> specifically noted otherwise on the RFC itself, all RFCs are for
>>>> unlimited distribution.
>>>> 
>>>> 
>>>> The RFC Editor Team
>>>> Association Management Solutions, LLC
>>>> 
>>>> 
>>>> _______________________________________________
>>>> IETF-Announce mailing list
>>>> IETF-Announce at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ________________________________________
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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

More information about the LACTF mailing list