RFC 2526

Reserved IPv6 Subnet Anycast Addresses

πŸ“… published March 1999, from ietf

RFC 2526 πŸŽ€ Reserved IPv6 Subnet Anycast Addresses

okay bestie, this one is RFC 2526, "Reserved IPv6 Subnet Anycast Addresses" πŸ’– It's a Standards Track doc from March 1999, written by D. Johnson of Carnegie Mellon University and S. Deering of Cisco Systems, Inc. 🧚 The title block doesn't list any RFCs it obsoletes or updates, so it's doing its own thing ✨

Status of This Memo πŸ“‹

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements πŸ’¬ For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (1999). All Rights Reserved. πŸ’œ

Abstract ✨

So the IP Version 6 addressing architecture defines an "anycast" address, which is an IPv6 address given to one or more network interfaces (usually on different nodes) πŸ¦‹ The fun part is that a packet sent to an anycast address gets routed to the "nearest" interface that has that address, based on the routing protocols' measure of distance πŸ—ΊοΈ This doc defines a set of reserved anycast addresses inside each subnet prefix, and it lists the initial allocation of those reserved subnet anycast addresses πŸ’…

1. Introduction 🌸

IPv6 introduces a new kind of address, the "anycast" address, which lets a packet get routed to one of several different nodes that all answer to the same address [2, 3] 🧚 The anycast address can be assigned to one or more network interfaces (usually on different nodes), and the network delivers each packet sent to it to the "nearest" interface, where "nearest" depends on the "distance" the routing protocols in use work out πŸ—ΊοΈ

Anycast is still an evolving thing, but these addresses have real potential for useful services [5, 6] πŸ”₯ For example, an anycast address can let nodes reach one of a group of servers offering a well-known service, without every node needing a manually configured list of those servers 🫢 Or an anycast address can be used in a source route to push traffic through a specific internet service provider, without tying the routing to one specific router that gets you into that ISP πŸ‘‘

IPv6 already defines a required Subnet-Router anycast address [3] for all routers within a subnet prefix, and it lets extra anycast addresses come from the unicast address space πŸ’– This document adds another set of reserved anycast addresses inside each subnet prefix, and lists the initial allocation of those reserved subnet anycast addresses πŸŽ€

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 [1] πŸ“š

2. Format of Reserved Subnet Anycast Addresses πŸ“

Within each subnet, the highest 128 interface identifier values are reserved for assignment as subnet anycast addresses πŸ¦‹

How you build a reserved subnet anycast address depends on the type of IPv6 address used in the subnet, which you can tell from the format prefix in the address πŸ‘€ The big one: for IPv6 address types that are required to have 64-bit interface identifiers in EUI-64 format, the universal/local bit MUST be set to 0 (local) in all reserved subnet anycast addresses. That tells everyone the interface identifier isn't globally unique πŸ™ˆ Address types like this currently have format prefixes 001 through 111, except for Multicast Addresses (1111 1111) [3] 🌈

So, for those EUI-64 types, the reserved subnet anycast addresses get built like this:

|              64 bits            |      57 bits     |   7 bits   |
+---------------------------------+------------------+------------+
|           subnet prefix         | 1111110111...111 | anycast ID |
+---------------------------------+------------------+------------+
                                  |   interface identifier field  |

For every other IPv6 address type (so, format prefixes that aren't listed above), the interface identifier is not in EUI-64 format, and it can be a length other than 64 bits πŸ’… Those reserved subnet anycast addresses are built like this:

|              n bits             |    121-n bits    |   7 bits   |
+---------------------------------+------------------+------------+
|           subnet prefix         | 1111111...111111 | anycast ID |
+---------------------------------+------------------+------------+
                                  |   interface identifier field  |

The subnet prefix here is every field of the IPv6 address except the interface identifier field ✨ The interface identifier field in these reserved subnet anycast addresses is made from a 7-bit anycast identifier ("anycast ID"), and the remaining highest-order bits are filled with all ones. Quick catch though: for interface identifiers in EUI-64 format, the universal/local bit in the interface identifier MUST be set to 0 🫢 The anycast identifier picks out one particular reserved anycast address within the subnet prefix, from the set of reserved subnet anycast addresses 🧚

Why the highest addresses and not the lowest? Because the low-numbered addresses in a subnet are already in use, officially and unofficially πŸ™ƒ They're often used for the ends of a point-to-point link, for tunnel endpoints, for manually configured unicast addresses when a network interface doesn't have a hardware token, and even for manually configured static addresses on routers attached to a link 😭 Reserving only 128 values for anycast identifiers (instead of maybe 256) means the smallest possible interface identifier in an IPv6 address is 8 bits. That leaves room in the subnet for both unicast and reserved subnet anycast addresses, and it keeps the split between subnet prefix and interface identifier byte-aligned in that case πŸ’œ

Just like all IPv6 anycast addresses [3], these reserved subnet anycast addresses come out of the IPv6 unicast address space 🌸 Every reserved subnet anycast address defined in this document is reserved on all links, with all subnet prefixes. They MUST NOT be used for unicast addresses assigned to any interface 🚫 No sneaking them onto a real interface, bestie πŸ’€

3. List of Reserved Subnet Anycast Addresses πŸ‘‘

Right now, these are the anycast identifiers defined for the reserved subnet anycast addresses:

  Decimal   Hexadecimal     Description
  -------   -----------     -----------
   127         7F           Reserved
   126         7E           Mobile IPv6 Home-Agents anycast [4]
   0-125       00-7D        Reserved

More anycast identifiers are expected to get defined in the future πŸ¦‹

Authors' Addresses ✨

Okay bestie, here are the authors' deets, exactly as they were written πŸ“‡πŸ’–

David B. Johnson
Carnegie Mellon University
Computer Science Department
5000 Forbes Avenue
Pittsburgh, PA  15213-3891
USA

Phone:  +1 412 268-7399
Fax:    +1 412 268-5576
EMail:  dbj@cs.cmu.edu


Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA

Phone:  +1 408 527-8213
Fax:    +1 408 527-8254
EMail:  deering@cisco.com

Copyright (C) The Internet Society (1999). All Rights Reserved. πŸ’œ

Okay so the legal stuff, but make it cute πŸ™ˆ

You're allowed to copy this document and share it with others, and you can make derivative works that comment on or explain it or help people implement it. Those can be prepared, copied, published, and distributed, in whole or in part, with no restriction of any kind, as long as the copyright notice and this paragraph are included on all of those copies and derivative works. πŸ¦‹

BUT the document itself can't be modified in any way. That means you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards (in which case the copyright procedures in the Internet Standards process must be followed) or when you're translating it into a language other than English. 🌍

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 🫢 Forever and ever, periodt ✨

Also, this document and everything in it is provided on an "AS IS" basis, and the Internet Society and the Internet Engineering Task Force put it out there with no warranties at all. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. Not gonna lie, that's a lot of disclaimers, but it's the rules πŸ’…

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