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

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

PPP is a link technology for connecting the consumer device to the SP
router. Not to be advertising, but
http://www.cisco.com/en/US/products/hw/routers/ps272/index.html would take
any offered PDP context as an interesting link that might have a route to
someplace useful at the other end. The point is it doesn't matter if that
consumer device is an endpoint or a router; the carrier sees a logical link
to a customer. What the customer does behind the device on the other end of
that link is outside the carrier's realm of concern. Even if they think they
know, widespread use of NAT proves that they don't. So rather than look at
this as a role specific device connecting to a limited scope service, the
carriers need to pay attention to the fact that the consumer edge device is
in control of the actual application, and any barriers just create a market
for technologies to circumvent them. 

Yes, there are no technical problems with long prefixes. The problem with
long prefixes is the operational fall out at the other end. If business
models get built around very long prefixes, people will demand a
one-time-cost device to use the low continuing cost long prefix as a means
to mitigate the costs of doing it right to start with. IETF documents should
not recommend anything longer than a /60 at the demarc between a service
provider and customer. 

It is not the IETF's job to define business models, but outlining the
consequences of specific approaches is a responsibility. 

Tony 


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> JORDI PALET MARTINEZ
> Sent: Monday, July 18, 2005 11:03 AM
> To: [e-mail]; [e-mail]
> Subject: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> 
> I was thinking in a PPP link or PDP context, I'm not really sure if they
> allow (at least today, but protocol definition), to use a prefix instead
> of
> an address. Also for tunnel end points, where I think the recommendation
> is
> /126, but some people still use /128, etc.
> 
> Regards,
> Jordi
> 
> 
> 
> 
> > De: Tony Hain <[e-mail]>
> > Responder a: <[e-mail]>
> > Fecha: Mon, 18 Jul 2005 10:50:52 -0700
> > Para: <[e-mail]>, <[e-mail]>,
> > <[e-mail]>
> > Asunto: RE: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> >
> > 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
> > --------------------------------------------------------------------
> 
> 
> 
> 
> ************************************
> 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
--------------------------------------------------------------------