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

["Tony Hain" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> JORDI PALET MARTINEZ
> Sent: Saturday, July 16, 2005 1:39 PM
> To: [e-mail]; [e-mail]
> 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 <[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
> --------------------------------------------------------------------


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