<- BCP Index (101..200)
(also RFC 6598, RFC 6890, RFC 8190)
[Note that this file is a concatenation of more than one RFC.]
Internet Engineering Task Force (IETF) J. Weil
Request for Comments: 6598 Time Warner Cable
BCP: 153 V. Kuarsingh
Updates: 5735 Rogers Communications
Category: Best Current Practice C. Donley
ISSN: 2070-1721 CableLabs
C. Liljenstolpe
Telstra Corp.
M. Azinger
Frontier Communications
April 2012
IANA-Reserved IPv4 Prefix for Shared Address Space
Abstract
This document requests the allocation of an IPv4 /10 address block to
be used as Shared Address Space to accommodate the needs of Carrier-
Grade NAT (CGN) devices. It is anticipated that Service Providers
will use this Shared Address Space to number the interfaces that
connect CGN devices to Customer Premises Equipment (CPE).
Shared Address Space is distinct from RFC 1918 private address space
because it is intended for use on Service Provider networks.
However, it may be used in a manner similar to RFC 1918 private
address space on routing equipment that is able to do address
translation across router interfaces when the addresses are identical
on two different interfaces. Details are provided in the text of
this document.
This document details the allocation of an additional special-use
IPv4 address block and updates RFC 5735.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(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.
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/rfc6598.
Weil, et al. Best Current Practice [Page 1]
RFC 6598 Shared Address Space Request April 2012
IESG Note
A number of operators have expressed a need for the special-purpose
IPv4 address allocation described by this document. During
deliberations, the IETF community demonstrated very rough consensus
in favor of the allocation.
While operational expedients, including the special-purpose address
allocation described in this document, may help solve a short-term
operational problem, the IESG and the IETF remain committed to the
deployment of IPv6.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Alternatives to Shared Address Space ............................3
4. Use of Shared CGN Space .........................................4
5. Risk ............................................................5
5.1. Analysis ...................................................5
5.2. Empirical Data .............................................6
6. Security Considerations .........................................7
7. IANA Considerations .............................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
Appendix A. Acknowledgments .......................................10
Weil, et al. Best Current Practice [Page 2]
RFC 6598 Shared Address Space Request April 2012 1. Introduction IPv4 address space is nearly exhausted. However, ISPs must continue to support IPv4 growth until IPv6 is fully deployed. To that end, many ISPs will deploy a Carrier-Grade NAT (CGN) device, such as that described in [RFC6264]. Because CGNs are used on networks where public address space is expected, and currently available private address space causes operational issues when used in this context, ISPs require a new IPv4 /10 address block. This address block will be called the "Shared Address Space" and will be used to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE). Shared Address Space is similar to [RFC1918] private address space in that it is not globally routable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space. In conversations with many ISPs, a /10 is the smallest block that will allow them to deploy CGNs on a regional basis without requiring nested CGNs. For instance, as described in [ISP-SHARED-ADDR], a /10 is sufficient to service Points of Presence in the Tokyo area. This document details the allocation of an additional special-use IPv4 address block and updates [RFC5735]. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Alternatives to Shared Address Space The interfaces that connect CGN devices to CPE might conceivably be numbered from any of the following address spaces: o legitimately assigned globally unique address space o usurped globally unique address space (i.e., squat space) Weil, et al. Best Current Practice [Page 3]
RFC 6598 Shared Address Space Request April 2012
o [RFC1918] space
o Shared Address Space
A Service Provider can number the interfaces in question from
legitimately assigned globally unique address space. While this
solution poses the fewest problems, it is impractical because
globally unique IPv4 address space is in short supply. While the
Regional Internet Registries (RIRs) have enough address space to
allocate a single /10 to be shared by all Service Providers, they do
not have enough address space to make a unique assignment to each
Service Provider.
Service Providers MUST NOT number the interfaces in question from
usurped globally unique address space (i.e., squat space). If a
Service Provider leaks advertisements for squat space into the global
Internet, the legitimate holders of that address space may be
adversely impacted, as would those wishing to communicate with them.
Even if the Service Provider did not leak advertisements for squat
space, the Service Provider and its subscribers might lose
connectivity to the legitimate holders of that address space.
A Service Provider can number the interfaces in question from
[RFC1918] space if at least one of the following conditions is true:
o The Service Provider knows that the CPE/NAT works correctly when
the same [RFC1918] address block is used on both its inside and
outside interfaces.
o The Service Provider knows that the [RFC1918] address block that
it uses to number interfaces between the CGN and CPE is not used
on the subscriber side of the CPE.
Unless at least one of the conditions above is true, the Service
Provider cannot safely use [RFC1918] address space and must resort to
Shared Address Space. This is typically the case in an unmanaged
service, where subscribers provide their own CPE and number their own
internal network.
4. Use of Shared CGN Space
Shared Address Space is IPv4 address space designated for Service
Provider use with the purpose of facilitating CGN deployment. Also,
Shared Address Space can be used as additional non-globally routable
space on routing equipment that is able to do address translation
across router interfaces when the addresses are identical on two
different interfaces.
Weil, et al. Best Current Practice [Page 4]
RFC 6598 Shared Address Space Request April 2012 Devices MUST be capable of performing address translation when identical Shared Address Space ranges are used on two different interfaces. Packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links. One exception to this paragraph's proscription is in the case of business relationships, such as hosted CGN services. When running a single DNS infrastructure, Service Providers MUST NOT include Shared Address Space in zone files. When running a split DNS infrastructure, Service Providers MUST NOT include Shared Address Space in external-facing zone files. Reverse DNS queries for Shared Address Space addresses MUST NOT be forwarded to the global DNS infrastructure. DNS Providers SHOULD filter requests for Shared Address Space reverse DNS queries on recursive nameservers. This is done to avoid having to set up something similar to AS112.net for [RFC1918] private address space that a host has incorrectly sent for a DNS that reverse-maps queries on the public Internet [RFC6304]. Because CGN service requires non-overlapping address space on each side of the home NAT and CGN, entities using Shared Address Space for purposes other than for CGN service, as described in this document, are likely to experience problems implementing or connecting to CGN service at such time as they exhaust their supply of public IPv4 addresses. 5. Risk 5.1. Analysis Some existing applications discover the outside address of their local CPE, determine whether the address is reserved for special use, and behave differently based on that determination. If a new IPv4 address block is reserved for special use and that block is used to number CPE outside interfaces, some of the above-mentioned applications may fail. For example, assume that an application requires its peer (or some other device) to initiate an incoming connection directly with its CPE's outside address. That application discovers the outside address of its CPE and determines whether that address is reserved for special use. If the address is reserved for special use, the application rightly concludes that the address is not reachable from Weil, et al. Best Current Practice [Page 5]
RFC 6598 Shared Address Space Request April 2012
the global Internet and behaves in one manner. If the address is not
reserved for special use, the application assumes that the address is
reachable from the global Internet and behaves in another manner.
While the assumption that a non-special-use address is reachable from
the global Internet is generally safe, it is not always true (e.g.,
when the CPE outside interface is numbered from globally unique
address space but that address is not advertised to the global
Internet as when it is behind a CGN). Such an assumption could cause
certain applications to behave incorrectly in those cases.
5.2. Empirical Data
The primary motivation for the allocation of Shared Address Space is
as address space for CGNs; the use and impact of CGNs has been
previously described in [RFC6269] and [NAT444-IMPACTS]. Some of the
services adversely impacted by CGNs are as follows:
1. Console gaming -- some games fail when two subscribers using the
same outside public IPv4 address try to connect to each other.
2. Video streaming -- performance is impacted when using one of
several popular video-streaming technologies to deliver multiple
video streams to users behind particular CPE routers.
3. Peer-to-peer -- some peer-to-peer applications cannot seed
content due to the inability to open incoming ports through the
CGN. Likewise, some SIP client implementations cannot receive
incoming calls unless they first initiate outgoing traffic or
open an incoming port through the CGN using the Port Control
Protocol (PCP) [PCP-BASE] or a similar mechanism.
4. Geo-location -- geo-location systems identify the location of the
CGN server, not the end host.
5. Simultaneous logins -- some websites (particularly banking and
social-networking websites) restrict the number of simultaneous
logins per outside public IPv4 address.
6. 6to4 -- 6to4 requires globally reachable addresses and will not
work in networks that employ addresses with limited topological
span, such as those employing CGNs.
Based on testing documented in [NAT444-IMPACTS], the CGN impacts on
items 1-5 above are comparable regardless of whether globally unique,
Shared Address Space, or [RFC1918] addresses are used. There is,
however, a difference between the three alternatives in the treatment
of 6to4.
Weil, et al. Best Current Practice [Page 6]
RFC 6598 Shared Address Space Request April 2012 As described in [RFC6343], CPE routers do not attempt to initialize 6to4 tunnels when they are configured with [RFC1918] or [RFC5735] WAN addresses. When configured with globally unique or Shared Address Space addresses, such devices may attempt to initiate 6to4, which would fail. Service Providers can mitigate this issue using 6to4 Provider Managed Tunnels [6to4-PMT] or blocking the route to 192.88.99.1 and generating an IPv4 'destination unreachable' message [RFC6343]. When the address range is well-defined, as with Shared Address Space, CPE router vendors can include Shared Address Space in their list of special-use addresses (e.g., [RFC5735]) and treat Shared Address Space similarly to [RFC1918] space. When the CGN-CPE address range is not well-defined, as in the case of globally unique space, it will be more difficult for CPE router vendors to mitigate this issue. Thus, when comparing the use of [RFC1918] and Shared Address Space, Shared Address Space poses an additional impact on 6to4 connectivity, which can be mitigated by Service Provider or CPE router vendor action. On the other hand, the use of [RFC1918] address space poses more of a challenge vis-a-vis Shared Address Space when the subscriber and Service Provider use overlapping [RFC1918] space, which will be outside the Service Provider's control in the case of unmanaged service. Service Providers have indicated that it is more challenging to mitigate the possibility of overlapping [RFC1918] address space on both sides of the CPE router than it is to mitigate the 6to4 impacts of Shared Address Space. 6. Security Considerations Similar to other [RFC5735] special-use IPv4 addresses, Shared Address Space does not directly raise security issues. However, the Internet does not inherently protect against abuse of these addresses. Attacks have been mounted that depend on the unexpected use of similar special-use addresses. Network operators are encouraged to review this document and determine what security policies should be associated with this address block within their specific operating environments. They should consider including Shared Address Space in Ingress Filter lists [RFC3704], unless their Internet service incorporates a CGN. Weil, et al. Best Current Practice [Page 7]
RFC 6598 Shared Address Space Request April 2012
To mitigate potential misuse of Shared Address Space, except where
required for hosted CGN service or a similar business relationship,
o routing information about Shared Address Space networks MUST NOT
be propagated across Service Provider boundaries. Service
Providers MUST filter incoming advertisements regarding Shared
Address Space.
o packets with Shared Address Space source or destination addresses
MUST NOT be forwarded across Service Provider boundaries. Service
Providers MUST filter such packets on ingress links.
o Service Providers MUST NOT include Shared Address Space in
external-facing DNS zone files.
o reverse DNS queries for Shared Address Space addresses MUST NOT be
forwarded to the global DNS infrastructure.
o DNS Providers SHOULD filter requests for Shared Address Space
reverse DNS queries on recursive nameservers.
7. IANA Considerations
IANA has recorded the allocation of an IPv4 /10 for use as Shared
Address Space.
The Shared Address Space address range is 100.64.0.0/10.
8. References
8.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010.
Weil, et al. Best Current Practice [Page 8]
RFC 6598 Shared Address Space Request April 2012
8.2. Informative References
[6to4-PMT] Kuarsingh, V., Ed., Lee, Y., and O. Vautrin, "6to4
Provider Managed Tunnels", Work in Progress,
February 2012.
[ISP-SHARED-ADDR]
Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "ISP Shared Address", Work in Progress,
January 2012.
[NAT444-IMPACTS]
Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J.
Doshi, "Assessing the Impact of Carrier-Grade NAT on
Network Applications", Work in Progress, November 2011.
[PCP-BASE] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", Work
in Progress, March 2012.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental
Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
June 2011.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations",
RFC 6304, July 2011.
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
RFC 6343, August 2011.
Weil, et al. Best Current Practice [Page 9]
RFC 6598 Shared Address Space Request April 2012
Appendix A. Acknowledgments
Thanks to the following people (in alphabetical order) for their
guidance and feedback:
Stan Barber
John Brzozowski
Isaiah Connell
Greg Davies
Owen DeLong
Kirk Erichsen
Wes George
Chris Grundemann
Tony Hain
Philip Matthews
John Pomeroy
Barbara Stark
Jean-Francois Tremblay
Leo Vegoda
Steven Wright
Ikuhei Yamagata
Weil, et al. Best Current Practice [Page 10]
RFC 6598 Shared Address Space Request April 2012 Authors' Addresses Jason Weil Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 USA EMail: jason.weil@twcable.com Victor Kuarsingh Rogers Communications 8200 Dixie Road Brampton, ON L6T 0C1 Canada EMail: victor.kuarsingh@gmail.com Chris Donley CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA EMail: c.donley@cablelabs.com Christopher Liljenstolpe Telstra Corp. 7/242 Exhibition Street Melbourne, VIC 316 Australia Phone: +61 3 8647 6389 EMail: cdl@asgaard.org Marla Azinger Frontier Communications Vancouver, WA USA Phone: +1.360.513.2293 EMail: marla.azinger@frontiercorp.com Weil, et al. Best Current Practice [Page 11]
=========================================================================
Internet Engineering Task Force (IETF) M. Cotton
Request for Comments: 6890 L. Vegoda
BCP: 153 ICANN
Obsoletes: 4773, 5156, 5735, 5736 R. Bonica, Ed.
Category: Best Current Practice Juniper Networks
ISSN: 2070-1721 B. Haberman
JHU
April 2013
Special-Purpose IP Address Registries
Abstract
This memo reiterates the assignment of an IPv4 address block
(192.0.0.0/24) to IANA. It also instructs IANA to restructure its
IPv4 and IPv6 Special-Purpose Address Registries. Upon
restructuring, the aforementioned registries will record all special-
purpose address blocks, maintaining a common set of information
regarding each address block.
This memo obsoletes RFCs 4773, 5156, 5735, and 5736.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(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.
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/rfc6890.
Cotton, et al. Best Current Practice [Page 1]
RFC 6890 Special-Purpose Address Registries April 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. IANA Considerations .............................................3
2.1. Assignment of an IPv4 Address Block to IANA ................3
2.2. Restructuring of the IPv4 and IPv6 Special-Purpose
Address ....................................................4
2.2.1. Information Requirements ............................4
2.2.2. IPv4 Special-Purpose Address Registry Entries .......6
2.2.3. IPv6 Special-Purpose Address Registry Entries ......14
3. Security Considerations ........................................20
4. Acknowledgements ...............................................20
5. Informative References .........................................20
1. Introduction
In order to support new protocols and practices, the IETF
occasionally reserves an address block for a special purpose. For
example, [RFC1122] reserves an IPv4 address block (0.0.0.0/8) to
represent the local (i.e., "this") network. Likewise, [RFC4291]
reserves an IPv6 address block (fe80::/10) to represent link-scoped
unicast addresses.
Periodically, the IETF publishes an RFC that catalogs special-purpose
address blocks. Currently, [RFC5735] catalogs all IPv4 special-
purpose address blocks and [RFC5156] catalogs all IPv6 special-
purpose address blocks.
[RFC5736] assigns an IPv4 address block (192.0.0.0/24) to IANA and
instructs IANA to allocate special-purpose address blocks from this
space. [RFC5736] also instructs IANA to create an IPv4 Special-
Purpose Address Registry that records allocations from this address
Cotton, et al. Best Current Practice [Page 2]
RFC 6890 Special-Purpose Address Registries April 2013
space. However, [RFC5736] does not instruct IANA to record special-
purpose address block reservations from outside of the aforementioned
space in the IPv4 Special-Purpose Address Registry.
Likewise, [RFC2928] assigns an IPv6 address block (2001:0000::/23) to
IANA and instructs IANA to allocate special-purpose address blocks
from this space. [RFC4773] instructs IANA to create an IPv6 Special-
Purpose Address Registry that records allocations from this address
space. However, [RFC4773] does not instruct IANA to record special-
purpose address block reservations from outside of the aforementioned
space in the IPv6 Special-Purpose Address Registry.
This memo reiterates the assignment of an IPv4 address block
(192.0.0.0/24) to IANA. It also instructs IANA to restructure its
IPv4 and IPv6 Special-Purpose Address Registries. Specifically, this
memo instructs IANA to record all special-purpose address blocks in
the aforementioned registries. These include, but are not limited
to, IPv4 allocations from 192.0.0.0/24 and IPv6 allocations from
2001:0000::/23. Furthermore, this memo defines:
o a common set of information that the registries will maintain
regarding each special-purpose address block
o a common set of requirements for future entries
When the aforementioned registries include all special-purpose
address blocks, [RFC5735] and [RFC5156] will become redundant with
the registries. Therefore, this memo obsoletes [RFC5735] and
[RFC5156]. Because this memo reiterates the assignment of
192.0.0.0/24 to IANA, and because it restructures the IPv4 Special-
Purpose Address Registry, it obsoletes [RFC5736]. Finally, because
this memo restructures the IPv6 Special-Purpose Address Registry, it
obsoletes [RFC4773].
2. IANA Considerations
2.1. Assignment of an IPv4 Address Block to IANA
Table 7 of this document records the assignment of an IPv4 address
block (192.0.0.0/24) to IANA for IETF protocol assignments. This
address allocation to IANA is intended to support IETF protocol
assignments. A more general view of the roles of IANA with respect
to address allocation functions is documented in Sections 4.1 and 4.3
[RFC2860].
IANA has designated special-purpose address blocks in compliance with
[RFC2860].
Cotton, et al. Best Current Practice [Page 3]
RFC 6890 Special-Purpose Address Registries April 2013
2.2. Restructuring of the IPv4 and IPv6 Special-Purpose Address
Registries
IANA has restructured the following registries:
o IPv4 Special-Purpose Address Registry
o IPv6 Special-Purpose Address Registry
The IPv4 Special-Purpose Address Registry records all IPv4 special-
purpose address blocks. These reservations include, but are not
limited to, allocations from the 192.0.0.0/24 address block.
Likewise, the IPv6 Special-Purpose Address Registry records all IPv6
special-purpose address blocks. These reservations include, but are
not limited to, allocations from the 2001:0000::/23 address block.
Section 2.2.1 of this document describes information that both
registries will maintain for each entry. Initially, IANA has
populated the IPv4 Special-Purpose Address Registry with information
taken from Section 2.2.2 of this document. Likewise, IANA has
populated the IPv6 Special-Purpose Address Registry with information
taken from Section 2.2.3 of this document.
IANA will update the aforementioned registries as requested in the
"IANA Considerations" section of a document that has passed IETF
Review [RFC5226]. The "IANA Considerations" section must include all
of the information specified in Section 2.2.1 of this document.
2.2.1. Information Requirements
The IPv4 and IPv6 Special-Purpose Address Registries maintain the
following information regarding each entry:
o Address Block - A block of IPv4 or IPv6 addresses that has been
registered for a special purpose.
o Name - A descriptive name for the special-purpose address block.
o RFC - The RFC through which the special-purpose address block was
requested.
o Allocation Date - The date upon which the special-purpose address
block was allocated.
o Termination Date - The date upon which the allocation is to be
terminated. This field is applicable for limited-use allocations
only.
Cotton, et al. Best Current Practice [Page 4]
RFC 6890 Special-Purpose Address Registries April 2013
o Source - A boolean value indicating whether an address from the
allocated special-purpose address block is valid when used as the
source address of an IP datagram that transits two devices.
o Destination - A boolean value indicating whether an address from
the allocated special-purpose address block is valid when used as
the destination address of an IP datagram that transits two
devices.
o Forwardable - A boolean value indicating whether a router may
forward an IP datagram whose destination address is drawn from the
allocated special-purpose address block between external
interfaces.
o Global - A boolean value indicating whether an IP datagram whose
destination address is drawn from the allocated special-purpose
address block is forwardable beyond a specified administrative
domain.
o Reserved-by-Protocol - A boolean value indicating whether the
special-purpose address block is reserved by IP, itself. This
value is "TRUE" if the RFC that created the special-purpose
address block requires all compliant IP implementations to behave
in a special way when processing packets either to or from
addresses contained by the address block.
If the value of "Destination" is FALSE, the values of "Forwardable"
and "Global" must also be false.
Cotton, et al. Best Current Practice [Page 5]
RFC 6890 Special-Purpose Address Registries April 2013
2.2.2. IPv4 Special-Purpose Address Registry Entries
Tables 1 though 16, below, represent entries with which IANA has
initially populated the IPv4 Special-Purpose Address Registry.
+----------------------+----------------------------+
| Attribute | Value |
+----------------------+----------------------------+
| Address Block | 0.0.0.0/8 |
| Name | "This host on this network"|
| RFC | [RFC1122], Section 3.2.1.3 |
| Allocation Date | September 1981 |
| Termination Date | N/A |
| Source | True |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | True |
+----------------------+----------------------------+
Table 1: "This host on this network"
+----------------------+---------------+
| Attribute | Value |
+----------------------+---------------+
| Address Block | 10.0.0.0/8 |
| Name | Private-Use |
| RFC | [RFC1918] |
| Allocation Date | February 1996 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+---------------+
Table 2: Private-Use Networks
Cotton, et al. Best Current Practice [Page 6]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+----------------------+
| Attribute | Value |
+----------------------+----------------------+
| Address Block | 100.64.0.0/10 |
| Name | Shared Address Space |
| RFC | [RFC6598] |
| Allocation Date | April 2012 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+----------------------+
Table 3: Shared Address Space
+----------------------+----------------------------+
| Attribute | Value |
+----------------------+----------------------------+
| Address Block | 127.0.0.0/8 |
| Name | Loopback |
| RFC | [RFC1122], Section 3.2.1.3 |
| Allocation Date | September 1981 |
| Termination Date | N/A |
| Source | False [1] |
| Destination | False [1] |
| Forwardable | False [1] |
| Global | False [1] |
| Reserved-by-Protocol | True |
+----------------------+----------------------------+
[1] Several protocols have been granted exceptions to this
rule. For examples, see [RFC4379] and [RFC5884].
Table 4: Loopback
Cotton, et al. Best Current Practice [Page 7]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block | 169.254.0.0/16 |
| Name | Link Local |
| RFC | [RFC3927] |
| Allocation Date | May 2005 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | True |
+----------------------+----------------+
Table 5: Link Local
+----------------------+---------------+
| Attribute | Value |
+----------------------+---------------+
| Address Block | 172.16.0.0/12 |
| Name | Private-Use |
| RFC | [RFC1918] |
| Allocation Date | February 1996 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+---------------+
Table 6: Private-Use Networks
Cotton, et al. Best Current Practice [Page 8]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+---------------------------------+
| Attribute | Value |
+----------------------+---------------------------------+
| Address Block | 192.0.0.0/24 [2] |
| Name | IETF Protocol Assignments |
| RFC | Section 2.1 of this document |
| Allocation Date | January 2010 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+---------------------------------+
[2] Not usable unless by virtue of a more specific
reservation.
Table 7: IETF Protocol Assignments
+----------------------+--------------------------------+
| Attribute | Value |
+----------------------+--------------------------------+
| Address Block | 192.0.0.0/29 |
| Name | DS-Lite |
| RFC | [RFC6333] |
| Allocation Date | June 2011 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+--------------------------------+
Table 8: DS-Lite
Cotton, et al. Best Current Practice [Page 9]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+----------------------------+
| Attribute | Value |
+----------------------+----------------------------+
| Address Block | 192.0.2.0/24 |
| Name | Documentation (TEST-NET-1) |
| RFC | [RFC5737] |
| Allocation Date | January 2010 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+----------------------------+
Table 9: TEST-NET-1
+----------------------+--------------------+
| Attribute | Value |
+----------------------+--------------------+
| Address Block | 192.88.99.0/24 |
| Name | 6to4 Relay Anycast |
| RFC | [RFC3068] |
| Allocation Date | June 2001 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+--------------------+
Table 10: 6to4 Relay Anycast
Cotton, et al. Best Current Practice [Page 10]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block | 192.168.0.0/16 |
| Name | Private-Use |
| RFC | [RFC1918] |
| Allocation Date | February 1996 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+----------------+
Table 11: Private-Use Networks
+----------------------+---------------+
| Attribute | Value |
+----------------------+---------------+
| Address Block | 198.18.0.0/15 |
| Name | Benchmarking |
| RFC | [RFC2544] |
| Allocation Date | March 1999 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+---------------+
Table 12: Network Interconnect Device Benchmark Testing
Cotton, et al. Best Current Practice [Page 11]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+----------------------------+
| Attribute | Value |
+----------------------+----------------------------+
| Address Block | 198.51.100.0/24 |
| Name | Documentation (TEST-NET-2) |
| RFC | [RFC5737] |
| Allocation Date | January 2010 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+----------------------------+
Table 13: TEST-NET-2
+----------------------+----------------------------+
| Attribute | Value |
+----------------------+----------------------------+
| Address Block | 203.0.113.0/24 |
| Name | Documentation (TEST-NET-3) |
| RFC | [RFC5737] |
| Allocation Date | January 2010 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+----------------------------+
Table 14: TEST-NET-3
Cotton, et al. Best Current Practice [Page 12]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+----------------------+
| Attribute | Value |
+----------------------+----------------------+
| Address Block | 240.0.0.0/4 |
| Name | Reserved |
| RFC | [RFC1112], Section 4 |
| Allocation Date | August 1989 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | True |
+----------------------+----------------------+
Table 15: Reserved for Future Use
+----------------------+----------------------+
| Attribute | Value |
+----------------------+----------------------+
| Address Block | 255.255.255.255/32 |
| Name | Limited Broadcast |
| RFC | [RFC919], Section 7 |
| Allocation Date | October 1984 |
| Termination Date | N/A |
| Source | False |
| Destination | True |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+----------------------+
Table 16: Limited Broadcast
Cotton, et al. Best Current Practice [Page 13]
RFC 6890 Special-Purpose Address Registries April 2013
2.2.3. IPv6 Special-Purpose Address Registry Entries
Tables 17 through 28, below, represent entries with which the IANA
has initially populated the IPv6 Special-Purpose Address Registry.
+----------------------+------------------+
| Attribute | Value |
+----------------------+------------------+
| Address Block | ::1/128 |
| Name | Loopback Address |
| RFC | [RFC4291] |
| Allocation Date | February 2006 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | True |
+----------------------+------------------+
Table 17: Loopback Address
+----------------------+---------------------+
| Attribute | Value |
+----------------------+---------------------+
| Address Block | ::/128 |
| Name | Unspecified Address |
| RFC | [RFC4291] |
| Allocation Date | February 2006 |
| Termination Date | N/A |
| Source | True |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | True |
+----------------------+---------------------+
Table 18: Unspecified Address
Cotton, et al. Best Current Practice [Page 14]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+---------------------+
| Attribute | Value |
+----------------------+---------------------+
| Address Block | 64:ff9b::/96 |
| Name | IPv4-IPv6 Translat. |
| RFC | [RFC6052] |
| Allocation Date | October 2010 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | True |
| Reserved-by-Protocol | False |
+----------------------+---------------------+
Table 19: IPv4-IPv6 Translation Address
+----------------------+---------------------+
| Attribute | Value |
+----------------------+---------------------+
| Address Block | ::ffff:0:0/96 |
| Name | IPv4-mapped Address |
| RFC | [RFC4291] |
| Allocation Date | February 2006 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | True |
+----------------------+---------------------+
Table 20: IPv4-Mapped Address
Cotton, et al. Best Current Practice [Page 15]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+----------------------------+
| Attribute | Value |
+----------------------+----------------------------+
| Address Block | 100::/64 |
| Name | Discard-Only Address Block |
| RFC | [RFC6666] |
| Allocation Date | June 2012 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+----------------------------+
Table 21: Discard-Only Prefix
+----------------------+---------------------------+
| Attribute | Value |
+----------------------+---------------------------+
| Address Block | 2001::/23 |
| Name | IETF Protocol Assignments |
| RFC | [RFC2928] |
| Allocation Date | September 2000 |
| Termination Date | N/A |
| Source | False[1] |
| Destination | False[1] |
| Forwardable | False[1] |
| Global | False[1] |
| Reserved-by-Protocol | False |
+----------------------+---------------------------+
[1] Unless allowed by a more specific allocation.
Table 22: IETF Protocol Assignments
Cotton, et al. Best Current Practice [Page 16]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block | 2001::/32 |
| Name | TEREDO |
| RFC | [RFC4380] |
| Allocation Date | January 2006 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+----------------+
Table 23: TEREDO
+----------------------+----------------+
| Attribute | Value |
+----------------------+----------------+
| Address Block | 2001:2::/48 |
| Name | Benchmarking |
| RFC | [RFC5180] |
| Allocation Date | April 2008 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+----------------+
Table 24: Benchmarking
Cotton, et al. Best Current Practice [Page 17]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+---------------+
| Attribute | Value |
+----------------------+---------------+
| Address Block | 2001:db8::/32 |
| Name | Documentation |
| RFC | [RFC3849] |
| Allocation Date | July 2004 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+---------------+
Table 25: Documentation
+----------------------+--------------+
| Attribute | Value |
+----------------------+--------------+
| Address Block | 2001:10::/28 |
| Name | ORCHID |
| RFC | [RFC4843] |
| Allocation Date | March 2007 |
| Termination Date | March 2014 |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+--------------+
Table 26: ORCHID
Cotton, et al. Best Current Practice [Page 18]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+---------------+
| Attribute | Value |
+----------------------+---------------+
| Address Block | 2002::/16 [2] |
| Name | 6to4 |
| RFC | [RFC3056] |
| Allocation Date | February 2001 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | N/A [2] |
| Reserved-by-Protocol | False |
+----------------------+---------------+
[2] See [RFC3056] for details.
Table 27: 6to4
+----------------------+--------------+
| Attribute | Value |
+----------------------+--------------+
| Address Block | fc00::/7 |
| Name | Unique-Local |
| RFC | [RFC4193] |
| Allocation Date | October 2005 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | True |
| Global | False |
| Reserved-by-Protocol | False |
+----------------------+--------------+
Table 28: Unique-Local
Cotton, et al. Best Current Practice [Page 19]
RFC 6890 Special-Purpose Address Registries April 2013
+----------------------+-----------------------+
| Attribute | Value |
+----------------------+-----------------------+
| Address Block | fe80::/10 |
| Name | Linked-Scoped Unicast |
| RFC | [RFC4291] |
| Allocation Date | February 2006 |
| Termination Date | N/A |
| Source | True |
| Destination | True |
| Forwardable | False |
| Global | False |
| Reserved-by-Protocol | True |
+----------------------+-----------------------+
Table 29: Linked-Scoped Unicast
3. Security Considerations
Security of the Internet's routing system relies on the ability to
authenticate an assertion of unique control of an address block.
Measures to authenticate such assertions rely on validation that the
address block forms part of an existing allocated address block and
that there is a trustable and unique reference in the IANA address
registries.
The proposed registry is intended to provide an authoritative source
of information regarding the currency and intended purpose of special
purpose address blocks that are designated from the IANA-administered
Special-Purpose registry. This is a small step towards the creation
of a comprehensive registry framework that can be used as a trust
point for commencing a chain of address validation. Consideration
should be given to IANA registry publication formats that are machine
parsable. Additionally, consideration should be given to the use of
file signatures and associated certificate mechanisms to allow
applications to confirm that the registry contents are current and
that they have been published by the IANA.
4. Acknowledgements
The authors thank Geoff Huston and Randy Bush for their helpful
comments. The authors also express their gratitude to an anonymous
donor, without whom this document would not have been written.
5. Informative References
[RFC919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC
919, October 1984.
Cotton, et al. Best Current Practice [Page 20]
RFC 6890 Special-Purpose Address Registries April 2013
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC2928] Hinden, R., Deering, S., Fink, R., and T. Hain, "Initial
IPv6 Sub-TLA ID Assignments", RFC 2928, September 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, February
2006.
Cotton, et al. Best Current Practice [Page 21]
RFC 6890 Special-Purpose Address Registries April 2013
[RFC4773] Huston, G., "Administration of the IANA Special Purpose
IPv6 Address Block", RFC 4773, December 2006.
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)", RFC 4843, April 2007.
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
April 2008.
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D.
Dugatkin, "IPv6 Benchmarking Methodology for Network
Interconnect Devices", RFC 5180, May 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
RFC 5735, January 2010.
[RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special
Purpose Address Registry", RFC 5736, January 2010.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, January 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", BCP 153, RFC 6598, April 2012.
[RFC6666] Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6",
RFC 6666, August 2012.
Cotton, et al. Best Current Practice [Page 22]
RFC 6890 Special-Purpose Address Registries April 2013 Authors' Addresses Michelle Cotton Internet Corporation for Assigned Names and Numbers (ICANN) 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 USA Phone: +310-823-9358 EMail: michelle.cotton@icann.org URI: http://www.icann.org/ Leo Vegoda Internet Corporation for Assigned Names and Numbers (ICANN) 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 USA Phone: +310-823-9358 EMail: leo.vegoda@icann.org URI: http://www.icann.org/ Ronald P Bonica (editor) Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 USA EMail: rbonica@juniper.net Brian Haberman Johns Hopkins University (JHU) Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA EMail: brian@innovationslab.net Cotton, et al. Best Current Practice [Page 23]
Internet Engineering Task Force (IETF) R. Bonica
Request for Comments: 8190 Juniper Networks
BCP: 153 M. Cotton
Updates: 6890 PTI
Category: Best Current Practice B. Haberman
ISSN: 2070-1721 Johns Hopkins University
L. Vegoda
ICANN
June 2017
Updates to the Special-Purpose IP Address Registries
Abstract
This memo updates the IANA IPv4 and IPv6 Special-Purpose Address
Registries to address issues raised by the definition of a "global"
prefix. It also corrects several errors in registry entries to
ensure the integrity of the IANA Special-Purpose Address Registries.
This memo updates RFC 6890.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(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 7841.
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/rfc8190.
Bonica, et al. Best Current Practice [Page 1]
RFC 8190 Special-Purpose Address Registries June 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definition of Globally Reachable . . . . . . . . . . . . 3
2.2. Updates to the IPv4 Special-Purpose Address Registry . . 4
2.3. Updates to the IPv6 Special-Purpose Address Registry . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Normative References . . . . . . . . . . . . . . . . . . 5
4.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
Bonica, et al. Best Current Practice [Page 2]
RFC 8190 Special-Purpose Address Registries June 2017
1. Introduction
In order to support new protocols and practices, the IETF
occasionally reserves an address block for a special purpose. For
example, [RFC1122] reserves an IPv4 address block (0.0.0.0/8) to
represent the local (i.e., "this") network. Likewise, [RFC4291]
reserves an IPv6 address block (fe80::/10) for link-local unicast
addresses.
Several issues have been raised with the documentation of some of the
special-purpose address blocks in [RFC6890]. Specifically, the
definition of "global" provided in [RFC6890] was misleading as it
slightly differed from the generally accepted definition of "global
scope" (i.e., the ability to forward beyond the boundaries of an
administrative domain, described as "global unicast" in the IPv6
addressing architecture [RFC4291]).
This memo updates the definition of "global" from [RFC6890] for the
IPv4 and IPv6 Special-Purpose Address Registries, augments the fields
contained within the registries in order to address the confusion
raised by the definition of "global", and corrects some errors in
some of the entries in the Special-Purpose Address Registries.
This memo updates [RFC6890].
2. IANA Considerations
2.1. Definition of Globally Reachable
[RFC6890] defined the term "global" without taking into consideration
the multiple uses of the term. Specifically, IP addresses can be
global in terms of allocation scope as well as global in terms of
routing/reachability. To address this ambiguity, the use of the term
"global" defined in [RFC6890] is replaced with "globally reachable".
The following definition replaces the definition of "global" in the
IANA Special-Purpose Address Registries:
o Globally Reachable - A boolean value indicating whether an IP
datagram whose destination address is drawn from the allocated
special-purpose address block is forwardable beyond a specified
administrative domain.
The same relationship between the value of "Destination" and the
values of "Forwardable" and "Global" described in [RFC6890] holds for
"Globally Reachable". If the value of "Destination" is FALSE, the
values of "Forwardable" and "Globally Reachable" must also be FALSE.
Bonica, et al. Best Current Practice [Page 3]
RFC 8190 Special-Purpose Address Registries June 2017
The "Global" columns in the IPv4 Special-Purpose Address Registry
(https://www.iana.org/assignments/iana-ipv4-special-registry) and the
IPv6 Special-Purpose Address Registry
(https://www.iana.org/assignments/iana-ipv6-special-registry) have
been renamed to "Globally Reachable".
2.2. Updates to the IPv4 Special-Purpose Address Registry
o Limited Broadcast prefix (255.255.255.255/32) - The Reserved-by-
Protocol value has changed from False to True. This change was
made to align the registry with reservation of the limited
broadcast address with Section 7 of [RFC919].
2.3. Updates to the IPv6 Special-Purpose Address Registry
The following changes to the "IPv6 Special-Purpose Address Registry"
involved the insertion of two new footnotes. These additions
required that the footnotes be renumbered.
o TEREDO prefix (2001::/32) - The Globally Reachable value has
changed from False to "N/A [2]". The [2] footnote now states:
* See Section 5 of [RFC4380] for details.
o EID Space for LISP (2001:5::/32) - All footnotes have been
incremented by 1.
o 6to4 (2002::/16) - All footnotes have been incremented by 1.
o Unique-Local (fc00::/7) - The Globally Reachable value has changed
from False to "False [7]". The [7] footnote now states:
* See [RFC4193] for more details on the routability of Unique-
Local addresses. The Unique-Local prefix is drawn from the
IPv6 Global Unicast Address range but is specified as not
globally routed.
3. Security Considerations
This document does not raise any security issues beyond those
discussed in [RFC6890].
Bonica, et al. Best Current Practice [Page 4]
RFC 8190 Special-Purpose Address Registries June 2017
4. References
4.1. Normative References
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<http://www.rfc-editor.org/info/rfc6890>.
4.2. Informative References
[RFC919] Mogul, J., "Broadcasting Internet Datagrams", STD 5,
RFC 919, DOI 10.17487/RFC919, October 1984,
<http://www.rfc-editor.org/info/rfc919>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>.
Acknowledgements
Brian Carpenter and C.M. Heard provided useful comments on initial
draft versions of this document. Daniel Migault provided an in-depth
review that helped strengthen the text within the document. Amanda
Baber and Sabrina Tanamal asked questions which resulted in the
authors simplifying the document.
Bonica, et al. Best Current Practice [Page 5]
RFC 8190 Special-Purpose Address Registries June 2017 Authors' Addresses Ronald Bonica Juniper Networks Email: rbonica@juniper.net Michelle Cotton PTI, an affiliate of ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Phone: +1-424-254-5300 Email: michelle.cotton@iana.org Brian Haberman Johns Hopkins University Email: brian@innovationslab.net Leo Vegoda ICANN Email: leo.vegoda@icann.org Bonica, et al. Best Current Practice [Page 6]