Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt

[JORDI PALET MARTINEZ <[e-mail]>]

I tend to agree with this.

I see situations for assigning a /128 when a unique device is connected,
which is not going to route anything else, but once it has other interfaces
(which is the most common case and will become more and more often) ...

Regards,
Jordi




> De: Tony Hain <[e-mail]>
> Responder a: <[e-mail]>
> Fecha: Fri, 15 Jul 2005 17:40:24 -0700
> Para: 'Thomas Narten' <[e-mail]>, <[e-mail]>
> Asunto: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> 
> I said part of this on the ARIN PPML list but thought it should be repeated
> here. 
> 
> A /64 allocation never makes any sense. The claims about a PDA only needing
> one assume that it will never be dropped into a cradle of a vehicle suddenly
> enabling various subnets (freight environmental or inventory monitor,
> dispatch service) to reach out or be reached with independent access
> controls. A /64 puts the carrier in the position of telling the customer
> they can't build anything more than a single lan, where a /60 removes that
> limitation with effectively the same impact on space utilization.
> 
> We bumped into another version of this when thinking through some of the
> issues with cable. The MSO's appear to be focusing around a prefix being the
> unit of allocation to a customer. All well and good until we get the 'a /64
> is more than enough space' discussion. The issue crystallized when the
> discussion included a separate subnet for cable devices in the home to
> communicate locally. Since the MSO has bought into the concept of a prefix
> maps to a customer, having independent /64's breaks the allocation and
> management model. The conservation mindset clashes with the simplified
> management mindset and documents with wording like this are not helping.
> 
> This draft really needs to remove the discussion about a /64 being
> appropriate for anything from an allocation perspective. There is no serious
> technical need for the draft to begin with, but if it exists it should point
> out that a /60 is the longest prefix that allows customers to build networks
> with multiple links (specifically technologies that don't bridge) and maps
> cleanly onto the reverse delegation name tree.
> 
> Tony 
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Thomas Narten
>> Sent: Wednesday, July 13, 2005 2:44 PM
>> To: [e-mail]
>> Subject: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>> 
>> Here's an ID for consideration by the IPv6 WG.
>> 
>> Background:
>> 
>> Discussion on the more general topic took place at the April ARIN and
>> May RIPE meetings.  A good summary of those presentations can be found
>> at:
>> 
>> http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-
>> wed-ipv6-roundtable-report.pdf
>> 
>> A more general discussion of the overall topic of IPv6 address
>> allocation considerations (the /48 boundary topic is just one piece of
>> a larger puzzle) can be found at:
>> 
>> http://www.ietf.org/internet-drafts/draft-narten-iana-rir-ipv6-
>> considerations-00.txt
>> 
>> Thomas
>> 
>> ------- Forwarded Message
>> 
>> From: [e-mail]
>> To: [e-mail]
>> Date: Tue, 12 Jul 2005 15:50:03 -0400
>> Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>> Reply-To: [e-mail]
>> 
>> --NextPart
>> 
>> 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
>> [e-mail] 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:
>> [e-mail].
>> 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.
>> 
>> --NextPart
>> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>> 
>> --OtherAccess
>> Content-Type: Message/External-body; access-type="mail-server";
>> server="[e-mail]"
>> 
>> Content-Type: text/plain
>> Content-ID: <[e-mail]>
>> 
>> ENCODING mime
>> FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt
>> 
>> --OtherAccess
>> Content-Type: Message/External-body;
>> name="draft-narten-ipv6-3177bis-48boundary-00.txt";
>> site="ftp.ietf.org"; access-type="anon-ftp";
>> directory="internet-drafts"
>> 
>> Content-Type: text/plain
>> Content-ID: <[e-mail]>
>> 
>> 
>> --OtherAccess--
>> 
>> --NextPart
>> Content-Type: text/plain; charset="us-ascii"
>> MIME-Version: 1.0
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: inline
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>> 
>> --NextPart--
>> 
>> ------- End of Forwarded Message
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------




************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Information available 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.




--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------