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

From: Thomas Narten <[email-masked]>
Date: Fri, 10 Mar 2006 10:45:48 -0500

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

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 10 Mar 2006 16:46:35 -0500

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.

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.

I guess this boils down to "who sets the policy?"

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 
> 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> 	"FILE 
> /internet-drafts/draft-narten-ipv6-3177bis-48boundary-01.txt".
>