idnits 2.17.1 draft-ietf-ipngwg-resv-anycast-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 81: '...versal/local bit MUST be set to 0 (loc...' RFC 2119 keyword, line 115: '... MUST be set to 0. The anycast iden...' RFC 2119 keyword, line 137: '...all subnet prefixes. They MUST NOT be...' RFC 2119 keyword, line 200: '...ned. Such anycast identifiers MUST be...' RFC 2119 keyword, line 203: '... SHOULD be assigned in descending nu...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (17 October 1998) is 9321 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-ipv6-spec-v2 is -01, but you're referring to -02. ** Obsolete normative reference: RFC 2373 (ref. '2') (Obsoleted by RFC 3513) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-06 -- No information found for draft-ietf-iab-case-for-ipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. '5') Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF IPng Working Group David B. Johnson 3 INTERNET-DRAFT Carnegie Mellon University 4 Stephen E. Deering 5 Cisco Systems, Inc. 6 17 October 1998 8 Reserved IPv6 Subnet Anycast Addresses 10 12 Status of This Memo 14 This document is a submission by the IPng Working Group of the 15 Internet Engineering Task Force (IETF). Comments should be submitted 16 to the Working Group mailing list at "ipng@sunroof.Eng.Sun.COM". 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 To view the entire list of current Internet-Drafts, please check 30 the "1id-abstracts.txt" listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 Abstract 37 The IP Version 6 addressing architecture defines an "anycast" address 38 as an IPv6 address that is assigned to one or more network interfaces 39 (typically belonging to different nodes), with the property that 40 a packet sent to an anycast address is routed to the "nearest" 41 interface having that address, according to the routing protocols' 42 measure of distance. This document defines a set of reserved anycast 43 addresses within each subnet prefix, and lists the initial allocation 44 of these reserved subnet anycast addresses. 46 1. Introduction 48 IP Version 6 (IPv6) defines a new type of address, known as an 49 "anycast" address, that allows a packet to be routed to one of a 50 number of different nodes all responding to the same address [1, 2]. 51 The anycast address may be assigned to one or more network interfaces 52 (typically on different nodes), with the network delivering packets 53 addressed to this address to the "nearest" interface based on the 54 notion of "distance" determined by the routing protocols in use. 56 The uses of anycast addresses are still evolving, but such addresses 57 offer the potential for a number of important services [4, 5]. For 58 example, an anycast address may be used to allow nodes to access 59 one of a collection of servers providing a well-known service, 60 without manual configuration in each node of the list of servers; or 61 an anycast address may be used in a source route to force routing 62 through a specific internet service provider, without limiting 63 routing to a single specific router providing access to that ISP. 65 IPv6 defines a required Subnet-Router anycast address [2] for 66 all routers within a subnet prefix, and allows additional anycast 67 addresses to be taken from the unicast address space. This document 68 defines an additional set of reserved anycast addresses within each 69 subnet prefix, and lists the initial allocation of these reserved 70 subnet anycast addresses. 72 2. Format of Reserved Subnet Anycast Addresses 74 Within each subnet, the highest 128 interface identifier values are 75 reserved for assignment as subnet anycast addresses. 77 The construction of a reserved subnet anycast address depends on 78 the type of IPv6 addresses used within the subnet, as indicated 79 by the format prefix in the addresses. In particular, for IPv6 80 address types required to have to have 64-bit interface identifiers 81 in EUI-64 format, the universal/local bit MUST be set to 0 (local) 82 in all reserved subnet anycast addresses, to indicate that the 83 interface identifier in the address is not globally unique. IPv6 84 addresses of this type are currently specified to be those having 85 format prefixes 001 through 111, except for Multicast Addresses 86 (1111 1111) [2]. 88 Specifically, for IPv6 address types required to have to have 64-bit 89 interface identifiers in EUI-64 format, these reserved subnet anycast 90 addresses are constructed as follows: 92 | 64 bits | 57 bits | 7 bits | 93 +---------------------------------+------------------+------------+ 94 | subnet prefix | 1111110111...111 | anycast ID | 95 +---------------------------------+------------------+------------+ 96 | interface identifier field | 98 For other IPv6 address types (that is, with format prefixes other 99 than those listed above), the interface identifier is not in EUI-64 100 format and may be other than 64 bits in length; these reserved subnet 101 anycast addresses for such address types are constructed as follows: 103 | n bits | 121-n bits | 7 bits | 104 +---------------------------------+------------------+------------+ 105 | subnet prefix | 1111111...111111 | anycast ID | 106 +---------------------------------+------------------+------------+ 107 | interface identifier field | 109 The subnet prefix here consists of all fields of the IPv6 address 110 except the interface identifier field. The interface identifier 111 field in these reserved subnet anycast addresses is formed from a 112 7-bit anycast identifier ("anycast ID"), with the remaining (highest 113 order) bits filled with all one's; however, for interface identifiers 114 in EUI-64 format, the universal/local bit in the interface identifier 115 MUST be set to 0. The anycast identifier identifies a particular 116 reserved anycast address within the subnet prefix, from the set of 117 reserved subnet anycast addresses. 119 The motivation for reserving the highest addresses from each subnet 120 rather than the lowest addresses, is to avoid conflicting with some 121 existing official and unofficial uses of the low-numbered addresses 122 in a subnet. For example, these low-numbered addresses are often 123 used for the ends of a point-to-point link, for tunnel endpoints, for 124 manually configured unicast addresses when a hardware token is not 125 available for the network interface, and even for manually configured 126 static addresses for the routers on a link. Reserving only 128 127 values for anycast identifiers (rather than perhaps 256) means that 128 the minimum possible size of interface identifiers in an IPv6 address 129 is 8 bits (including room in the subnet for unicast addresses as 130 well as reserved subnet anycast addresses), allowing the division 131 between subnet prefix and interface identifier in this case to be 132 byte-aligned. 134 As with all IPv6 anycast addresses [2], these reserved subnet anycast 135 addresses are allocated from the IPv6 unicast address space. All 136 reserved subnet anycast addresses as defined in this document are 137 reserved on all links, with all subnet prefixes. They MUST NOT be 138 used for unicast addresses assigned to any interface. 140 3. List of Reserved Subnet Anycast Addresses 142 Currently, the following anycast identifiers for these reserved 143 subnet anycast addresses are defined: 145 Decimal Hexadecimal Description 146 ------- ----------- ----------- 147 127 7F Reserved 148 126 7E Mobile IPv6 Home-Agents anycast [3] 149 0-125 00-7D Reserved 151 Additional anycast identifiers are expected to be defined in the 152 future. 154 4. Examples 156 To illustrate the construction of reserved subnet anycast addresses, 157 this section details the construction of the reserved Mobile IPv6 158 Home-Agents subnet anycast address [3]. As noted in Section 3, the 159 7-bit anycast identifier for the Mobile IPv6 Home-Agents anycast 160 address is 126 (decimal) or 7E (hexadecimal). 162 For IPv6 addresses containing a format prefix indicating that 163 interface identifiers are required to be 64 bits in length and are 164 required to be in EUI-64 format (currently format prefixes 001 165 through 111, except for 1111 1111 [2]), the reserved Mobile IPv6 166 Home-Agents subnet anycast address consists of the 64-bit subnet 167 prefix followed by the 64-bit interface identifier shown below: 169 |0 1|1 3|3 4|4 6| 170 |0 5|6 1|2 7|8 3| 171 +----------------+----------------+----------------+----------------+ 172 |1111110111111111|1111111111111111|1111111111111111|1111111111111110| 173 +----------------+----------------+----------------+----------------+ 174 ^ ^^^^^^^ 175 +--- universal/local bit anycast identifier ---+-----+ 177 For other IPv6 address types, the interface identifier may be other 178 than 64 bits in length and is not in EUI-64 format. In this example, 179 assume that the length of the interface identifier is 64 bits, 180 to allow clear comparison with the example given above (although 181 interface identifiers of lengths other than 64 bits follow the same 182 general construction of the interface identifier shown here). In 183 this case, the reserved Mobile IPv6 Home-Agents subnet anycast 184 address consists of the 64-bit subnet prefix followed by the 64-bit 185 interface identifier shown below: 187 |0 1|1 3|3 4|4 6| 188 |0 5|6 1|2 7|8 3| 189 +----------------+----------------+----------------+----------------+ 190 |1111111111111111|1111111111111111|1111111111111111|1111111111111110| 191 +----------------+----------------+----------------+----------------+ 192 ^^^^^^^ 193 anycast identifier ---+-----+ 195 5. IANA Considerations 197 This document defines a set of reserved subnet anycast addresses, 198 based on a set of anycast identifiers within each subnet prefix 199 in the IPv6 unicast address space. As future needs arise, new 200 anycast identifiers may be defined. Such anycast identifiers MUST be 201 reserved within all subnet prefixes, and so the assignment of these 202 anycast identifiers requires centralized administration. New values 203 SHOULD be assigned in descending numerical order and are expected to 204 be assigned only with IESG approval. 206 6. Security Considerations 208 The use of any type of reserved anycast addresses poses a security 209 concern only in allowing potential attackers a well-known address to 210 attack. By designating certain services to be located at specific 211 reserved anycast addresses, an attacker may more profitably focus an 212 attack against such a specific service. Any such attack, however, is 213 best dealt with in each service that uses a reserved anycast address. 215 RFC 1546, which originally proposed the idea of anycasting in IP, 216 also points out a number of security considerations with the use of 217 anycasting in general [5]. 219 References 221 [1] Stephen E. Deering and Robert M. Hinden. Internet 222 Protocol version 6 (IPv6) specification. Internet-Draft, 223 draft-ietf-ipngwg-ipv6-spec-v2-02.txt, August 1998. Work in 224 progress. 226 [2] Robert M. Hinden and Stephen E. Deering. IP Version 6 addressing 227 architecture. RFC 2373, July 1998. 229 [3] David B. Johnson and Charles Perkins. Mobility support in IPv6. 230 Internet-Draft, draft-ietf-mobileip-ipv6-06.txt, August 1998. 231 Work in progress. 233 [4] Steve King et al. The case for IPv6. Internet-Draft, 234 draft-ietf-iab-case-for-ipv6-01.txt, March 1998. Work in 235 progress. 237 [5] Craig Partridge, Trevor Mendez, and Walter Milliken. Host 238 anycasting service. RFC 1546, November 1993. 240 Authors' Addresses 242 David B. Johnson Stephen E. Deering 243 Carnegie Mellon University Cisco Systems, Inc. 244 Computer Science Department 170 West Tasman Drive 245 5000 Forbes Avenue San Jose, CA 95134-1706 246 Pittsburgh, PA 15213-3891 USA 247 USA 249 Phone: +1 412 268-7399 Phone: +1 408 527-8213 250 Fax: +1 412 268-5576 Fax: +1 408 527-8254 251 Email: dbj@cs.cmu.edu Email: deering@cisco.com