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

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Apr 2006 13:51:29 +0200

Manfredi, Albert E wrote:
> The ID seems clear enough and achieves the goals of removing any
> specific mention of prefix length or conservation of address space. The
> next question is, who makes the policy on what size of prefix the
> customers are assigned? I assume each ISP.

Actually, no, in that reductionist view it's the customers, by choosing
the ISPs that offer what they want. One of the motivations for the original
/48 recommendation was to avoid a reflex reaction in which /64 would
be considered adequate for a domestic or small business customer - we want
home subnetting to be considered the norm. I don't think that motivation
has changed, even if a rigid boundary at /48 no longer looks optimal.

> 
> Not to say there's anything wrong with this, but it seems to me that as
> written, this ID would make it acceptable for ISPs to assign 64-bit
> prefixes.
> 
>    Thus, it
>    remains highly desirable to provide end sites with enough space (on
>    both initial and subsequent assignments) to last several years.
>    Fortunately, this goal can be achieved in a number of ways and does
>    not require that all end sites receive the same default size
>    assignment.
> 
> If that's desirable enough, maybe the IETF can make that IETF policy,
> and we're back to wondering whether some default min size should be made
> mandatory.

Mandatory is a strong word. But the notion that norm is a prefix *shorter*
than /64 seems necessary.
> 
> I guess this boils down to "who sets the policy?"

How about "nobody" ? Seriously,if we have a strong technical recommendation
that customer prefixes SHOULD be shorter than /64 to allow subnetting,
is any policy needed?

    Brian

> 
> Bert
> 
> 
> 
>>-----Original Message-----
>>From: Thomas Narten [mailto:[email-masked]] 
>>Sent: Friday, March 10, 2006 10:46 AM
>>To: [email-masked]
>>Subject: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-01.txt 
>>
>>FYI. This is a revised version of a document the WG discussed in
>>Paris. At the time the WG (at least those in the room) agreed to make
>>this a WG document. But that probably needs to be reevaluated, given
>>the changes.
>>
>>This version is fairly heavily changed. Pretty much all of the text
>>relating to "conservation of address space" arguments and ideas on
>>using other sized boundaries has been removed. I think that text has
>>been superceded by events, and is really the purview of the RIR
>>community.
>>
>>What I think this document should do is update/replace 3177 and to
>>document any architectural/standards issues related to the /48
>>boundary (or changing that boundary to something else).
>>
>>Comments welcome (and the document is very short!)
>>
>>Thomas
>>
>>------- Forwarded Message
>>
>>From: [email-masked]
>>To: [email-masked]
>>Cc: 
>>Date: Thu, 09 Mar 2006 15:50:03 -0500
>>Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-01.txt 
>>Reply-To: [email-masked]
>>
>>--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-01.txt
>>	Pages		: 7
>>	Date		: 2006-3-9
>>	
>>RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks
>>in most cases. The Regional Internet Registries (RIRs) adopted those
>>recommendations in 2002 and they have been in effect ever since.
>>This document revisits and updates the IAB/IESG recommendations on
>>the assignment of IPv6 address space to end sites.  The exact choice
>>of how much address space to assign end sites is a policy issue under
>>the purview of the RIRs, subject to IPv6 architectural
>>considerations. This document reviews those architectural
>>considerations and reiterates that changing the /48 recommendation is
>>one of policy, and has minimal impact on the IPv6 architecture and on
>>IETF Standards.
>>
>>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-01.txt
> 
>>To remove yourself from the I-D Announcement list, send a message to 
>>[email-masked] 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-01.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-masked].
>>In the body type:
>>	"FILE 
>>/internet-drafts/draft-narten-ipv6-3177bis-48boundary-01.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-masked]"
>>
>>Content-Type: text/plain
>>Content-ID: <[email-masked]>
>>
>>ENCODING mime
>>FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-01.txt
>>
>>--OtherAccess
>>Content-Type: Message/External-body;
>>	name="draft-narten-ipv6-3177bis-48boundary-01.txt";
>>	site="ftp.ietf.org"; access-type="anon-ftp";
>>	directory="internet-drafts"
>>
>>Content-Type: text/plain
>>Content-ID: <[email-masked]>
>>
>>
>>--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
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/i-d-announce
>>
>>--NextPart--
>>
>>------- End of Forwarded Message
>>
>>--------------------------------------------------------------------
>>IETF IPv6 working group mailing list
>>[email-masked]
>>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>>--------------------------------------------------------------------
>>
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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