Skip to main content

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