RFC 6890
Special-Purpose IP Address Registries
RFC 6890: Special-Purpose IP Address Registries ✨
okay bestie, let's get into it 🎀 RFC 6890 is a Best Current Practice (it's BCP 153 🫶) from the IETF, published in April 2013. It's titled Special-Purpose IP Address Registries and has ISSN 2070-1721. The main authors are M. Cotton and L. Vegoda from ICANN, plus R. Bonica (Ed.) from Juniper Networks and B. Haberman from JHU. It obsoletes RFCs 4773, 5156, 5735, and 5736, and the header doesn't list any RFCs it updates 💅
Abstract
this memo basically re-confirms that the IPv4 block 192.0.0.0/24 belongs to IANA 🦋 It also tells IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Once that's done, the registries will record all special-purpose address blocks, and each block gets the same set of info 💜
This memo obsoletes RFCs 4773, 5156, 5735, and 5736.
Status of This Memo
This memo documents an Internet Best Current Practice.
this doc is an IETF product 🌸 It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on BCPs, check Section 2 of RFC 5741 ✨
Info about the current status of this document, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc6890.
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) as they were on the publication date. Please read these carefully, because they spell out your rights and restrictions 🙈 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes.
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 .........................................201. Introduction 🧚
okay so the IETF sometimes reserves an address block for a special purpose, so new protocols and practices can use it 💖 For example, [RFC1122] reserves the IPv4 block 0.0.0.0/8 to mean the local ("this") network. Likewise, [RFC4291] reserves the IPv6 block fe80::/10 for link-scoped unicast addresses. literally so iconic 😭
Every so often the IETF publishes an RFC that catalogs these special-purpose blocks. Right now, [RFC5735] catalogs all the IPv4 ones and [RFC5156] catalogs all the IPv6 ones 🍓
[RFC5736] assigns the IPv4 block 192.0.0.0/24 to IANA and tells IANA to hand out special-purpose blocks from inside that space. It also tells IANA to create an IPv4 Special-Purpose Address Registry that records allocations from that space. BUT, and this is the tea ☕, [RFC5736] does not tell IANA to record special-purpose reservations that live outside that block in the IPv4 registry.
same energy with IPv6 🌈 [RFC2928] assigns the IPv6 block 2001:0000::/23 to IANA and tells IANA to allocate special-purpose blocks from it. [RFC4773] tells IANA to create an IPv6 Special-Purpose Address Registry for allocations from that space. Again, [RFC4773] does not tell IANA to record reservations from outside that block in the IPv6 registry 🙄
This memo is the glow-up 👑 It re-confirms the assignment of the IPv4 block 192.0.0.0/24 to IANA and tells IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Specifically, IANA has to record all special-purpose address blocks in those registries. That includes, but isn't limited to, IPv4 allocations from 192.0.0.0/24 and IPv6 allocations from 2001:0000::/23. This memo also defines two things:
- a common set of information that the registries will maintain for each special-purpose address block
- a common set of requirements for future entries
once the registries cover every special-purpose block, [RFC5735] and [RFC5156] are basically redundant 💀 So this memo obsoletes [RFC5735] and [RFC5156]. Because it re-confirms the 192.0.0.0/24 assignment to IANA and restructures the IPv4 Special-Purpose Address Registry, it also obsoletes [RFC5736]. And because it restructures the IPv6 Special-Purpose Address Registry, it obsoletes [RFC4773] too 💅
2. IANA Considerations 🎀
2.1. Assignment of an IPv4 Address Block to IANA
Table 7 of this document records the assignment of the IPv4 address block 192.0.0.0/24 to IANA for IETF protocol assignments 🌸 That allocation is meant to support those IETF protocol assignments. A broader look at IANA's roles in address allocation is documented in Sections 4.1 and 4.3 [RFC2860].
IANA has designated special-purpose address blocks in compliance with [RFC2860] 🫶
2.2. Restructuring of the IPv4 and IPv6 Special-Purpose Address Registries
IANA has restructured these two registries:
- IPv4 Special-Purpose Address Registry
- IPv6 Special-Purpose Address Registry
the IPv4 registry records all IPv4 special-purpose address blocks 🦋 Those reservations include, but aren't limited to, allocations from the 192.0.0.0/24 block. the IPv6 registry does the same for IPv6, and that includes, but isn't limited to, allocations from 2001:0000::/23 ✨
Section 2.2.1 of this document describes the info both registries will maintain for each entry. At first, IANA filled the IPv4 registry with the info from Section 2.2.2 of this document, and the IPv6 registry with the info from Section 2.2.3 🧚
IANA will update these registries when asked 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 keep the following info about each entry:
- Address Block - A block of IPv4 or IPv6 addresses that has been registered for a special purpose.
- Name - A descriptive name for the special-purpose address block.
- RFC - The RFC through which the special-purpose address block was requested.
- Allocation Date - The date upon which the special-purpose address block was allocated.
- Termination Date - The date upon which the allocation is to be terminated. This field only applies to limited-use allocations.
- Source - A boolean value saying whether an address from the allocated block is valid when used as the source address of an IP datagram that transits two devices.
- Destination - A boolean value saying whether an address from the allocated block is valid when used as the destination address of an IP datagram that transits two devices.
- Forwardable - A boolean value saying whether a router may forward an IP datagram whose destination address comes from the allocated block between external interfaces.
- Global - A boolean value saying whether an IP datagram whose destination address comes from the allocated block can be forwarded beyond a specified administrative domain.
- Reserved-by-Protocol - A boolean value saying whether IP itself reserves the block. This value is "TRUE" if the RFC that created the block requires all compliant IP implementations to behave in a special way when processing packets to or from addresses in that block.
If the value of "Destination" is FALSE, the values of "Forwardable" and "Global" must also be false. this one's a rule, bestie, don't skip it 🙈
2.2.2. IPv4 Special-Purpose Address Registry Entries
Tables 1 though 16, below, show the entries IANA first used to fill up 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 Networksokay that's Tables 1 and 2 for now, the IPv4 entry list keeps going in the next part 🦋 stay tuned, we're just getting started 💖
Okay bestie, the registry table party has officially started 🎀✨ Each block below is one special-purpose block, with its own little attribute card: the address block, its name, which RFC it comes from, when it was allocated, and whether it's Source, Destination, Forwardable, Global, or Reserved-by-Protocol 💅
Shared Address Space comes first 🦋
+----------------------+----------------------+
| 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 SpaceNext up is Loopback, and this one is giving drama 😭 Its Source, Destination, Forwardable, and Global are all False [1], and there's a footnote with exceptions 👀
+----------------------+----------------------------+
| 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: LoopbackThen we've got Link Local 🧚 This one has Forwardable as False, and it's Reserved-by-Protocol as True 🌸
+----------------------+----------------+
| 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 LocalNow for Private-Use 172.16. It's a classic and honestly iconic 🍓
+----------------------+---------------+
| 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 NetworksIETF Protocol Assignments is next, and it's the one with the footnote saying [2] is not usable unless by virtue of a more specific reservation 🙈 Everything in its attribute card is False, and the RFC column points back to Section 2.1 of this document 📜
+----------------------+---------------------------------+
| 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 AssignmentsOkay, the DS-Lite block is a smaller slice at 192.0.0.0/29, and it's Source, Destination, and Forwardable all True 💖
+----------------------+--------------------------------+
| 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-LiteTEST-NET-1 is documentation space, so every flag is False 📚
+----------------------+----------------------------+
| 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-1Next is 6to4 Relay Anycast 🌈 This is the one where Global is True, so it's the main character of this section 👑
+----------------------+--------------------+
| 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 AnycastBack to Private-Use networks, this time 192.168.0.0/16 💅
+----------------------+----------------+
| 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 NetworksNow Benchmarking at 198.18.0.0/15, which is for Network Interconnect Device Benchmark Testing 🧪✨
+----------------------+---------------+
| 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 TestingThen the documentation blocks continue with TEST-NET-2 at 198.51.100.0/24, where every flag is False again 🦋
+----------------------+----------------------------+
| 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-2And last but not least, TEST-NET-3 at 203.0.113.0/24, same vibe, all False 🫶
+----------------------+----------------------------+
| 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 +----------------------+----------------------+
| 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 | [RFC0919], 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 Broadcast2.2.3. IPv6 Special-Purpose Address Registry Entries ✨
Okay, the IPv6 table party 🎀
Okay bestie, so this is where the IANA populates the IPv6 Special-Purpose Address Registry. Tables 17 through 28 are the initial entries, and I'm already obsessed with how many of these are just the reserved vibes 💅 Let's go through them!
+----------------------+------------------+
| 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
+----------------------+---------------------+
| 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
+----------------------+----------------------------+
| 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
+----------------------+----------------+
| 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
+----------------------+---------------+
| 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: ORCHIDOkay bestie, picking up right where the tables left off 💅🎀
+----------------------+---------------+
| 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
+----------------------+-----------------------+
| 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 is the whole vibe here, so pay attention 😭 The Internet's routing system depends on being able to authenticate someone's claim that they uniquely control an address block. The ways we check those claims rely on confirming that the block is part of an address block that's already allocated, and that there's a trustworthy, unique reference for it in the IANA address registries. 🧚
The proposed registry is meant to be an authoritative place to look up whether a special-purpose address block is current and what it's actually for, for any block designated from the IANA-administered Special-Purpose registry. It's a small step toward a bigger registry framework that can work as a trust point to start a chain of address validation. ✨ Consideration should be given to IANA registry publication formats that are machine parsable. Consideration should also be given to file signatures and the certificate mechanisms that go with them, so applications can confirm that the registry contents are current and were actually published by the IANA. Verify your sources, periodt 💅
4. Acknowledgements 🫶
The authors thank Geoff Huston and Randy Bush for their helpful comments. 💜 The authors also send major gratitude to an anonymous donor, without whom this document would literally not have been written 😭🌈
5. Informative References 📚
[RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC
919, October 1984.
[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.
[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.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.netThat's the whole RFC, bestie 🌈🦋👑
📦 where this page comes from
- ietf: rfc6890 2013-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms