idnits 2.17.1 draft-ietf-ipngwg-resv-anycast-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (26 January 1999) is 9222 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) ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-07 -- No information found for draft-ietf-iab-case-for-ipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. '6') Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF IPng Working Group David B. Johnson 2 INTERNET-DRAFT Carnegie Mellon University 3 Stephen E. Deering 4 Cisco Systems, Inc. 5 26 January 1999 7 Reserved IPv6 Subnet Anycast Addresses 9 11 Status of This Memo 13 This document is a submission by the IPng Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the Working Group mailing list at "ipng@sunroof.Eng.Sun.COM". 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 Abstract 38 The IP Version 6 addressing architecture defines an "anycast" address 39 as an IPv6 address that is assigned to one or more network interfaces 40 (typically belonging to different nodes), with the property that 41 a packet sent to an anycast address is routed to the "nearest" 42 interface having that address, according to the routing protocols' 43 measure of distance. This document defines a set of reserved anycast 44 addresses within each subnet prefix, and lists the initial allocation 45 of these reserved subnet anycast addresses. 47 1. Introduction 49 IP Version 6 (IPv6) defines a new type of address, known as an 50 "anycast" address, that allows a packet to be routed to one of a 51 number of different nodes all responding to the same address [2, 3]. 52 The anycast address may be assigned to one or more network interfaces 53 (typically on different nodes), with the network delivering packets 54 addressed to this address to the "nearest" interface based on the 55 notion of "distance" determined by the routing protocols in use. 57 The uses of anycast addresses are still evolving, but such addresses 58 offer the potential for a number of important services [5, 6]. For 59 example, an anycast address may be used to allow nodes to access 60 one of a collection of servers providing a well-known service, 61 without manual configuration in each node of the list of servers; or 62 an anycast address may be used in a source route to force routing 63 through a specific internet service provider, without limiting 64 routing to a single specific router providing access to that ISP. 66 IPv6 defines a required Subnet-Router anycast address [3] for 67 all routers within a subnet prefix, and allows additional anycast 68 addresses to be taken from the unicast address space. This document 69 defines an additional set of reserved anycast addresses within each 70 subnet prefix, and lists the initial allocation of these reserved 71 subnet anycast addresses. 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [1]. 77 2. Format of Reserved Subnet Anycast Addresses 79 Within each subnet, the highest 128 interface identifier values are 80 reserved for assignment as subnet anycast addresses. 82 The construction of a reserved subnet anycast address depends on 83 the type of IPv6 addresses used within the subnet, as indicated 84 by the format prefix in the addresses. In particular, for IPv6 85 address types required to have to have 64-bit interface identifiers 86 in EUI-64 format, the universal/local bit MUST be set to 0 (local) 87 in all reserved subnet anycast addresses, to indicate that the 88 interface identifier in the address is not globally unique. IPv6 89 addresses of this type are currently specified to be those having 90 format prefixes 001 through 111, except for Multicast Addresses 91 (1111 1111) [3]. 93 Specifically, for IPv6 address types required to have to have 64-bit 94 interface identifiers in EUI-64 format, these reserved subnet anycast 95 addresses are constructed as follows: 97 | 64 bits | 57 bits | 7 bits | 98 +---------------------------------+------------------+------------+ 99 | subnet prefix | 1111110111...111 | anycast ID | 100 +---------------------------------+------------------+------------+ 101 | interface identifier field | 103 For other IPv6 address types (that is, with format prefixes other 104 than those listed above), the interface identifier is not in EUI-64 105 format and may be other than 64 bits in length; these reserved subnet 106 anycast addresses for such address types are constructed as follows: 108 | n bits | 121-n bits | 7 bits | 109 +---------------------------------+------------------+------------+ 110 | subnet prefix | 1111111...111111 | anycast ID | 111 +---------------------------------+------------------+------------+ 112 | interface identifier field | 114 The subnet prefix here consists of all fields of the IPv6 address 115 except the interface identifier field. The interface identifier 116 field in these reserved subnet anycast addresses is formed from a 117 7-bit anycast identifier ("anycast ID"), with the remaining (highest 118 order) bits filled with all one's; however, for interface identifiers 119 in EUI-64 format, the universal/local bit in the interface identifier 120 MUST be set to 0. The anycast identifier identifies a particular 121 reserved anycast address within the subnet prefix, from the set of 122 reserved subnet anycast addresses. 124 The motivation for reserving the highest addresses from each subnet 125 rather than the lowest addresses, is to avoid conflicting with some 126 existing official and unofficial uses of the low-numbered addresses 127 in a subnet. For example, these low-numbered addresses are often 128 used for the ends of a point-to-point link, for tunnel endpoints, for 129 manually configured unicast addresses when a hardware token is not 130 available for the network interface, and even for manually configured 131 static addresses for the routers on a link. Reserving only 128 132 values for anycast identifiers (rather than perhaps 256) means that 133 the minimum possible size of interface identifiers in an IPv6 address 134 is 8 bits (including room in the subnet for unicast addresses as 135 well as reserved subnet anycast addresses), allowing the division 136 between subnet prefix and interface identifier in this case to be 137 byte-aligned. 139 As with all IPv6 anycast addresses [3], these reserved subnet anycast 140 addresses are allocated from the IPv6 unicast address space. All 141 reserved subnet anycast addresses as defined in this document are 142 reserved on all links, with all subnet prefixes. They MUST NOT be 143 used for unicast addresses assigned to any interface. 145 3. List of Reserved Subnet Anycast Addresses 147 Currently, the following anycast identifiers for these reserved 148 subnet anycast addresses are defined: 150 Decimal Hexadecimal Description 151 ------- ----------- ----------- 152 127 7F Reserved 153 126 7E Mobile IPv6 Home-Agents anycast [4] 154 0-125 00-7D Reserved 156 Additional anycast identifiers are expected to be defined in the 157 future. 159 4. Examples 161 To illustrate the construction of reserved subnet anycast addresses, 162 this section details the construction of the reserved Mobile IPv6 163 Home-Agents subnet anycast address [4]. As noted in Section 3, the 164 7-bit anycast identifier for the Mobile IPv6 Home-Agents anycast 165 address is 126 (decimal) or 7E (hexadecimal). 167 For IPv6 addresses containing a format prefix indicating that 168 interface identifiers are required to be 64 bits in length and are 169 required to be in EUI-64 format (currently format prefixes 001 170 through 111, except for 1111 1111 [3]), the reserved Mobile IPv6 171 Home-Agents subnet anycast address consists of the 64-bit subnet 172 prefix followed by the 64-bit interface identifier shown below: 174 |0 1|1 3|3 4|4 6| 175 |0 5|6 1|2 7|8 3| 176 +----------------+----------------+----------------+----------------+ 177 |1111110111111111|1111111111111111|1111111111111111|1111111111111110| 178 +----------------+----------------+----------------+----------------+ 179 ^ ^^^^^^^ 180 +--- universal/local bit anycast identifier ---+-----+ 182 For other IPv6 address types, the interface identifier may be other 183 than 64 bits in length and is not in EUI-64 format. In this example, 184 assume that the length of the interface identifier is 64 bits, 185 to allow clear comparison with the example given above (although 186 interface identifiers of lengths other than 64 bits follow the same 187 general construction of the interface identifier shown here). In 188 this case, the reserved Mobile IPv6 Home-Agents subnet anycast 189 address consists of the 64-bit subnet prefix followed by the 64-bit 190 interface identifier shown below: 192 |0 1|1 3|3 4|4 6| 193 |0 5|6 1|2 7|8 3| 194 +----------------+----------------+----------------+----------------+ 195 |1111111111111111|1111111111111111|1111111111111111|1111111111111110| 196 +----------------+----------------+----------------+----------------+ 197 ^^^^^^^ 198 anycast identifier ---+-----+ 200 5. IANA Considerations 202 This document defines a set of reserved subnet anycast addresses, 203 based on a set of anycast identifiers within each subnet prefix 204 in the IPv6 unicast address space. As future needs arise, new 205 anycast identifiers may be defined. Such anycast identifiers MUST be 206 reserved within all subnet prefixes, and so the assignment of these 207 anycast identifiers requires centralized administration. New values 208 SHOULD be assigned in descending numerical order and are expected to 209 be assigned only with IESG approval. 211 6. Security Considerations 213 The use of any type of reserved anycast addresses poses a security 214 concern only in allowing potential attackers a well-known address to 215 attack. By designating certain services to be located at specific 216 reserved anycast addresses, an attacker may more profitably focus an 217 attack against such a specific service. Any such attack, however, is 218 best dealt with in each service that uses a reserved anycast address. 220 RFC 1546, which originally proposed the idea of anycasting in IP, 221 also points out a number of security considerations with the use of 222 anycasting in general [6]. 224 References 226 [1] Scott Bradner. Key words for use in RFCs to indicate requirement 227 levels. RFC 2119, March 1997. 229 [2] Stephen E. Deering and Robert M. Hinden. Internet Protocol 230 version 6 (IPv6) specification. RFC 2460, December 1998. 232 [3] Robert M. Hinden and Stephen E. Deering. IP Version 6 addressing 233 architecture. RFC 2373, July 1998. 235 [4] David B. Johnson and Charles Perkins. Mobility support in IPv6. 236 Internet-Draft, draft-ietf-mobileip-ipv6-07.txt, November 1998. 237 Work in progress. 239 [5] Steve King et al. The case for IPv6. Internet-Draft, 240 draft-ietf-iab-case-for-ipv6-03.txt, November 1998. Work in 241 progress. 243 [6] Craig Partridge, Trevor Mendez, and Walter Milliken. Host 244 anycasting service. RFC 1546, November 1993. 246 Authors' Addresses 248 David B. Johnson Stephen E. Deering 249 Carnegie Mellon University Cisco Systems, Inc. 250 Computer Science Department 170 West Tasman Drive 251 5000 Forbes Avenue San Jose, CA 95134-1706 252 Pittsburgh, PA 15213-3891 USA 253 USA 255 Phone: +1 412 268-7399 Phone: +1 408 527-8213 256 Fax: +1 412 268-5576 Fax: +1 408 527-8254 257 Email: dbj@cs.cmu.edu Email: deering@cisco.com 259 Full Copyright Statement 261 Copyright (C) The Internet Society (1999). All Rights Reserved. 263 This document and translations of it may be copied and furnished to 264 others, and derivative works that comment on or otherwise explain it 265 or assist in its implementation may be prepared, copied, published 266 and distributed, in whole or in part, without restriction of any 267 kind, provided that the above copyright notice and this paragraph 268 are included on all such copies and derivative works. However, 269 this document itself may not be modified in any way, such as by 270 removing the copyright notice or references to the Internet Society 271 or other Internet organizations, except as needed for the purpose 272 of developing Internet standards in which case the procedures 273 for copyrights defined in the Internet Standards process must be 274 followed, or as required to translate it into languages other than 275 English. 277 The limited permissions granted above are perpetual and will not be 278 revoked by the Internet Society or its successors or assigns. 280 This document and the information contained herein is provided on an 281 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 282 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 283 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 284 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 285 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.