IPv6 Address Assignment to End Sites
RFC 6177
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-12-20
|
01 | (System) | Received changes through RFC Editor sync (changed abstract to 'RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most … Received changes through RFC Editor sync (changed abstract to 'RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default. This document obsoletes RFC 3177. [STANDARDS-TRACK]') |
|
2017-05-16
|
01 | (System) | Changed document authors from "Geoff Huston, Thomas Narten" to "Geoff Huston, Thomas Narten, Rosalea Roberts" |
|
2015-10-14
|
01 | (System) | Notify list changed from v6ops-chairs@ietf.org, draft-ietf-v6ops-3177bis-end-sites@ietf.org to (None) |
|
2012-08-22
|
01 | (System) | post-migration administrative database adjustment to the No Objection position for Robert Sparks |
|
2012-08-22
|
01 | (System) | post-migration administrative database adjustment to the No Objection position for Alexey Melnikov |
|
2012-08-22
|
01 | (System) | post-migration administrative database adjustment to the No Objection position for David Harrington |
|
2011-03-28
|
01 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
|
2011-03-28
|
01 | Cindy Morgan | [Note]: changed to 'BCP 157, RFC 6177<br>' |
|
2011-03-27
|
01 | (System) | RFC published |
|
2011-01-13
|
01 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2011-01-12
|
01 | (System) | IANA Action state changed to No IC from In Progress |
|
2011-01-12
|
01 | (System) | IANA Action state changed to In Progress |
|
2011-01-12
|
01 | Cindy Morgan | IESG state changed to Approved-announcement sent |
|
2011-01-12
|
01 | Cindy Morgan | IESG has approved the document |
|
2011-01-12
|
01 | Cindy Morgan | Closed "Approve" ballot |
|
2011-01-12
|
01 | Cindy Morgan | Approval announcement text regenerated |
|
2011-01-03
|
01 | Ron Bonica | Ballot writeup text changed |
|
2011-01-03
|
01 | (System) | New version available: draft-ietf-v6ops-3177bis-end-sites-01.txt |
|
2010-12-27
|
01 | Ron Bonica | Approval announcement text changed |
|
2010-12-27
|
01 | Ron Bonica | Approval announcement text regenerated |
|
2010-12-27
|
01 | Ron Bonica | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
|
2010-12-23
|
01 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss |
|
2010-12-17
|
01 | (System) | Removed from agenda for telechat - 2010-12-16 |
|
2010-12-16
|
01 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Stephen Kent. |
|
2010-12-16
|
01 | Amy Vezza | State changed to IESG Evaluation::AD Followup from IESG Evaluation. |
|
2010-12-16
|
01 | Ron Bonica | Ballot writeup text changed |
|
2010-12-16
|
01 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss |
|
2010-12-16
|
01 | Alexey Melnikov | [Ballot comment] Ron promised to give IAB 1 week to review the document. |
|
2010-12-16
|
01 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
|
2010-12-16
|
01 | Ron Bonica | Ballot writeup text changed |
|
2010-12-16
|
01 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
|
2010-12-16
|
01 | Lars Eggert | [Ballot Position Update] New position, Yes, has been recorded |
|
2010-12-16
|
01 | Jari Arkko | [Ballot comment] This document is spot-on, much needed, and its about time we publish it. I can warmly recommend it being approved as it is. … [Ballot comment] This document is spot-on, much needed, and its about time we publish it. I can warmly recommend it being approved as it is. I do have a few comments on other AD's comments, however. Regarding David's Discuss on IPv6-IPv6 address translation, I think the current text in the document is actually completely appropriate and should not be changed. It is indeed the case that we must avoid a situation where address translation becomes necessary from a mere tight address allocation policy reason. Regarding Robert's Discuss on IETF role, I think the text would probably read better and be more acceptable to you if it said ... the IETF's role ... *in this case*. That is what I think the authors meant. The IETF should not, IMO, dictate the exact allocation size but rather provide guidelines, for the reasons stated in the document. Regarding the possible need to ask for IAB's approval, I think this document is clearly within IETF's scope, the working group and the community is behind this proposal and I see no formal reason to ask previous authors (including the IAB) for a permission. From a basic politeness stance, maybe we should check with the IAB though. I propose that this be done as a "for information" query rather than as a formal review period, and the AD who holds the discuss can clear when we are satisfied that the IAB has had enough time to respond if they feel the need to. |
|
2010-12-16
|
01 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko |
|
2010-12-16
|
01 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
|
2010-12-15
|
01 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded |
|
2010-12-15
|
01 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
|
2010-12-15
|
01 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
|
2010-12-15
|
01 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
|
2010-12-14
|
01 | David Harrington | [Ballot comment] "The exact choice of how much address space to assign end sites is an issue for the operational community. The role … [Ballot comment] "The exact choice of how much address space to assign end sites is an issue for the operational community. The role of the IETF is limited to providing guidance on IPv6 architectural and operational considerations. This document provides input into those discussions." I suggest this might be better worded as "This document provides input to the discussions of how much address space to assign end sites, as guidance to the operations community." |
|
2010-12-14
|
01 | David Harrington | [Ballot discuss] In section 1, the text asserts that IPv6/IPv6 NATS must be avoided. I think should be avoided is more accurate, since we cannot … [Ballot discuss] In section 1, the text asserts that IPv6/IPv6 NATS must be avoided. I think should be avoided is more accurate, since we cannot predict the future needs of an applicant. We can certainly try to avoid assigning non-contiguous ranges, but we cannot guarantee it. Therefore "must" seems inapprorpiate. |
|
2010-12-14
|
01 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to Discuss from No Objection |
|
2010-12-14
|
01 | David Harrington | [Ballot comment] I support the DISCUSS from Robert. |
|
2010-12-14
|
01 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded |
|
2010-12-14
|
01 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
|
2010-12-14
|
01 | Robert Sparks | [Ballot comment] This appears to obsolete 3177, not update it. |
|
2010-12-14
|
01 | Robert Sparks | [Ballot discuss] This text (which occurs twice in the document) is problematic: "The role of the IETF is limited to providing guidance on IPv6 architectural … [Ballot discuss] This text (which occurs twice in the document) is problematic: "The role of the IETF is limited to providing guidance on IPv6 architectural and operational considerations." The IETF's role, in general, is clearly much larger. It is not necessary for this document to attempt to define or limit what the IETF's role is or isn't. I suggest deleting the sentences. |
|
2010-12-14
|
01 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded |
|
2010-12-13
|
01 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
|
2010-12-13
|
01 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
|
2010-12-12
|
01 | Alexey Melnikov | [Ballot discuss] DISCUSS DISCUSS: The original document came from IAB+IESG. Does this document need to also be approved by IAB? |
|
2010-12-11
|
01 | Alexey Melnikov | [Ballot discuss] This document updates and replaces RFC 3177. - does this mean "Updates: RFC 3177" or does this mean "Obsoletes: RFC 3177 … [Ballot discuss] This document updates and replaces RFC 3177. - does this mean "Updates: RFC 3177" or does this mean "Obsoletes: RFC 3177"? Either way the document is missing such field in the document header. DISCUSS DISCUSS: The original document came from IAB+IESG. Does this document need to also be approved by IAB? |
|
2010-12-11
|
01 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded |
|
2010-12-07
|
01 | Ron Bonica | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
|
2010-12-07
|
01 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2010-12-01
|
01 | Ron Bonica | Placed on agenda for telechat - 2010-12-16 by Ron Bonica |
|
2010-12-01
|
01 | Ron Bonica | [Note]: 'Fred Baker (fred@cisco.com) is the document shepherd.' added by Ron Bonica |
|
2010-12-01
|
01 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica |
|
2010-12-01
|
01 | Ron Bonica | Ballot has been issued by Ron Bonica |
|
2010-12-01
|
01 | Ron Bonica | Created "Approve" ballot |
|
2010-11-30
|
01 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Kent |
|
2010-11-30
|
01 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Kent |
|
2010-11-29
|
01 | Amanda Baber | We understand that this document does not require any IANA actions. |
|
2010-11-23
|
01 | Cindy Morgan | Last call sent |
|
2010-11-23
|
01 | Cindy Morgan | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <v6ops@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-v6ops-3177bis-end-sites-00.txt> (IPv6 Address Assignment to End Sites) to BCP The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'IPv6 Address Assignment to End Sites' <draft-ietf-v6ops-3177bis-end-sites-00.txt> as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-12-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/ |
|
2010-11-23
|
01 | Ron Bonica | Last Call was requested by Ron Bonica |
|
2010-11-23
|
01 | Ron Bonica | State Changes to Last Call Requested from Publication Requested by Ron Bonica |
|
2010-11-23
|
01 | (System) | Ballot writeup text was added |
|
2010-11-23
|
01 | (System) | Last call text was added |
|
2010-11-23
|
01 | (System) | Ballot approval text was added |
|
2010-11-07
|
01 | Cindy Morgan | [Note]: 'Fred Baker (fred@cisco.com) is the document shepherd.' added by Cindy Morgan |
|
2010-11-07
|
01 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Fred Baker. Yes, I believe that it is ready for IESG consideration. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document was first introduced in ipv6/6man in 2005 and discussed there. As the issues were primarily operational, the 6man chairs sent it to v6ops, where it was first discussed in 2008. There was some discussion of specific points it made, but the primary change in the document in v6ops was to replace the statement that it "updates" RFC 3177 with a statement that it "replaces" it, and a summary of the specific changes in recommended policy. The sense of the working group discussion is well stated in a summary of the WGLC: there was wide support for adoption as a working group document, and the WGLC resulted in a large number of single word responses - "support" or "+1". In the words of Brian Carpenter: This is very important, as it aligns the IETF's technical guidance with the reality of address management faced by the RIRs. RFC 3177 was a rather theoretical document (which I wrote a fair chunk of), and it's time to officially retire it. I believe the draft is ready, and overdue. Brian Carpenter (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? I do have one concern. RFC 3177 was originally drafted under the auspices of the IESG, and was largely crafted by Tom Narten, then an Area Director, and Brian Carpenter, then chair of the IAB, and was published as a joint statement by the IESG and IAB. As such, I believe that the IESG and IAB need to agree to it. I sent a note to the IAB requesting comment on 17 October 2010, but have not heard back. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. no (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I consider this consensus to be Very Smooth. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) no (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/ ). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. There is one line that is four characters too long. If the IESG would prefer, an updated draft can be produced that fixes that. Or the RFC Editor could. (1.h) Has the document split its references into normative and informative? The draft only includes informative references. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. no (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? yes. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? there are no such sections. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document revisits and updates the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The role of the IETF is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original 3177 recommendations. Moreover, the document clarifies that a one- size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default. This document updates and replaces RFC 3177. Working Group Summary The IPv6 Operations Working Group very solidly supported the specific changes in proposed policy from RFC 3177. These are: 1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site by definition implies multiple subnets and multiple devices. 2) RFC 3177 specifically recommended using prefix lengths of /48, /64 and /128. Specifying a small number of fixed boundaries has raised concerns that implementations and operational practices might become "hard-coded" to recognize only those fixed boundaries (i.e., a return to "classful addressing"). The actual intention has always been that there be no hard-coded boundaries within addresses, and that CIDR continues to apply to all bits of the routing prefixes. 3) This document moves away from the previous recommendation that a single default assignment size (e.g., a /48) makes sense for all end sites in the general case. End sites come in different shapes and sizes, and a one-size-fits-all approach is not necessary or appropriate. This document does, however, reaffirm an important assumption behind RFC 3177: A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space. Document Quality The document appears to be of very high quality and essentially unanimous support. |
|
2010-11-07
|
01 | Cindy Morgan | Earlier history may be found in the Comment Log for <a href="/doc/draft-narten-ipv6-3177bis-48boundary/">draft-narten-ipv6-3177bis-48boundary</a>. |
|
2010-10-04
|
01 | (System) | Earlier history may be found in the Comment Log for <a href="/doc/draft-narten-ipv6-3177bis-48boundary/">draft-narten-ipv6-3177bis-48boundary</a>. |
|
2010-10-04
|
01 | (System) | Draft Added by the IESG Secretary in state 0. by system |
|
2010-09-26
|
00 | (System) | New version available: draft-ietf-v6ops-3177bis-end-sites-00.txt |