draft-ietf-v6ops-3177bis-end-sites-01.txt   rfc6177.txt 
Internet Engineering Task Force Thomas Narten Internet Engineering Task Force (IETF) T. Narten
Internet-Draft IBM Request for Comments: 6177 IBM
Intended Status: BCP Geoff Huston BCP: 157 G. Huston
Expires: July 3, 2011 APNIC Obsoletes: 3177 APNIC
Obsoletes: 3177 Lea Roberts Category: Best Current Practice L. Roberts
Stanford University ISSN: 2070-1721 Stanford University
January 3, 2011 March 2011
IPv6 Address Assignment to End Sites
<draft-ietf-v6ops-3177bis-end-sites-01.txt> IPv6 Address Assignment to End Sites
Status of this Memo Abstract
This Internet-Draft is submitted to IETF in full conformance with the RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks
provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering This document obsoletes RFC 3177.
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This memo documents an Internet Best Current Practice.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 5741.
This Internet-Draft will expire on July 3, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6177.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 20 skipping to change at page 2, line 32
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
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 Table of Contents
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 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 obsoletes RFC 3177.
Contents
Status of this Memo.......................................... 1
1. Introduction............................................. 3
2. On /48 Assignments to End Sites.......................... 4
3. Other RFC 3177 considerations............................ 6
4. Impact on IPv6 Standards................................. 7
4.1. RFC3056: Connection of IPv6 Domains via IPv4 Clouds. 7
4.2. IPv6 Multicast Addressing........................... 7
5. Summary.................................................. 7
6. Security Considerations.................................. 8
7. IANA Considerations...................................... 8
8. Acknowledgments.......................................... 8
9. Normative References..................................... 8
10. Informative References.................................. 8
11. Author's Address........................................ 9 1. Introduction ....................................................3
2. On /48 Assignments to End Sites .................................4
3. Other RFC 3177 Considerations ...................................6
4. Impact on IPv6 Standards ........................................6
4.1. RFC 3056: Connection of IPv6 Domains via IPv4 Clouds .......6
4.2. IPv6 Multicast Addressing ..................................7
5. Summary .........................................................7
6. Security Considerations .........................................8
7. Acknowledgments .................................................8
8. Informative References ..........................................8
1. Introduction 1. Introduction
There are a number of considerations that factor into address There are a number of considerations that factor into address
assignment policies. For example, to provide for the long-term health assignment policies. For example, to provide for the long-term
and scalability of the public routing infrastructure, it is important health and scalability of the public routing infrastructure, it is
that addresses aggregate well [ROUTE-SCALING]. Likewise, giving out important that addresses aggregate well [ROUTE-SCALING]. Likewise,
an excessive amount of address space could result in premature giving out an excessive amount of address space could result in
depletion of the address space. This document focuses on the (more premature depletion of the address space. This document focuses on
narrow) question of what is an appropriate IPv6 address assignment the (more narrow) question of what is an appropriate IPv6 address
size for end sites. That is, when end sites request IPv6 address assignment size for end sites. That is, when end sites request IPv6
space from ISPs, what is an appropriate assignment size. address space from ISPs, what is an appropriate assignment size.
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 recommendations of RFC 3177 [RIR-IPV6]. In 2005,
RIRs began discussing IPv6 address assignment policy again. Since the RIRs began discussing IPv6 address assignment policy again.
then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE] and RIPE [RIPE- Since then, APNIC [APNIC-ENDSITE], ARIN [ARIN-ENDSITE], and RIPE
ENDSITE] have revised the end site assignment policy to encourage the [RIPE-ENDSITE] have revised the end site assignment policy to
assignment of smaller (i.e., /56) blocks to end sites. encourage the assignment of smaller (i.e., /56) blocks to end sites.
This document obsoletes RFC 3177, updating its recommendations in the This document obsoletes RFC 3177, updating its recommendations in the
following ways: 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
may be some cases where assigning only a single address may be there may be some cases where assigning only a single address
justified, a site by definition implies multiple subnets and may be justified, a site, by definition, implies multiple
multiple devices. subnets and 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
raised concerns that implementations and operational practices has raised concerns that implementations and operational
might become "hard-coded" to recognize only those fixed practices might become "hard-coded" to recognize only those
boundaries (i.e., a return to "classful addressing"). The actual fixed boundaries (i.e., a return to "classful addressing").
intention has always been that there be no hard-coded boundaries The actual intention has always been that there be no hard-
within addresses, and that CIDR continues to apply to all bits coded boundaries within addresses, and that Classless Inter-
of the routing prefixes. Domain Routing (CIDR) continues to apply to all bits of the
routing prefixes.
3) This document moves away from the previous recommendation that a 3) This document moves away from the previous recommendation that
single default assignment size (e.g., a /48) makes sense for all a single default assignment size (e.g., a /48) makes sense for
end sites in the general case. End sites come in different all end sites in the general case. End sites come in different
shapes and sizes, and a one-size-fits-all approach is not shapes and sizes, and a one-size-fits-all approach is not
necessary or appropriate. necessary or appropriate.
This document does, however, reaffirm an important assumption behind This document does, however, reaffirm an important assumption behind
RFC 3177: RFC 3177:
A key principle for address management is that end sites always A key principle for address management is that end sites always be
be able to obtain a reasonable amount of address space for their able to obtain a reasonable amount of address space for their
actual and planned usage, and over time ranges specified in actual and planned usage, and over time ranges specified in years
years rather than just months. In practice, that means at least rather than just months. In practice, that means at least one
one /64, and in most cases significantly more. One particular /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
other burdensome address conservation techniques because it burdensome address conservation techniques because it could not
could not get sufficient address space. 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 IETF's role in this case 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
sufficient address space without having to "jump through hoops" to do sufficient address space without having to "jump through hoops" to do
so. For example, if someone felt they needed more space, just the act so. For example, if someone felt they needed more space, just the
of asking would at some level be sufficient justification. As a act of asking would at some level be sufficient justification. As a
comparison point, in IPv4, typical home users are given a single comparison point, in IPv4, typical home users are given a single
public IP address (though even this is not always assured), but public IP address (though even this is not always assured), but
getting any more than one address is often difficult or even getting any more than one address is often difficult or even
impossible -- unless one is willing to pay a (significantly) impossible -- unless one is willing to pay a (significantly)
increased fee for what is often considered to be a "higher grade" of increased fee for what is often considered to be a "higher grade" of
service. (It should be noted that increased ISP charges to obtain a service. (It should be noted that increased ISP charges to obtain a
small number of additional addresses cannot usually be justified by small number of additional addresses cannot usually be justified by
the real per-address cost levied by RIRs, but additional addresses the real per-address cost levied by RIRs, but additional addresses
are frequently only available to end users as part of a different are frequently only available to end users as part of a different
type or "higher grade" of service, for which an additional charge is type or "higher grade" of service, for which an additional charge is
levied. The point here is that the additional cost is not due to the levied. The point here is that the additional cost is not due to the
RIR fee structures, but to business choices ISPs make.) An important RIR fee structures, but to business choices ISPs make.) An important
goal in IPv6 is to significantly change the default and minimal end goal in IPv6 is to significantly change the default and minimal end
site assignment, from "a single address" to "multiple networks" and site assignment, from "a single address" to "multiple networks" and
to ensure that end sites can easily obtain address space. to ensure that end sites can easily obtain address space.
A second motivation behind the original /48 recommendation was to A second motivation behind the original /48 recommendation was to
simplify the management of an end site's addressing plan in the simplify the management of an end site's addressing plan in the
presence of renumbering (e.g., when switching ISPs). In IPv6, a site presence of renumbering (e.g., when switching ISPs). In IPv6, a site
may simultaneously use multiple prefixes, including one or more may simultaneously use multiple prefixes, including one or more
public prefixes from ISPs as well as Unique Local Addresses [ULA- public prefixes from ISPs as well as Unique Local Addresses
ADDRESSES]. In the presence of multiple prefixes, it is significantly [ULA-ADDRESSES]. In the presence of multiple prefixes, it is
less complex to manage a numbering plan if the same subnet numbering significantly less complex to manage a numbering plan if the same
plan can be used for all prefixes. That is, for a link that has (say) subnet numbering plan can be used for all prefixes. That is, for a
three different prefixes assigned to it, the subnet portion of those link that has (say) three different prefixes assigned to it, the
prefixes would be identical for all assigned addresses. In contrast, subnet portion of those prefixes would be identical for all assigned
renumbering from a larger set of "subnet bits" into a smaller set is addresses. In contrast, renumbering from a larger set of "subnet
often painful, as it it can require making changes to the network bits" into a smaller set is often painful, as it can require making
itself (e.g., collapsing subnets). Hence renumbering a site into a changes to the network itself (e.g., collapsing subnets). Hence,
prefix that has (at least) the same number of subnet bits is more renumbering a site into a prefix that has (at least) the same number
straightforward, because only the top-level bits of the address need of subnet bits is more straightforward, because only the top-level
to change. A key goal of the RFC 3177 recommendations is to ensure bits of the address need to change. A key goal of the
that upon renumbering, one does not have to deal with renumbering recommendations in RFC 3177 is to ensure that upon renumbering, one
into a smaller subnet size. does not have to deal with renumbering into a smaller subnet size.
It should be noted that similar arguments apply to the management of It should be noted that similar arguments apply to the management of
zone files in the DNS. In particular, managing the reverse (ip6.arpa) zone files in the DNS. In particular, managing the reverse
tree is simplified when all links are numbered using the same subnet (ip6.arpa) tree is simplified when all links are numbered using the
ids. same subnet ids.
A third motivation behind the /48 recommendation was to better A third motivation behind the /48 recommendation was to better
support network growth common at many sites. In IPv4, it is usually support network growth common at many sites. In IPv4, it is usually
difficult (or impossible) to obtain public address space for more difficult (or impossible) to obtain public address space for more
than a few months worth of projected growth. Thus, even slow growth than a few months worth of projected growth. Thus, even slow growth
over several years can lead to the need to renumber into a larger over several years can lead to the need to renumber into a larger
address blocks. With IPv6's vast address space, end sites can easily address block. With IPv6's vast address space, end sites can easily
be given more address space (compared with IPv4) to support expected be given more address space (compared with IPv4) to support expected
growth over multi-year time periods. growth over multi-year time periods.
While the /48 recommendation does simplify address space management While the /48 recommendation does simplify address space management
for end sites, it has also been widely criticized as being wasteful. for end sites, it has also been widely criticized as being wasteful.
For example, a large business (which may have thousands of employees) For example, a large business (which may have thousands of employees)
would by default receive the same amount of address space as a home would, by default, receive the same amount of address space as a home
user, who today typically has a single (or small number of) LANs and user, who today typically has a single (or small number of) LAN and a
a small number of devices (dozens or less). While it seems likely small number of devices (dozens or less). While it seems likely that
that the size of a typical home network will grow over the next few the size of a typical home network will grow over the next few
decades, it is hard to argue that home sites will make use of 65K decades, it is hard to argue that home sites will make use of 65K
subnets within the foreseeable future. At the same time, it might be subnets within the foreseeable future. At the same time, it might be
tempting to give home sites a single /64, since that is already tempting to give home sites a single /64, since that is already
significantly more address space compared with today's IPv4 practice. significantly more address space compared with today's IPv4 practice.
However, this precludes the expectation that even home sites will However, this precludes the expectation that even home sites will
grow to support multiple subnets going forward. Hence, it is strongly grow to support multiple subnets going forward. Hence, it is
intended that even home sites be given multiple subnets worth of strongly intended that even home sites be given multiple subnets
space by default. Hence, this document still recommends giving home worth of space, by default. Hence, this document still recommends
sites significantly more than a single /64, but does not recommend giving home sites significantly more than a single /64, but does not
that every home site be given a /48 either. recommend that every home site be given a /48 either.
A change in policy (such as above) would have a significant impact on A change in policy (such as above) would have a significant impact on
address consumption projections and the expected longevity for IPv6. address consumption projections and the expected longevity for IPv6.
For example, changing the default assignment from a /48 to /56 (for For example, changing the default assignment from a /48 to /56 (for
the vast majority of end sites, e.g, home sites) would result in a the vast majority of end sites, e.g., home sites) would result in a
savings of up to 8 bits, reducing the "total projected address savings of up to 8 bits, reducing the "total projected address
consumption" by (up to) 8 bits or two orders of magnitude. (The exact consumption" by (up to) 8 bits or two orders of magnitude. (The
amount of savings depends on the relative number of home users exact amount of savings depends on the relative number of home users
compared with the number of larger sites.) compared with the number of larger sites.)
The above-mentioned RFC3177 goals can easily be met by giving home The above-mentioned goals of RFC 3177 can easily be met by giving
users a default assignment of less than /48, such as a /56. home users a default assignment of less than /48, such as a /56.
3. Other RFC 3177 considerations 3. Other RFC 3177 Considerations
RFC3177 suggested that some multihoming approaches (e.g., GSE) might RFC 3177 suggested that some multihoming approaches (e.g.,
benefit from having a fixed /48 boundary. This no longer appears to Generalized Structure Element (GSE)) might benefit from having a
be a consideration. fixed /48 boundary. This no longer appears to be a consideration.
RFC3177 argued that having a "one size fits all" default assignment RFC 3177 argued that having a "one-size-fits-all" default assignment
size reduced the need for customers to continually or repeatedly size reduced the need for customers to continually or repeatedly
justify usage of existing address space in order to get "a little justify the usage of existing address space in order to get "a little
more". Likewise, it also reduces the need for ISPs to evaluate such more". Likewise, it also reduces the need for ISPs to evaluate such
requests. Given the large amount of address space in IPv6, there is requests. Given the large amount of address space in IPv6, there is
plenty of space to grant end sites enough space to be consistent with plenty of space to grant end sites enough space to be consistent with
reasonable growth projections over multi-year time frames. Thus, it reasonable growth projections over multi-year time frames. Thus, it
remains highly desirable to provide end sites with enough space (on remains highly desirable to provide end sites with enough space (on
both initial and subsequent assignments) to last several years. both initial and subsequent assignments) to last several years.
Fortunately, this goal can be achieved in a number of ways and does Fortunately, this goal can be achieved in a number of ways and does
not require that all end sites receive the same default size not require that all end sites receive the same default size
assignment. assignment.
4. Impact on IPv6 Standards 4. Impact on IPv6 Standards
4.1. RFC3056: Connection of IPv6 Domains via IPv4 Clouds 4.1. RFC 3056: Connection of IPv6 Domains via IPv4 Clouds
RFC3056 [RFC3056] describes a way of generating IPv6 addresses from RFC 3056 [RFC3056] describes a way of generating IPv6 addresses from
an existing public IPv4 address. That document describes an address an existing public IPv4 address. That document describes an address
format in which the first 48 bits concatenate a well-known prefix format in which the first 48 bits concatenate a well-known prefix
with a globally unique public IPv4 address. The "SLA ID" field is with a globally unique public IPv4 address. The "SLA ID" field is
assumed to be 16 bits, consistent with a 16-bit "subnet id" field. To assumed to be 16 bits, consistent with a 16-bit "subnet id" field.
facilitate transitioning from an RFC3056 address numbering scheme to To facilitate transitioning from the address numbering scheme in RFC
one based on a prefix obtained from an ISP, an end site would be 3056 to one based on a prefix obtained from an ISP, an end site would
advised to number out of the right most bits first, using the left be advised to number out of the right most bits first, using the
most bits only if the size of the site made that necessary. leftmost bits only if the size of the site made that necessary.
Similar considerations apply to other documents that allow for a Similar considerations apply to other documents that allow for a
subnet id of 16 bits, including [ULA-ADDRESSES]. subnet id of 16 bits, including [ULA-ADDRESSES].
4.2. IPv6 Multicast Addressing 4.2. IPv6 Multicast Addressing
Some IPv6 multicast address assignment schemes embed a unicast IPv6 Some IPv6 multicast address assignment schemes embed a unicast IPv6
prefix into the multicast address itself [RFC3306]. Such documents do prefix into the multicast address itself [RFC3306]. Such documents
not assume a particular size for the subnet id per se, but do assume do not assume a particular size for the subnet id, per se, but do
that the IPv6 prefix is a /64. Thus, the relative size of the subnet assume that the IPv6 prefix is a /64. Thus, the relative size of the
id has no direct impact on multicast address schemes. subnet id has no direct impact on multicast address schemes.
5. Summary 5. Summary
The exact choice of how much address space to assign end sites is an The exact choice of how much address space to assign end sites is an
issue for the operational community. The RFC 3177 [RFC3177] issue for the operational community. The recommendation in RFC 3177
recommendation to assign /48s as a default is not a requirement of [RFC3177] to assign /48s as a default is not a requirement of the
the IPv6 architecture; anything of length /64 or shorter works from a IPv6 architecture; anything of length /64 or shorter works from a
standards perspective. However, there are important operational standards perspective. However, there are important operational
considerations as well, some of which are important if users are to considerations as well, some of which are important if users are to
share in the key benefit of IPv6: expanding the usable address space share in the key benefit of IPv6: expanding the usable address space
of the Internet. The IETF recommends that any policy on IPv6 address of the Internet. The IETF recommends that any policy on IPv6 address
assignment policy to end sites take into consideration: assignment policy to end sites take into consideration the following:
- it should be easy for an end site to obtain address space to - it should be easy for an end site to obtain address space to
number multiple subnets (i.e., a block larger than a single /64) number multiple subnets (i.e., a block larger than a single /64)
and to support reasonable growth projections over long time and to support reasonable growth projections over long time
periods (e.g., a decade or more). periods (e.g., a decade or more).
- the default assignment size should take into consideration the - the default assignment size should take into consideration the
likelihood that an end site will have need for multiple subnets likelihood that an end site will have need for multiple subnets
in the future and avoid the IPv4 practice of having frequent and in the future and avoid the IPv4 practice of having frequent and
continual justification for obtaining small amounts of continual justification for obtaining small amounts of
additional space additional space.
- Although a /64 can (in theory) address an almost unlimited - Although a /64 can (in theory) address an almost unlimited
number of devices, sites should be given sufficient address number of devices, sites should be given sufficient address
space to be able to lay out subnets as appropriate, and not be space to be able to lay out subnets as appropriate, and not be
forced to use address conservation techniques such as using forced to use address conservation techniques such as using
bridging. Whether or not bridging is an appropriate choice is an bridging. Whether or not bridging is an appropriate choice is
end site matter. an end site matter.
- assigning a longer prefix to an end site, compared with the - assigning a longer prefix to an end site, compared with the
existing prefixes the end site already has assigned to it, is existing prefixes the end site already has assigned to it, is
likely to increase operational costs and complexity for the end likely to increase operational costs and complexity for the end
site, with insufficient benefit to anyone. site, with insufficient benefit to anyone.
- the operational considerations of managing and delegating the - the operational considerations of managing and delegating the
reverse DNS tree under ip6.arpa on nibble vs. non-nibble reverse DNS tree under ip6.arpa on nibble versus non-nibble
boundaries should be given adequate consideration boundaries should be given adequate consideration.
6. Security Considerations 6. Security Considerations
This document has no known security implications. This document has no known security implications.
7. IANA Considerations 7. Acknowledgments
This document makes no requests to IANA.
8. Acknowledgments
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 8. 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 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- policy.html
policy.html
[RFC3056] "Connection of IPv6 Domains via IPv4 Clouds," B. Carpenter, [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
K. Moore, RFC 3056, February 2001. Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3306] "Unicast-Prefix-based IPv6 Multicast Addresses," B. [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based
Haberman, D. Thaler, RFC 3306, August 2002. IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3177] IAB/IESG Recommendations on IPv6 Address Allocations to [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6
Sites. IAB, IESG. September 2001. Address Allocations to Sites", RFC 3177, September
2001.
[RIPE-ENDSITE] "Proposal to Amend the IPv6 Assignment and Utilisation [RIPE-ENDSITE] "Proposal to Amend the IPv6 Assignment and
Requirement Policy", 2005-8, Utilisation Requirement Policy", 2005-8,
http://ripe.net/ripe/policies/proposals/2005-08.html http://www.ripe.net/ripe/policies/proposals/2005-08.
[ROUTE-SCALING] "Routing and Addressing Problem Statement", draft- [ROUTE-SCALING] "Routing and Addressing Problem Statement", Work in
narten-radir-problem-statement-05.txt Progress, February 2010.
[ULA-ADDRESSES] RFC 4193 "Unique Local IPv6 Unicast Addresses," R. [ULA-ADDRESSES] Hinden, R. and B. Haberman, "Unique Local IPv6
Hinden, B. Haberman, RFC 4193, October 2005. Unicast Addresses", RFC 4193, October 2005.
11. Author's Address Authors' Addresses
Thomas Narten Thomas Narten
IBM Corporation IBM Corporation
3039 Cornwallis Ave. 3039 Cornwallis Ave.
PO Box 12195 PO Box 12195
Research Triangle Park, NC 27709-2195 Research Triangle Park, NC 27709-2195
Phone: 919-254-7798 Phone: 919-254-7798
EMail: narten@us.ibm.com EMail: narten@us.ibm.com
skipping to change at page 10, line 4 skipping to change at page 9, line 23
PO Box 12195 PO Box 12195
Research Triangle Park, NC 27709-2195 Research Triangle Park, NC 27709-2195
Phone: 919-254-7798 Phone: 919-254-7798
EMail: narten@us.ibm.com EMail: narten@us.ibm.com
Geoff Huston Geoff Huston
APNIC APNIC
EMail: gih@apnic.net EMail: gih@apnic.net
Rosalea G Roberts Rosalea G Roberts
Stanford University, Networking Systems Stanford University, Networking Systems
P.O. Box 19131 P.O. Box 19131
Stanford, CA 94309-9131 Stanford, CA 94309-9131
Email: lea.roberts@stanford.edu EMail: lea.roberts@stanford.edu
Phone: +1-650-723-3352 Phone: +1-650-723-3352
 End of changes. 63 change blocks. 
215 lines changed or deleted 186 lines changed or added

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