The operator never should know if the device has a backside interface, so the argument about /128 being valid is also wrong (/128's are the fastest track to an IPv6 NAT that there is). From the perspective of the operator they are selling access via a link, what the consumer does behind the device connected to the link (other than resell it) is not their business. They should be set up to allocate a prefix shorter than /64 in all cases.
Tony > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > JORDI PALET MARTINEZ > Sent: Saturday, July 16, 2005 1:39 PM > To: [EMAIL PROTECTED]; ipv6@ietf.org > Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > > 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 <[EMAIL PROTECTED]> > > Responder a: <[EMAIL PROTECTED]> > > Fecha: Fri, 15 Jul 2005 17:40:24 -0700 > > Para: 'Thomas Narten' <[EMAIL PROTECTED]>, <ipv6@ietf.org> > > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > >> Thomas Narten > >> Sent: Wednesday, July 13, 2005 2:44 PM > >> To: ipv6@ietf.org > >> 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: [EMAIL PROTECTED] > >> To: i-d-announce@ietf.org > >> Date: Tue, 12 Jul 2005 15:50:03 -0400 > >> Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt > >> Reply-To: [EMAIL PROTECTED] > >> > >> --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 > >> [EMAIL PROTECTED] 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: > >> [EMAIL PROTECTED] > >> 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="[EMAIL PROTECTED]" > >> > >> Content-Type: text/plain > >> Content-ID: <[EMAIL PROTECTED]> > >> > >> 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: <[EMAIL PROTECTED]> > >> > >> > >> --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 > >> I-D-Announce@ietf.org > >> https://www1.ietf.org/mailman/listinfo/i-d-announce > >> > >> --NextPart-- > >> > >> ------- End of Forwarded Message > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > 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 > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------