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 PROTECTED] > Sent: Friday, March 10, 2006 10:46 AM > To: [email protected] > 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 PROTECTED] > To: [email protected] > Cc: > Date: Thu, 09 Mar 2006 15:50:03 -0500 > Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-01.txt > Reply-To: [EMAIL PROTECTED] > > --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 PROTECTED] 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 PROTECTED] > 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 PROTECTED]" > > Content-Type: text/plain > Content-ID: <[EMAIL PROTECTED]> > > 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 PROTECTED]> > > > --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 protected] > https://www1.ietf.org/mailman/listinfo/i-d-announce > > --NextPart-- > > ------- End of Forwarded Message > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
