draft-ietf-v6ops-3177bis-end-sites-00.txt   draft-ietf-v6ops-3177bis-end-sites-01.txt 
Internet Engineering Task Force Thomas Narten Internet Engineering Task Force Thomas Narten
Internet-Draft IBM Internet-Draft IBM
Intended Status: BCP Geoff Huston Intended Status: BCP Geoff Huston
Expires: March 26, 2011 APNIC Expires: July 3, 2011 APNIC
Updates: 3177 Lea Roberts Obsoletes: 3177 Lea Roberts
Stanford University Stanford University
September 26, 2010 January 3, 2011
IPv6 Address Assignment to End Sites IPv6 Address Assignment to End Sites
<draft-ietf-v6ops-3177bis-end-sites-00.txt> <draft-ietf-v6ops-3177bis-end-sites-01.txt>
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2011. This Internet-Draft will expire on July 3, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Abstract Abstract
RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks
in most cases. The Regional Internet Registries (RIRs) adopted that in most cases. The Regional Internet Registries (RIRs) adopted that
recommendation in 2002, but began reconsidering the policy in 2005. recommendation in 2002, but began reconsidering the policy in 2005.
This document revisits and updates the RFC 3177 recommendations on This document obsoletes the RFC 3177 recommendations on the
the assignment of IPv6 address space to end sites. The exact choice assignment of IPv6 address space to end sites. The exact choice of
of how much address space to assign end sites is an issue for the how much address space to assign end sites is an issue for the
operational community. The role of the IETF is limited to providing operational community. The IETF's role in this case is limited to
guidance on IPv6 architectural and operational considerations. This providing guidance on IPv6 architectural and operational
document reviews the architectural and operational considerations of considerations. This document reviews the architectural and
end site assignments as well as the motivations behind the original operational considerations of end site assignments as well as the
3177 recommendations. Moreover, the document clarifies that a one- motivations behind the original 3177 recommendations. Moreover, the
size-fits-all recommendation of /48 is not nuanced enough for the document clarifies that a one-size-fits-all recommendation of /48 is
broad range of end sites and is no longer recommended as a single not nuanced enough for the broad range of end sites and is no longer
default. recommended as a single default.
This document updates and replaces RFC 3177.
This document obsoletes RFC 3177.
Contents Contents
Status of this Memo.......................................... 1 Status of this Memo.......................................... 1
1. Introduction............................................. 3 1. Introduction............................................. 3
2. On /48 Assignments to End Sites.......................... 4 2. On /48 Assignments to End Sites.......................... 4
3. Other RFC 3177 considerations............................ 6 3. Other RFC 3177 considerations............................ 6
skipping to change at page 3, line 42 skipping to change at page 3, line 40
RFC 3177 [RFC3177] called for a default end site IPv6 assignment size RFC 3177 [RFC3177] called for a default end site IPv6 assignment size
of /48. Subsequently, the Regional Internet Registries (RIRs) of /48. Subsequently, the Regional Internet Registries (RIRs)
developed and adopted IPv6 address assignment and allocation policies developed and adopted IPv6 address assignment and allocation policies
consistent with the RFC 3177 recommendations [RIR-IPV6]. In 2005, the consistent with the RFC 3177 recommendations [RIR-IPV6]. In 2005, the
RIRs began discussing IPv6 address assignment policy again. Since RIRs began discussing IPv6 address assignment policy again. Since
then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE] and RIPE [RIPE- then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE] and RIPE [RIPE-
ENDSITE] have revised the end site assignment policy to encourage the ENDSITE] have revised the end site assignment policy to encourage the
assignment of smaller (i.e., /56) blocks to end sites. assignment of smaller (i.e., /56) blocks to end sites.
This document updates and replaces the RFC 3177 recommendations. This document obsoletes RFC 3177, updating its recommendations in the
following ways:
Specifically, this document updates RFC 3177 in the following ways:
1) It is no longer recommended that /128s be given out. While there 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 may be some cases where assigning only a single address may be
justified, a site by definition implies multiple subnets and justified, a site by definition implies multiple subnets and
multiple devices. multiple devices.
2) RFC 3177 specifically recommended using prefix lengths of /48, 2) RFC 3177 specifically recommended using prefix lengths of /48,
/64 and /128. Specifying a small number of fixed boundaries has /64 and /128. Specifying a small number of fixed boundaries has
raised concerns that implementations and operational practices raised concerns that implementations and operational practices
might become "hard-coded" to recognize only those fixed might become "hard-coded" to recognize only those fixed
skipping to change at page 4, line 36 skipping to change at page 4, line 31
years rather than just months. In practice, that means at least years rather than just months. In practice, that means at least
one /64, and in most cases significantly more. One particular one /64, and in most cases significantly more. One particular
situation that must be avoided is having an end site feel situation that must be avoided is having an end site feel
compelled to use IPv6-to-IPv6 Network Address Translation or compelled to use IPv6-to-IPv6 Network Address Translation or
other burdensome address conservation techniques because it other burdensome address conservation techniques because it
could not get sufficient address space. could not get sufficient address space.
This document does not make a formal recommendation on what the exact This document does not make a formal recommendation on what the exact
assignment size should be. The exact choice of how much address assignment size should be. The exact choice of how much address
space to assign end sites is an issue for the operational community. space to assign end sites is an issue for the operational community.
The role of the IETF is limited to providing guidance on IPv6 The IETF's role in this case is limited to providing guidance on IPv6
architectural and operational considerations. This document provides architectural and operational considerations. This document provides
input into those discussions. The focus of this document is to input into those discussions. The focus of this document is to
examine the architectural issues and some of the operational examine the architectural issues and some of the operational
considerations relating to the size of the end site assignment. considerations relating to the size of the end site assignment.
2. On /48 Assignments to End Sites 2. On /48 Assignments to End Sites
Looking back at some of the original motivations behind the /48 Looking back at some of the original motivations behind the /48
recommendation [RFC3177], there were three main concerns. The first recommendation [RFC3177], there were three main concerns. The first
motivation was to ensure that end sites could easily obtain motivation was to ensure that end sites could easily obtain
skipping to change at page 8, line 43 skipping to change at page 8, line 43
This document was motivated by and benefited from numerous This document was motivated by and benefited from numerous
conversations held during the ARIN XV and RIPE 50 meetings in April- conversations held during the ARIN XV and RIPE 50 meetings in April-
May, 2005. May, 2005.
9. Normative References 9. Normative References
10. Informative References 10. Informative References
[APNIC-ENDSITE] "prop-031: Proposal to amend APNIC IPv6 assignment [APNIC-ENDSITE] "prop-031: Proposal to amend APNIC IPv6 assignment
and utilisation requirement policy," and utilisation requirement policy,"
http://www.apnic.net/policy/proposals/prop-031-v002.html http://www.apnic.net/policy/proposals/prop-031
[ARIN-ENDSITE] "2005-8: Proposal to amend ARIN IPv6 assignment and [ARIN-ENDSITE] "2005-8: Proposal to amend ARIN IPv6 assignment and
utilisation requirement", utilisation requirement",
http://www.arin.net/policy/proposals/2005_8.html http://www.arin.net/policy/proposals/2005_8.html
[RIR-IPV6] ARIN: http://www.arin.net/policy/nrpm.html#ipv6; RIPE [RIR-IPV6] ARIN: http://www.arin.net/policy/nrpm.html#ipv6; RIPE
Document ID: ripe-267, Date: 22 January 2003 Document ID: ripe-267, Date: 22 January 2003
http://www.ripe.net/ripe/docs/ipv6policy.html; http://www.ripe.net/ripe/docs/ipv6policy.html;
APNIC: APNIC:
http://www.apnic.net/docs/policy/ipv6-address- http://www.apnic.net/docs/policy/ipv6-address-
 End of changes. 9 change blocks. 
23 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/