idnits 2.17.00 (12 Aug 2021) /tmp/idnits63576/draft-ietf-ipv6-addr-arch-v4-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 928. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 935. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 941. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IPV6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 14 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 227 has weird spacing: '...address is ...' == Line 230 has weird spacing: '...-length is a...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3513' is mentioned on line 526, but not defined ** Obsolete undefined reference: RFC 3513 (Obsoleted by RFC 4291) == Unused Reference: 'RFC2026' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'MASGN' is defined on line 867, but no explicit reference was found in the text == Unused Reference: 'TOKEN' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'TRAN' is defined on line 883, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'AUTH') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. 'PRIV') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 2893 (ref. 'TRAN') (Obsoleted by RFC 4213) Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Hinden, Nokia 3 March 23, 2005 S. Deering, Cisco Systems 5 IP Version 6 Addressing Architecture 7 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet Draft expires September 28, 2005. 34 Abstract 36 This specification defines the addressing architecture of the IP 37 Version 6 protocol [IPV6]. The document includes the IPv6 addressing 38 model, text representations of IPv6 addresses, definition of IPv6 39 unicast addresses, anycast addresses, and multicast addresses, and an 40 IPv6 node's required addresses. 42 This document obsoletes RFC-3513 "IP Version 6 Addressing 43 Architecture". 45 Table of Contents 47 1. Introduction.................................................3 49 2. IPv6 Addressing..............................................3 50 2.1 Addressing Model.........................................4 51 2.2 Text Representation of Addresses.........................4 52 2.3 Text Representation of Address Prefixes..................5 53 2.4 Address Type Identification..............................7 54 2.5 Unicast Addresses........................................7 55 2.5.1 Interface Identifiers................................8 56 2.5.2 The Unspecified Address.............................10 57 2.5.3 The Loopback Address................................10 58 2.5.4 Global Unicast Addresses............................10 59 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.........11 60 2.5.6 Link-Local IPv6 Unicast Addresses...................12 61 2.5.7 Site-Local IPv6 Unicast Addresses...................12 62 2.6 Anycast Addresses.......................................13 63 2.6.1 Required Anycast Address............................14 64 2.7 Multicast Addresses.....................................14 65 2.7.1 Pre-Defined Multicast Addresses.....................17 66 2.8 A Node's Required Addresses.............................18 68 3. Security Considerations.....................................19 70 4. IANA Considerations.........................................19 72 5. References..................................................19 74 6. Author's Addresses..........................................20 76 7. Disclaimer of Validity......................................21 78 8. Copyright Statement.........................................21 80 9. Intellectual Property.......................................21 82 APPENDIX A: Creating Modified EUI-64 format Interface IDs......22 84 APPENDIX B: Changes from RFC-3513..............................25 86 1.0 INTRODUCTION 88 This specification defines the addressing architecture of the IP 89 Version 6 protocol. It includes the basic formats for the various 90 types of IPv6 addresses (unicast, anycast, and multicast). 92 The authors would like to acknowledge the contributions of Paul 93 Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, 94 Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, 95 Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg 96 Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, 97 Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino, 98 Tatuya Jinmei, Suresh Krishnan, and Mahmood Ali. 100 2.0 IPv6 ADDRESSING 102 IPv6 addresses are 128-bit identifiers for interfaces and sets of 103 interfaces (where "interface" is as defined in Section 2 of [IPV6]). 104 There are three types of addresses: 106 Unicast: An identifier for a single interface. A packet sent to a 107 unicast address is delivered to the interface identified 108 by that address. 110 Anycast: An identifier for a set of interfaces (typically 111 belonging to different nodes). A packet sent to an 112 anycast address is delivered to one of the interfaces 113 identified by that address (the "nearest" one, according 114 to the routing protocols' measure of distance). 116 Multicast: An identifier for a set of interfaces (typically 117 belonging to different nodes). A packet sent to a 118 multicast address is delivered to all interfaces 119 identified by that address. 121 There are no broadcast addresses in IPv6, their function being 122 superseded by multicast addresses. 124 In this document, fields in addresses are given a specific name, for 125 example "subnet". When this name is used with the term "ID" for 126 identifier after the name (e.g., "subnet ID"), it refers to the 127 contents of the named field. When it is used with the term "prefix" 128 (e.g., "subnet prefix") it refers to all of the address from the left 129 up to and including this field. 131 In IPv6, all zeros and all ones are legal values for any field, 132 unless specifically excluded. Specifically, prefixes may contain, or 133 end with, zero-valued fields. 135 2.1 Addressing Model 137 IPv6 addresses of all types are assigned to interfaces, not nodes. 138 An IPv6 unicast address refers to a single interface. Since each 139 interface belongs to a single node, any of that node's interfaces' 140 unicast addresses may be used as an identifier for the node. 142 All interfaces are required to have at least one link-local unicast 143 address (see Section 2.8 for additional required addresses). A 144 single interface may also have multiple IPv6 addresses of any type 145 (unicast, anycast, and multicast) or scope. Unicast addresses with 146 scope greater than link-scope are not needed for interfaces that are 147 not used as the origin or destination of any IPv6 packets to or from 148 non-neighbors. This is sometimes convenient for point-to-point 149 interfaces. There is one exception to this addressing model: 151 A unicast address or a set of unicast addresses may be assigned to 152 multiple physical interfaces if the implementation treats the 153 multiple physical interfaces as one interface when presenting it 154 to the internet layer. This is useful for load-sharing over 155 multiple physical interfaces. 157 Currently IPv6 continues the IPv4 model that a subnet prefix is 158 associated with one link. Multiple subnet prefixes may be assigned 159 to the same link. 161 2.2 Text Representation of Addresses 163 There are three conventional forms for representing IPv6 addresses as 164 text strings: 166 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to 167 four hexadecimal digits of the eight 16-bit pieces of the address. 168 Examples: 170 ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 172 2001:DB8:0:0:8:800:200C:417A 174 Note that it is not necessary to write the leading zeros in an 175 individual field, but there must be at least one numeral in every 176 field (except for the case described in 2.). 178 2. Due to some methods of allocating certain styles of IPv6 179 addresses, it will be common for addresses to contain long strings 180 of zero bits. In order to make writing addresses containing zero 181 bits easier a special syntax is available to compress the zeros. 182 The use of "::" indicates one or more groups of 16 bits of zeros. 183 The "::" can only appear once in an address. The "::" can also be 184 used to compress leading or trailing zeros in an address. 186 For example the following addresses: 188 2001:DB8:0:0:8:800:200C:417A a unicast address 189 FF01:0:0:0:0:0:0:101 a multicast address 190 0:0:0:0:0:0:0:1 the loopback address 191 0:0:0:0:0:0:0:0 the unspecified address 193 may be represented as: 195 2001:DB8::8:800:200C:417A a unicast address 196 FF01::101 a multicast address 197 ::1 the loopback address 198 :: the unspecified address 200 3. An alternative form that is sometimes more convenient when dealing 201 with a mixed environment of IPv4 and IPv6 nodes is 202 x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of 203 the six high-order 16-bit pieces of the address, and the 'd's are 204 the decimal values of the four low-order 8-bit pieces of the 205 address (standard IPv4 representation). Examples: 207 0:0:0:0:0:0:13.1.68.3 209 0:0:0:0:0:FFFF:129.144.52.38 211 or in compressed form: 213 ::13.1.68.3 215 ::FFFF:129.144.52.38 217 2.3 Text Representation of Address Prefixes 219 The text representation of IPv6 address prefixes is similar to the 220 way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An 221 IPv6 address prefix is represented by the notation: 223 ipv6-address/prefix-length 225 where 227 ipv6-address is an IPv6 address in any of the notations listed 228 in Section 2.2. 230 prefix-length is a decimal value specifying how many of the 231 leftmost contiguous bits of the address comprise 232 the prefix. 234 For example, the following are legal representations of the 60-bit 235 prefix 20010DB80000CD3 (hexadecimal): 237 2001:0DB8:0000:CD30:0000:0000:0000:0000/60 238 2001:0DB8::CD30:0:0:0:0/60 239 2001:0DB8:0:CD30::/60 241 The following are NOT legal representations of the above prefix: 243 2001:0DB8:0:CD3/60 may drop leading zeros, but not trailing 244 zeros, within any 16-bit chunk of the address 246 2001:0DB8::CD30/60 address to left of "/" expands to 247 2001:0DB8:0000:0000:0000:0000:0000:CD30 249 2001:0DB8::CD3/60 address to left of "/" expands to 250 2001:0DB8:0000:0000:0000:0000:0000:0CD3 252 When writing both a node address and a prefix of that node address 253 (e.g., the node's subnet prefix), the two can combined as follows: 255 the node address 2001:0DB8:0:CD30:123:4567:89AB:CDEF 256 and its subnet number 2001:0DB8:0:CD30::/60 258 can be abbreviated as 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60 260 2.4 Address Type Identification 262 The type of an IPv6 address is identified by the high-order bits of 263 the address, as follows: 265 Address type Binary prefix IPv6 notation Section 266 ------------ ------------- ------------- ------- 267 Unspecified 00...0 (128 bits) ::/128 2.5.2 268 Loopback 00...1 (128 bits) ::1/128 2.5.3 269 Multicast 11111111 FF00::/8 2.7 270 Link-local unicast 1111111010 FE80::/10 2.5.6 271 Global unicast (everything else) 273 Anycast addresses are taken from the unicast address spaces (of any 274 scope) and are not syntactically distinguishable from unicast 275 addresses. 277 The general format of global unicast addresses is described in 278 Section 2.5.4. Some special-purpose subtypes of global unicast 279 addresses which contain embedded IPv4 addresses (for the purposes of 280 IPv4-IPv6 interoperation) are described in Section 2.5.5. 282 Future specifications may redefine one or more sub-ranges of the 283 global unicast space for other purposes, but unless and until that 284 happens, implementations must treat all addresses that do not start 285 with any of the above-listed prefixes as global unicast addresses. 287 2.5 Unicast Addresses 289 IPv6 unicast addresses are aggregatable with prefixes of arbitrary 290 bit-length similar to IPv4 addresses under Classless Interdomain 291 Routing. 293 There are several types of unicast addresses in IPv6, in particular 294 global unicast, site-local unicast (deprecated, see Section 2.5.7), 295 and link-local unicast. There are also some special-purpose subtypes 296 of global unicast, such as IPv6 addresses with embedded IPv4 297 addresses. Additional address types or subtypes can be defined in 298 the future. 300 IPv6 nodes may have considerable or little knowledge of the internal 301 structure of the IPv6 address, depending on the role the node plays 302 (for instance, host versus router). At a minimum, a node may 303 consider that unicast addresses (including its own) have no internal 304 structure: 306 | 128 bits | 307 +-----------------------------------------------------------------+ 308 | node address | 309 +-----------------------------------------------------------------+ 311 A slightly sophisticated host (but still rather simple) may 312 additionally be aware of subnet prefix(es) for the link(s) it is 313 attached to, where different addresses may have different values for 314 n: 316 | n bits | 128-n bits | 317 +-------------------------------+---------------------------------+ 318 | subnet prefix | interface ID | 319 +-------------------------------+---------------------------------+ 321 Though a very simple router may have no knowledge of the internal 322 structure of IPv6 unicast addresses, routers will more generally have 323 knowledge of one or more of the hierarchical boundaries for the 324 operation of routing protocols. The known boundaries will differ 325 from router to router, depending on what positions the router holds 326 in the routing hierarchy. 328 Except for the knowledge of the subnet boundary discussed in the 329 pervious paragraphs nodes should not make any assumptions about the 330 structure of an IPv6 address. 332 2.5.1 Interface Identifiers 334 Interface identifiers in IPv6 unicast addresses are used to identify 335 interfaces on a link. They are required to be unique within a subnet 336 prefix. It is recommended that the same interface identifier not be 337 assigned to different nodes on a link. They may also be unique over 338 a broader scope. In some cases an interface's identifier will be 339 derived directly from that interface's link-layer address. The same 340 interface identifier may be used on multiple interfaces on a single 341 node, as long as they are attached to different subnets. 343 Note that the uniqueness of interface identifiers is independent of 344 the uniqueness of IPv6 addresses. For example, a global unicast 345 address may be created with a local scope interface identifier and a 346 link-local address may be created with a universal scope interface 347 identifier. 349 For all unicast addresses, except those that start with binary value 350 000, Interface IDs are required to be 64 bits long and to be 351 constructed in Modified EUI-64 format. 353 Modified EUI-64 format based Interface identifiers may have universal 354 scope when derived from a universal token (e.g., IEEE 802 48-bit MAC 355 or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a 356 global token is not available (e.g., serial links, tunnel end-points, 357 etc.) or where global tokens are undesirable (e.g., temporary tokens 358 for privacy [PRIV]). 360 Modified EUI-64 format interface identifiers are formed by inverting 361 the "u" bit (universal/local bit in IEEE EUI-64 terminology) when 362 forming the interface identifier from IEEE EUI-64 identifiers. In 363 the resulting Modified EUI-64 format the "u" bit is set to one (1) to 364 indicate universal scope, and it is set to zero (0) to indicate local 365 scope. The first three octets in binary of an IEEE EUI-64 identifier 366 are as follows: 368 0 0 0 1 1 2 369 |0 7 8 5 6 3| 370 +----+----+----+----+----+----+ 371 |cccc|ccug|cccc|cccc|cccc|cccc| 372 +----+----+----+----+----+----+ 374 written in Internet standard bit-order , where "u" is the 375 universal/local bit, "g" is the individual/group bit, and "c" are the 376 bits of the company_id. Appendix A: "Creating Modified EUI-64 format 377 Interface Identifiers" provides examples on the creation of Modified 378 EUI-64 format based interface identifiers. 380 The motivation for inverting the "u" bit when forming an interface 381 identifier is to make it easy for system administrators to hand 382 configure non-global identifiers when hardware tokens are not 383 available. This is expected to be case for serial links, tunnel end- 384 points, etc. The alternative would have been for these to be of the 385 form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 386 0:0:0:1, 0:0:0:2, etc. 388 IPv6 nodes are not required to validate that interface identifiers 389 created with modified EUI-64 tokens with the "u" bit set to universal 390 are unique. 392 The use of the universal/local bit in the Modified EUI-64 format 393 identifier is to allow development of future technology that can take 394 advantage of interface identifiers with universal scope. 396 The details of forming interface identifiers are defined in the 397 appropriate "IPv6 over " specification such as "IPv6 over 398 Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. 400 2.5.2 The Unspecified Address 402 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It 403 must never be assigned to any node. It indicates the absence of an 404 address. One example of its use is in the Source Address field of 405 any IPv6 packets sent by an initializing host before it has learned 406 its own address. 408 The unspecified address must not be used as the destination address 409 of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a 410 source address of unspecified must never be forwarded by an IPv6 411 router. 413 2.5.3 The Loopback Address 415 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. 416 It may be used by a node to send an IPv6 packet to itself. It must 417 not be assigned to any physical interface. It is treated as having 418 link-local scope, and may be thought of as the link-local unicast 419 address of a virtual interface (typically called "the loopback 420 interface") to an imaginary link that goes nowhere. 422 The loopback address must not be used as the source address in IPv6 423 packets that are sent outside of a single node. An IPv6 packet with 424 a destination address of loopback must never be sent outside of a 425 single node and must never be forwarded by an IPv6 router. A packet 426 received on an interface with destination address of loopback must be 427 dropped. 429 2.5.4 Global Unicast Addresses 431 The general format for IPv6 global unicast addresses is as follows: 433 | n bits | m bits | 128-n-m bits | 434 +------------------------+-----------+----------------------------+ 435 | global routing prefix | subnet ID | interface ID | 436 +------------------------+-----------+----------------------------+ 438 where the global routing prefix is a (typically hierarchically- 439 structured) value assigned to a site (a cluster of subnets/links), 440 the subnet ID is an identifier of a link within the site, and the 441 interface ID is as defined in Section 2.5.1. 443 All global unicast addresses other than those that start with binary 444 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as 445 described in Section 2.5.1. Global unicast addresses that start with 446 binary 000 have no such constraint on the size or structure of the 447 interface ID field. 449 Examples of global unicast addresses that start with binary 000 are 450 the IPv6 address with embedded IPv4 addresses described in Section 451 2.5.5. An example of global addresses starting with a binary value 452 other than 000 (and therefore having a 64-bit interface ID field) can 453 be found in [GLOBAL]. 455 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses 457 Two types of IPv6 addresses are defined that carry an IPv4 address in 458 the low-order 32 bits of the address. These are the "IPv4-Compatible 459 IPv6 Address" and the "IPv4-Mapped IPv6 Address". 461 2.5.5.1 IPv4-Compatible IPv6 Address 463 The "IPv4-compatible IPv6 address", was defined to assist in the IPv6 464 transition. The format of the "IPv4-compatible IPv6 address" is: 466 | 80 bits | 16 | 32 bits | 467 +--------------------------------------+--------------------------+ 468 |0000..............................0000|0000| IPv4 address | 469 +--------------------------------------+----+---------------------+ 471 Note: The IPv4 address used in the "IPv4-compatible IPv6 address" 472 must be a globally-unique IPv4 unicast address. 474 The "IPv4-compatible IPv6 address" is now deprecated because the 475 current IPv6 transition mechanisms no longer use these addresses. 476 New or updated implementations are not required to support this 477 address type. 479 2.5.5.2 IPv4-Mapped IPv6 Address 481 A second type of IPv6 address that holds an embedded IPv4 address is 482 defined. This address type is used to represent the addresses of 483 IPv4 nodes as IPv6 addresses. The format of the "IPv4-mapped IPv6 484 address" is: 486 | 80 bits | 16 | 32 bits | 487 +--------------------------------------+--------------------------+ 488 |0000..............................0000|FFFF| IPv4 address | 489 +--------------------------------------+----+---------------------+ 491 See [RFC4038] for background on the usage of the "IPv4-mapped IPv6 492 address". 494 2.5.6 Link-Local IPv6 Unicast Addresses 496 Link-Local addresses are for use on a single link. Link-Local 497 addresses have the following format: 499 | 10 | 500 | bits | 54 bits | 64 bits | 501 +----------+-------------------------+----------------------------+ 502 |1111111010| 0 | interface ID | 503 +----------+-------------------------+----------------------------+ 505 Link-Local addresses are designed to be used for addressing on a 506 single link for purposes such as automatic address configuration, 507 neighbor discovery, or when no routers are present. 509 Routers must not forward any packets with link-local source or 510 destination addresses to other links. 512 2.5.7 Site-Local IPv6 Unicast Addresses 514 Site-local addresses were originally designed to be used for 515 addressing inside of a site without the need for a global prefix. 516 Site-Local addresses are now deprecated as defined in [SLDEP]. 518 Site-Local addresses have the following format: 520 | 10 | 521 | bits | 54 bits | 64 bits | 522 +----------+-------------------------+----------------------------+ 523 |1111111011| subnet ID | interface ID | 524 +----------+-------------------------+----------------------------+ 526 The special behavior of this prefix defined in [RFC3513] must no 527 longer be supported in new implementations (i.e., new implementations 528 must treat this prefix as Global Unicast). 530 Existing implementations and deployments may continue to use this 531 prefix. 533 2.6 Anycast Addresses 535 An IPv6 anycast address is an address that is assigned to more than 536 one interface (typically belonging to different nodes), with the 537 property that a packet sent to an anycast address is routed to the 538 "nearest" interface having that address, according to the routing 539 protocols' measure of distance. 541 Anycast addresses are allocated from the unicast address space, using 542 any of the defined unicast address formats. Thus, anycast addresses 543 are syntactically indistinguishable from unicast addresses. When a 544 unicast address is assigned to more than one interface, thus turning 545 it into an anycast address, the nodes to which the address is 546 assigned must be explicitly configured to know that it is an anycast 547 address. 549 For any assigned anycast address, there is a longest prefix P of that 550 address that identifies the topological region in which all 551 interfaces belonging to that anycast address reside. Within the 552 region identified by P, the anycast address must be maintained as a 553 separate entry in the routing system (commonly referred to as a "host 554 route"); outside the region identified by P, the anycast address may 555 be aggregated into the routing entry for prefix P. 557 Note that in the worst case, the prefix P of an anycast set may be 558 the null prefix, i.e., the members of the set may have no topological 559 locality. In that case, the anycast address must be maintained as a 560 separate routing entry throughout the entire Internet, which presents 561 a severe scaling limit on how many such "global" anycast sets may be 562 supported. Therefore, it is expected that support for global anycast 563 sets may be unavailable or very restricted. 565 One expected use of anycast addresses is to identify the set of 566 routers belonging to an organization providing Internet service. 567 Such addresses could be used as intermediate addresses in an IPv6 568 Routing header, to cause a packet to be delivered via a particular 569 service provider or sequence of service providers. 571 Some other possible uses are to identify the set of routers attached 572 to a particular subnet, or the set of routers providing entry into a 573 particular routing domain. 575 There is little experience with widespread, arbitrary use of Internet 576 anycast addresses, and some known complications and hazards when 577 using them in their full generality [ANYCST]. Until more experience 578 has been gained and solutions are specified, the following 579 restrictions are imposed on IPv6 anycast addresses: 581 o An anycast address must not be used as the source address of an 582 IPv6 packet. 584 o An anycast address must not be assigned to an IPv6 host, that 585 is, it may be assigned to an IPv6 router only. 587 2.6.1 Required Anycast Address 589 The Subnet-Router anycast address is predefined. Its format is as 590 follows: 592 | n bits | 128-n bits | 593 +------------------------------------------------+----------------+ 594 | subnet prefix | 00000000000000 | 595 +------------------------------------------------+----------------+ 597 The "subnet prefix" in an anycast address is the prefix which 598 identifies a specific link. This anycast address is syntactically 599 the same as a unicast address for an interface on the link with the 600 interface identifier set to zero. 602 Packets sent to the Subnet-Router anycast address will be delivered 603 to one router on the subnet. All routers are required to support the 604 Subnet-Router anycast addresses for the subnets to which they have 605 interfaces. 607 The subnet-router anycast address is intended to be used for 608 applications where a node needs to communicate with any one of the 609 set of routers. 611 2.7 Multicast Addresses 613 An IPv6 multicast address is an identifier for a group of interfaces 614 (typically on different nodes). An interface may belong to any 615 number of multicast groups. Multicast addresses have the following 616 format: 618 | 8 | 4 | 4 | 112 bits | 619 +------ -+----+----+---------------------------------------------+ 620 |11111111|flgs|scop| group ID | 621 +--------+----+----+---------------------------------------------+ 623 binary 11111111 at the start of the address identifies the 624 address as being a multicast address. 626 +-+-+-+-+ 627 flgs is a set of 4 flags: |0|0|0|T| 628 +-+-+-+-+ 630 The high-order 3 flags are reserved, and must be 631 initialized to 0. 633 T = 0 indicates a permanently-assigned ("well-known") 634 multicast address, assigned by the Internet Assigned Number 635 Authority (IANA). 637 T = 1 indicates a non-permanently-assigned ("transient") 638 multicast address. 640 scop is a 4-bit multicast scope value used to limit the scope of 641 the multicast group. The values are: 643 0 reserved 644 1 interface-local scope 645 2 link-local scope 646 3 reserved 647 4 admin-local scope 648 5 site-local scope 649 6 (unassigned) 650 7 (unassigned) 651 8 organization-local scope 652 9 (unassigned) 653 A (unassigned) 654 B (unassigned) 655 C (unassigned) 656 D (unassigned) 657 E global scope 658 F reserved 660 interface-local scope spans only a single interface on a 661 node, and is useful only for loopback transmission of 662 multicast. 664 link-local multicast scope spans the same 665 topological region as the corresponding unicast scope. 667 admin-local scope is the smallest scope that must be 668 administratively configured, i.e., not automatically 669 derived from physical connectivity or other, non- 670 multicast-related configuration. 672 site-local scope is intended to span a single site. 674 organization-local scope is intended to span multiple 675 sites belonging to a single organization. 677 scopes labeled "(unassigned)" are available for 678 administrators to define additional multicast regions. 680 group ID identifies the multicast group, either permanent or 681 transient, within the given scope. 683 The "meaning" of a permanently-assigned multicast address is 684 independent of the scope value. For example, if the "NTP servers 685 group" is assigned a permanent multicast address with a group ID of 686 101 (hex), then: 688 FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface 689 (i.e., the same node) as the sender. 691 FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as 692 the sender. 694 FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as 695 the sender. 697 FF0E:0:0:0:0:0:0:101 means all NTP servers in the Internet. 699 Non-permanently-assigned multicast addresses are meaningful only 700 within a given scope. For example, a group identified by the non- 701 permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one 702 site bears no relationship to a group using the same address at a 703 different site, nor to a non-permanent group using the same group ID 704 with different scope, nor to a permanent group with the same group 705 ID. 707 Multicast addresses must not be used as source addresses in IPv6 708 packets or appear in any Routing header. 710 Routers must not forward any multicast packets beyond of the scope 711 indicated by the scop field in the destination multicast address. 713 Nodes must not originate a packet to a multicast address whose scop 714 field contains the reserved value 0; if such a packet is received, it 715 must be silently dropped. Nodes should not originate a packet to a 716 multicast address whose scop field contains the reserved value F; if 717 such a packet is sent or received, it must be treated the same as 718 packets destined to a global (scop E) multicast address. 720 2.7.1 Pre-Defined Multicast Addresses 722 The following well-known multicast addresses are pre-defined. The 723 group ID's defined in this section are defined for explicit scope 724 values. 726 Use of these group IDs for any other scope values, with the T flag 727 equal to 0, is not allowed. 729 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 730 FF01:0:0:0:0:0:0:0 731 FF02:0:0:0:0:0:0:0 732 FF03:0:0:0:0:0:0:0 733 FF04:0:0:0:0:0:0:0 734 FF05:0:0:0:0:0:0:0 735 FF06:0:0:0:0:0:0:0 736 FF07:0:0:0:0:0:0:0 737 FF08:0:0:0:0:0:0:0 738 FF09:0:0:0:0:0:0:0 739 FF0A:0:0:0:0:0:0:0 740 FF0B:0:0:0:0:0:0:0 741 FF0C:0:0:0:0:0:0:0 742 FF0D:0:0:0:0:0:0:0 743 FF0E:0:0:0:0:0:0:0 744 FF0F:0:0:0:0:0:0:0 746 The above multicast addresses are reserved and shall never be 747 assigned to any multicast group. 749 All Nodes Addresses: FF01:0:0:0:0:0:0:1 750 FF02:0:0:0:0:0:0:1 752 The above multicast addresses identify the group of all IPv6 nodes, 753 within scope 1 (interface-local) or 2 (link-local). 755 All Routers Addresses: FF01:0:0:0:0:0:0:2 756 FF02:0:0:0:0:0:0:2 757 FF05:0:0:0:0:0:0:2 759 The above multicast addresses identify the group of all IPv6 routers, 760 within scope 1 (interface-local), 2 (link-local), or 5 (site-local). 762 Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX 764 Solicited-node multicast address are computed as a function of a 765 node's unicast and anycast addresses. A solicited-node multicast 766 address is formed by taking the low-order 24 bits of an address 767 (unicast or anycast) and appending those bits to the prefix 768 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 769 range 771 FF02:0:0:0:0:1:FF00:0000 773 to 775 FF02:0:0:0:0:1:FFFF:FFFF 777 For example, the solicited node multicast address corresponding to 778 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 779 addresses that differ only in the high-order bits, e.g. due to 780 multiple high-order prefixes associated with different aggregations, 781 will map to the same solicited-node address thereby, reducing the 782 number of multicast addresses a node must join. 784 A node is required to compute and join (on the appropriate interface) 785 the associated Solicited-Node multicast addresses for all Unicast and 786 Anycast Addresses that have been configured for the node's interfaces 787 (manually or automatically). 789 2.8 A Node's Required Addresses 791 A host is required to recognize the following addresses as 792 identifying itself: 794 o Its required Link-Local Address for each interface. 795 o Any additional Unicast and Anycast Addresses that have been 796 configured for the node's interfaces (manually or 797 automatically). 798 o The loopback address. 799 o The All-Nodes Multicast Addresses defined in Section 2.7.1. 800 o The Solicited-Node Multicast Address for each of its unicast and 801 anycast addresses. 802 o Multicast Addresses of all other groups to which the node 803 belongs. 805 A router is required to recognize all addresses that a host is 806 required to recognize, plus the following addresses as identifying 807 itself: 809 o The Subnet-Router Anycast Addresses for all interfaces for which 810 it is configured to act as a router. 811 o All other Anycast Addresses with which the router has been 812 configured. 813 o The All-Routers Multicast Addresses defined in Section 2.7.1. 815 3. Security Considerations 817 IPv6 addressing documents do not have any direct impact on Internet 818 infrastructure security. Authentication of IPv6 packets is defined 819 in [AUTH]. 821 4. IANA Considerations 823 The "IPv4-compatible IPv6 address" is deprecated by this document. 824 The IANA should continue to list the address block containing this 825 address as "Reserved by IETF" and not reassign it for any other 826 purpose. 828 The IANA should update the references for the IPv6 Address 829 Architecture in the IANA registries to this RFC when it is published. 831 5. References 833 5.1 Normative References 835 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 836 (IPv6) Specification", RFC2460, December 1998. 838 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 839 3", RFC2026, BCP00009, October 1996. 841 5.2 Non-Normative References 843 [ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host 844 Anycasting Service", RFC1546, November 1993. 846 [AUTH] Kent, S., and R. Atkinson, "IP Authentication Header", 847 RFC2402, November 1998. 849 [CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless 850 Inter-Domain Routing (CIDR): An Address Assignment and 851 Aggregation Strategy", RFC1519, September 1993. 853 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 854 Networks", RFC2464, December 1998. 856 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 857 Registration Authority", 858 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 859 , March 1997. 861 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 862 Networks", RFC2467, December 1998. 864 [GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 865 Unicast Address Format", RFC3587, August 2003. 867 [MASGN] Hinden, R., "IPv6 Multicast Address Assignments", RFC2375, 868 July 1998. 870 [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless 871 Address Autoconfiguration in IPv6", RFC3041, January 2001. 873 [RFC4038] Shin, M-K., et. al., "Application Aspects of IPv6 874 Transition", RFC4038, March 2005. 876 [SLDEP] Huitema, C. and B. Carpenter, "Deprecating Site Local 877 Addresses", RFC3879, September 2004. 879 [TOKEN] Crawford, M., Narten, T., and S. Thomas, "Transmission of 880 IPv6 Packets over Token Ring Networks", RFC2470, December 881 1998. 883 [TRAN] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 884 IPv6 Hosts and Routers", RFC2893, August 2000. 886 6. Author's Addresses 888 Robert M. Hinden 889 Nokia 890 313 Fairchild Drive 891 Mountain View, CA 94043 892 USA 894 phone: +1 650 625-2004 895 email: bob.hinden@nokia.com 897 Stephen E. Deering 898 Cisco Systems, Inc. 899 170 West Tasman Drive 900 San Jose, CA 95134-1706 901 USA 903 7. Disclaimer of Validity 905 This document and the information contained herein are provided on an 906 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 907 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 908 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 909 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 910 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 911 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 913 8. Copyright Statement 915 Copyright (C) The Internet Society (2005). This document is subject 916 to the rights, licenses and restrictions contained in BCP 78, and 917 except as set forth therein, the authors retain all their rights. 919 9. Intellectual Property 921 The IETF takes no position regarding the validity or scope of any 922 Intellectual Property Rights or other rights that might be claimed to 923 pertain to the implementation or use of the technology described in 924 this document or the extent to which any license under such rights 925 might or might not be available; nor does it represent that it has 926 made any independent effort to identify any such rights. Information 927 on the procedures with respect to rights in RFC documents can be 928 found in BCP 78 and BCP 79. 930 Copies of IPR disclosures made to the IETF Secretariat and any 931 assurances of licenses to be made available, or the result of an 932 attempt made to obtain a general license or permission for the use of 933 such proprietary rights by implementers or users of this 934 specification can be obtained from the IETF on-line IPR repository at 935 http://www.ietf.org/ipr. 937 The IETF invites any interested party to bring to its attention any 938 copyrights, patents or patent applications, or other proprietary 939 rights that may cover technology that may be required to implement 940 this standard. Please address the information to the IETF at ietf- 941 ipr@ietf.org. 943 APPENDIX A: Creating Modified EUI-64 format Interface Identifiers 944 ------------------------------------------------------------------ 946 Depending on the characteristics of a specific link or node there are 947 a number of approaches for creating Modified EUI-64 format interface 948 identifiers. This appendix describes some of these approaches. 950 Links or Nodes with IEEE EUI-64 Identifiers 952 The only change needed to transform an IEEE EUI-64 identifier to an 953 interface identifier is to invert the "u" (universal/local) bit. For 954 example, a globally unique IEEE EUI-64 identifier of the form: 956 |0 1|1 3|3 4|4 6| 957 |0 5|6 1|2 7|8 3| 958 +----------------+----------------+----------------+----------------+ 959 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 960 +----------------+----------------+----------------+----------------+ 962 where "c" are the bits of the assigned company_id, "0" is the value 963 of the universal/local bit to indicate universal scope, "g" is 964 individual/group bit, and "m" are the bits of the manufacturer- 965 selected extension identifier. The IPv6 interface identifier would 966 be of the form: 968 |0 1|1 3|3 4|4 6| 969 |0 5|6 1|2 7|8 3| 970 +----------------+----------------+----------------+----------------+ 971 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 972 +----------------+----------------+----------------+----------------+ 974 The only change is inverting the value of the universal/local bit. 976 Links or Nodes with IEEE 802 48 bit MAC's 978 [EUI64] defines a method to create a IEEE EUI-64 identifier from an 979 IEEE 48bit MAC identifier. This is to insert two octets, with 980 hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC 981 (between the company_id and vendor supplied id). For example the 48 982 bit IEEE MAC with global scope: 984 |0 1|1 3|3 4| 985 |0 5|6 1|2 7| 986 +----------------+----------------+----------------+ 987 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 988 +----------------+----------------+----------------+ 990 where "c" are the bits of the assigned company_id, "0" is the value 991 of the universal/local bit to indicate global scope, "g" is 992 individual/group bit, and "m" are the bits of the manufacturer- 993 selected extension identifier. The interface identifier would be of 994 the form: 996 |0 1|1 3|3 4|4 6| 997 |0 5|6 1|2 7|8 3| 998 +----------------+----------------+----------------+----------------+ 999 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 1000 +----------------+----------------+----------------+----------------+ 1002 When IEEE 802 48bit MAC addresses are available (on an interface or a 1003 node), an implementation may use them to create interface identifiers 1004 due to their availability and uniqueness properties. 1006 Links with Other Kinds of Identifiers 1008 There are a number of types of links that have link-layer interface 1009 identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples 1010 include LocalTalk and Arcnet. The method to create an Modified 1011 EUI-64 format identifier is to take the link identifier (e.g., the 1012 LocalTalk 8 bit node identifier) and zero fill it to the left. For 1013 example a LocalTalk 8 bit node identifier of hexadecimal value 0x4F 1014 results in the following interface identifier: 1016 |0 1|1 3|3 4|4 6| 1017 |0 5|6 1|2 7|8 3| 1018 +----------------+----------------+----------------+----------------+ 1019 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 1020 +----------------+----------------+----------------+----------------+ 1022 Note that this results in the universal/local bit set to "0" to 1023 indicate local scope. 1025 Links without Identifiers 1027 There are a number of links that do not have any type of built-in 1028 identifier. The most common of these are serial links and configured 1029 tunnels. Interface identifiers must be chosen that are unique within 1030 a subnet-prefix. 1032 When no built-in identifier is available on a link the preferred 1033 approach is to use a universal interface identifier from another 1034 interface or one which is assigned to the node itself. When using 1035 this approach no other interface connecting the same node to the same 1036 subnet-prefix may use the same identifier. 1038 If there is no universal interface identifier available for use on 1039 the link the implementation needs to create a local-scope interface 1040 identifier. The only requirement is that it be unique within a 1041 subnet prefix. There are many possible approaches to select a 1042 subnet-prefix-unique interface identifier. These include: 1044 Manual Configuration 1045 Node Serial Number 1046 Other node-specific token 1048 The subnet-prefix-unique interface identifier should be generated in 1049 a manner that it does not change after a reboot of a node or if 1050 interfaces are added or deleted from the node. 1052 The selection of the appropriate algorithm is link and implementation 1053 dependent. The details on forming interface identifiers are defined 1054 in the appropriate "IPv6 over " specification. It is strongly 1055 recommended that a collision detection algorithm be implemented as 1056 part of any automatic algorithm. 1058 APPENDIX B: Changes from RFC-3513 1059 --------------------------------- 1061 The following changes were made from RFC-3513 "IP Version 6 1062 Addressing Architecture": 1064 o Deprecated the Site-Local unicast prefix. Changes included 1065 - Removed Site-Local from special list of prefixes in Section 1066 2.4. 1067 - Split section titled "Local-use IPv6 Unicast Addresses" into 1068 two sections, "Link-Local IPv6 Unicast Addresses" and "Site- 1069 Local IPv6 Unicast Addresses". 1070 - Added text to new section describing Site-Local deprecation. 1072 o Changes to resolve issues raised in IAB response to Robert Elz 1073 appeal. Changes include: 1074 - Added clarification to Section 2.5 that nodes should make no 1075 assumptions about the structure of an IPv6 address. 1076 - Changed the text in Section 2.5.1 and Appendix A to refer to 1077 the modified EUI-64 format interface identifiers with the "u" 1078 bit set to one (1) as universal. 1079 - Added clarification to Section 2.5.1 that IPv6 nodes are not 1080 required to validate that interface identifiers created in 1081 modified EUI-64 format with the "u" bit set to one are unique. 1083 o Changed the reference indicated in Section 2.5.4 "Global Unicast 1084 Addresses" to RFC3587. 1086 o Removed mention of NSAP addresses in examples. 1088 o Clarified that the "x" in the textual representation can be one to 1089 four digits. 1091 o Deprecated the "IPv6 Compatible Address" because it is not being 1092 used in the IPv6 transition mechanisms. 1094 o Editorial changes.