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

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

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
--------------------------------------------------------------------