RFC 2471

IPv6 Testing Address Allocation

📅 published December 1998, from ietf

RFC 2471: IPv6 Testing Address Allocation 🎀

okay bestie, here's the deal ✨ this RFC is an Experimental doc (so it's not an Internet standard, just a "hey, try this out and tell us what you think" kinda vibe 🧪). It came out in December 1998 and was written by R. Hinden (Nokia), R. Fink (LBNL), and J. Postel (ISI). It obsoletes RFC 1897 (which is getting retired to historic status) and doesn't update anything else 💜

1.0 Introduction 🦋

so this doc is basically an allocation plan for IPv6 addresses that people use when they're testing IPv6 prototype software 🧑‍💻 these addresses are temporary and will be reclaimed later on, so any IPv6 system using them will have to renumber at some point in the future 🫠 they will not to be routable on the Internet other than for IPv6 testing, so don't get it twisted 🙅‍♀️

the address format is consistent with the "Aggregatable Global Unicast Address Allocation" [AGGR] and "TLA and NLA Assignment Rules" [TLAASN] docs, which is giving a whole ecosystem vibe 🌈

this document is meant to replace RFC 1897 "IPv6 Testing Address Allocation", January 1996, and RFC 1897 will become historic 📜

the addresses here line up with the IPv6 Addressing Architecture [ARCH] 💅 they can be given to nodes manually, with IPv6 Auto Address Allocation [AUTO], or with DHCP for IPv6 [DHCPv6] ✨

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 [RFC2119] 🫶 these are the BCP 14 key words, so they're really important and you gotta read them as written 🔥

2.0 Address Format 🍓

the Aggregatable Global Unicast Address Allocation format from [AGGR] looks like this 👑

   | 3 |  13 |    32     |   16   |          64 bits               |
   +---+-----+-----------+--------+--------------------------------+
   |FP | TLA | NLA ID    | SLA ID |         Interface ID           |
   |   | ID  |           |        |                                |
   +---+-----+-----------+--------+--------------------------------+

here's the breakdown, bestie 🧚

  • FP = 001 = Format Prefix: this is the Format Prefix used to identify aggregatable global unicast addresses 💖
  • TLA = 0x1FFE = Top-Level Aggregation Identifier: this is a TLA ID assigned by the IANA for 6bone testing under the auspices of the IETF IPng Transition Working Group 6bone testbed activity 🌸 it's to be administered by the chair of the 6bone activity (currently Bob Fink <rlfink@lbl.gov>) 🦋 the use of this TLA ID is temporary, and all users of these addresses in this TLA ID will be required to renumber at some time in the future 😭
  • NLA ID = Next-Level Aggregation Identifier: the NLA ID space gets assigned by the TLA ID administrator in an addressing hierarchy that's sufficient to identify transit networks and end user sites, consistent with the architecture and topology of the 6bone 🌐 this gives you a multi-level transit service that matches the 6bone goal of fully testing IPv6 in real use environments 🔥
  • SLA ID = Site-Level Aggregation Identifier: the SLA ID field is used by an individual organization to make its own local addressing hierarchy and to identify subnets 🏠 assigning this field is the responsibility of each individual organization 🫶
  • Interface ID: this is the interface identifier of the interface on the link, as defined in the appropriate IPv6 over <link> document, such as [ETHER], [FDDI], etc. 🧩

4.0 References 📚

  • [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
  • [AGGR] Hinden, R., Deering, S., O'Dell, M., "An Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
  • [AUTO] Thompson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971, August 1996.
  • [DHCP6] Bound, J., "Host Configuration Protocol for IPv6", Work in Progress.
  • [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
  • [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, December 1998.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [TLAASN] Hinden, R., "TLA and NLA Assignment Rules", Work in Progress.

5.0 Security Considerations 🔐

okay this one's serious, bestie 😤 this document defines a test approach for creating aggregatable addresses consistent with [AGGR] 🧪 it does not have any direct impact on Internet infrastructure security 🛡️ authentication of IPv6 packets is defined in [AUTH] 🔑

6.0 Authors' Addresses 💌

the authors' contact info, as given in the original 🫶

   Robert M. Hinden
   Nokia
   232 Java Drive
   Sunnyvale, CA 94089
   USA

   Phone: +1 408 990-2004
   EMail: hinden@iprg.nokia.com


   Robert Fink
   Lawrence Berkeley National Laboratory
   MS 50A-3111
   Berkeley, CA 94720
   USA

   Phone: +1 510 486-5692
   EMail: rlfink@lbl.gov


   Jon Postel (Deceased)
   Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292-6695
   USA

Copyright (C) The Internet Society (1998). All Rights Reserved. 🌈

this document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. however, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 💜

the limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ✨

this document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🫠

📦 where this page comes from