idnits 2.17.1 draft-ietf-ipv6-addr-arch-v4-03.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 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 898. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 915. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 922. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 928. ** 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. 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 226 has weird spacing: '...address is ...' == Line 229 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 525, but not defined ** Obsolete undefined reference: RFC 3513 (Obsoleted by RFC 4291) == Unused Reference: 'RFC2026' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'ANYCST' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'MASGN' is defined on line 854, but no explicit reference was found in the text == Unused Reference: 'TOKEN' is defined on line 866, but no explicit reference was found in the text == Unused Reference: 'TRAN' is defined on line 870, 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: 6 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 April 29, 2005 S. Deering, Cisco Systems 4 IP Version 6 Addressing Architecture 6 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet Draft expires November 3, 2005. 33 Abstract 35 This specification defines the addressing architecture of the IP 36 Version 6 protocol [IPV6]. The document includes the IPv6 addressing 37 model, text representations of IPv6 addresses, definition of IPv6 38 unicast addresses, anycast addresses, and multicast addresses, and an 39 IPv6 node's required addresses. 41 This document obsoletes RFC-3513 "IP Version 6 Addressing 42 Architecture". 44 Table of Contents 46 1. Introduction.................................................3 48 2. IPv6 Addressing..............................................3 49 2.1 Addressing Model.........................................4 50 2.2 Text Representation of Addresses.........................4 51 2.3 Text Representation of Address Prefixes..................5 52 2.4 Address Type Identification..............................7 53 2.5 Unicast Addresses........................................7 54 2.5.1 Interface Identifiers................................8 55 2.5.2 The Unspecified Address.............................10 56 2.5.3 The Loopback Address................................10 57 2.5.4 Global Unicast Addresses............................10 58 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.........11 59 2.5.6 Link-Local IPv6 Unicast Addresses...................12 60 2.5.7 Site-Local IPv6 Unicast Addresses...................12 61 2.6 Anycast Addresses.......................................13 62 2.6.1 Required Anycast Address............................13 63 2.7 Multicast Addresses.....................................14 64 2.7.1 Pre-Defined Multicast Addresses.....................16 65 2.8 A Node's Required Addresses.............................18 67 3. Security Considerations.....................................18 69 4. IANA Considerations.........................................19 71 5. References..................................................19 73 6. Author's Addresses..........................................20 75 7. Disclaimer of Validity......................................20 77 8. Copyright Statement.........................................21 79 9. Intellectual Property.......................................21 81 APPENDIX A: Creating Modified EUI-64 format Interface IDs......22 83 APPENDIX B: Changes from RFC-3513..............................25 85 1.0 INTRODUCTION 87 This specification defines the addressing architecture of the IP 88 Version 6 protocol. It includes the basic formats for the various 89 types of IPv6 addresses (unicast, anycast, and multicast). 91 The authors would like to acknowledge the contributions of Paul 92 Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, 93 Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, 94 Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg 95 Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, 96 Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino, 97 Tatuya Jinmei, Suresh Krishnan, and Mahmood Ali. 99 2.0 IPv6 ADDRESSING 101 IPv6 addresses are 128-bit identifiers for interfaces and sets of 102 interfaces (where "interface" is as defined in Section 2 of [IPV6]). 103 There are three types of addresses: 105 Unicast: An identifier for a single interface. A packet sent to a 106 unicast address is delivered to the interface identified 107 by that address. 109 Anycast: An identifier for a set of interfaces (typically 110 belonging to different nodes). A packet sent to an 111 anycast address is delivered to one of the interfaces 112 identified by that address (the "nearest" one, according 113 to the routing protocols' measure of distance). 115 Multicast: An identifier for a set of interfaces (typically 116 belonging to different nodes). A packet sent to a 117 multicast address is delivered to all interfaces 118 identified by that address. 120 There are no broadcast addresses in IPv6, their function being 121 superseded by multicast addresses. 123 In this document, fields in addresses are given a specific name, for 124 example "subnet". When this name is used with the term "ID" for 125 identifier after the name (e.g., "subnet ID"), it refers to the 126 contents of the named field. When it is used with the term "prefix" 127 (e.g., "subnet prefix") it refers to all of the address from the left 128 up to and including this field. 130 In IPv6, all zeros and all ones are legal values for any field, 131 unless specifically excluded. Specifically, prefixes may contain, or 132 end with, zero-valued fields. 134 2.1 Addressing Model 136 IPv6 addresses of all types are assigned to interfaces, not nodes. 137 An IPv6 unicast address refers to a single interface. Since each 138 interface belongs to a single node, any of that node's interfaces' 139 unicast addresses may be used as an identifier for the node. 141 All interfaces are required to have at least one link-local unicast 142 address (see Section 2.8 for additional required addresses). A 143 single interface may also have multiple IPv6 addresses of any type 144 (unicast, anycast, and multicast) or scope. Unicast addresses with 145 scope greater than link-scope are not needed for interfaces that are 146 not used as the origin or destination of any IPv6 packets to or from 147 non-neighbors. This is sometimes convenient for point-to-point 148 interfaces. There is one exception to this addressing model: 150 A unicast address or a set of unicast addresses may be assigned to 151 multiple physical interfaces if the implementation treats the 152 multiple physical interfaces as one interface when presenting it 153 to the internet layer. This is useful for load-sharing over 154 multiple physical interfaces. 156 Currently IPv6 continues the IPv4 model that a subnet prefix is 157 associated with one link. Multiple subnet prefixes may be assigned 158 to the same link. 160 2.2 Text Representation of Addresses 162 There are three conventional forms for representing IPv6 addresses as 163 text strings: 165 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to 166 four hexadecimal digits of the eight 16-bit pieces of the address. 167 Examples: 169 ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 171 2001:DB8:0:0:8:800:200C:417A 173 Note that it is not necessary to write the leading zeros in an 174 individual field, but there must be at least one numeral in every 175 field (except for the case described in 2.). 177 2. Due to some methods of allocating certain styles of IPv6 178 addresses, it will be common for addresses to contain long strings 179 of zero bits. In order to make writing addresses containing zero 180 bits easier a special syntax is available to compress the zeros. 181 The use of "::" indicates one or more groups of 16 bits of zeros. 182 The "::" can only appear once in an address. The "::" can also be 183 used to compress leading or trailing zeros in an address. 185 For example the following addresses: 187 2001:DB8:0:0:8:800:200C:417A a unicast address 188 FF01:0:0:0:0:0:0:101 a multicast address 189 0:0:0:0:0:0:0:1 the loopback address 190 0:0:0:0:0:0:0:0 the unspecified address 192 may be represented as: 194 2001:DB8::8:800:200C:417A a unicast address 195 FF01::101 a multicast address 196 ::1 the loopback address 197 :: the unspecified address 199 3. An alternative form that is sometimes more convenient when dealing 200 with a mixed environment of IPv4 and IPv6 nodes is 201 x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of 202 the six high-order 16-bit pieces of the address, and the 'd's are 203 the decimal values of the four low-order 8-bit pieces of the 204 address (standard IPv4 representation). Examples: 206 0:0:0:0:0:0:13.1.68.3 208 0:0:0:0:0:FFFF:129.144.52.38 210 or in compressed form: 212 ::13.1.68.3 214 ::FFFF:129.144.52.38 216 2.3 Text Representation of Address Prefixes 218 The text representation of IPv6 address prefixes is similar to the 219 way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An 220 IPv6 address prefix is represented by the notation: 222 ipv6-address/prefix-length 224 where 226 ipv6-address is an IPv6 address in any of the notations listed 227 in Section 2.2. 229 prefix-length is a decimal value specifying how many of the 230 leftmost contiguous bits of the address comprise 231 the prefix. 233 For example, the following are legal representations of the 60-bit 234 prefix 20010DB80000CD3 (hexadecimal): 236 2001:0DB8:0000:CD30:0000:0000:0000:0000/60 237 2001:0DB8::CD30:0:0:0:0/60 238 2001:0DB8:0:CD30::/60 240 The following are NOT legal representations of the above prefix: 242 2001:0DB8:0:CD3/60 may drop leading zeros, but not trailing 243 zeros, within any 16-bit chunk of the address 245 2001:0DB8::CD30/60 address to left of "/" expands to 246 2001:0DB8:0000:0000:0000:0000:0000:CD30 248 2001:0DB8::CD3/60 address to left of "/" expands to 249 2001:0DB8:0000:0000:0000:0000:0000:0CD3 251 When writing both a node address and a prefix of that node address 252 (e.g., the node's subnet prefix), the two can combined as follows: 254 the node address 2001:0DB8:0:CD30:123:4567:89AB:CDEF 255 and its subnet number 2001:0DB8:0:CD30::/60 257 can be abbreviated as 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60 259 2.4 Address Type Identification 261 The type of an IPv6 address is identified by the high-order bits of 262 the address, as follows: 264 Address type Binary prefix IPv6 notation Section 265 ------------ ------------- ------------- ------- 266 Unspecified 00...0 (128 bits) ::/128 2.5.2 267 Loopback 00...1 (128 bits) ::1/128 2.5.3 268 Multicast 11111111 FF00::/8 2.7 269 Link-local unicast 1111111010 FE80::/10 2.5.6 270 Global unicast (everything else) 272 Anycast addresses are taken from the unicast address spaces (of any 273 scope) and are not syntactically distinguishable from unicast 274 addresses. 276 The general format of global unicast addresses is described in 277 Section 2.5.4. Some special-purpose subtypes of global unicast 278 addresses which contain embedded IPv4 addresses (for the purposes of 279 IPv4-IPv6 interoperation) are described in Section 2.5.5. 281 Future specifications may redefine one or more sub-ranges of the 282 global unicast space for other purposes, but unless and until that 283 happens, implementations must treat all addresses that do not start 284 with any of the above-listed prefixes as global unicast addresses. 286 2.5 Unicast Addresses 288 IPv6 unicast addresses are aggregatable with prefixes of arbitrary 289 bit-length similar to IPv4 addresses under Classless Interdomain 290 Routing. 292 There are several types of unicast addresses in IPv6, in particular 293 global unicast, site-local unicast (deprecated, see Section 2.5.7), 294 and link-local unicast. There are also some special-purpose subtypes 295 of global unicast, such as IPv6 addresses with embedded IPv4 296 addresses. Additional address types or subtypes can be defined in 297 the future. 299 IPv6 nodes may have considerable or little knowledge of the internal 300 structure of the IPv6 address, depending on the role the node plays 301 (for instance, host versus router). At a minimum, a node may 302 consider that unicast addresses (including its own) have no internal 303 structure: 305 | 128 bits | 306 +-----------------------------------------------------------------+ 307 | node address | 308 +-----------------------------------------------------------------+ 310 A slightly sophisticated host (but still rather simple) may 311 additionally be aware of subnet prefix(es) for the link(s) it is 312 attached to, where different addresses may have different values for 313 n: 315 | n bits | 128-n bits | 316 +-------------------------------+---------------------------------+ 317 | subnet prefix | interface ID | 318 +-------------------------------+---------------------------------+ 320 Though a very simple router may have no knowledge of the internal 321 structure of IPv6 unicast addresses, routers will more generally have 322 knowledge of one or more of the hierarchical boundaries for the 323 operation of routing protocols. The known boundaries will differ 324 from router to router, depending on what positions the router holds 325 in the routing hierarchy. 327 Except for the knowledge of the subnet boundary discussed in the 328 pervious paragraphs nodes should not make any assumptions about the 329 structure of an IPv6 address. 331 2.5.1 Interface Identifiers 333 Interface identifiers in IPv6 unicast addresses are used to identify 334 interfaces on a link. They are required to be unique within a subnet 335 prefix. It is recommended that the same interface identifier not be 336 assigned to different nodes on a link. They may also be unique over 337 a broader scope. In some cases an interface's identifier will be 338 derived directly from that interface's link-layer address. The same 339 interface identifier may be used on multiple interfaces on a single 340 node, as long as they are attached to different subnets. 342 Note that the uniqueness of interface identifiers is independent of 343 the uniqueness of IPv6 addresses. For example, a global unicast 344 address may be created with a local scope interface identifier and a 345 link-local address may be created with a universal scope interface 346 identifier. 348 For all unicast addresses, except those that start with binary value 349 000, Interface IDs are required to be 64 bits long and to be 350 constructed in Modified EUI-64 format. 352 Modified EUI-64 format based Interface identifiers may have universal 353 scope when derived from a universal token (e.g., IEEE 802 48-bit MAC 354 or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a 355 global token is not available (e.g., serial links, tunnel end-points, 356 etc.) or where global tokens are undesirable (e.g., temporary tokens 357 for privacy [PRIV]). 359 Modified EUI-64 format interface identifiers are formed by inverting 360 the "u" bit (universal/local bit in IEEE EUI-64 terminology) when 361 forming the interface identifier from IEEE EUI-64 identifiers. In 362 the resulting Modified EUI-64 format the "u" bit is set to one (1) to 363 indicate universal scope, and it is set to zero (0) to indicate local 364 scope. The first three octets in binary of an IEEE EUI-64 identifier 365 are as follows: 367 0 0 0 1 1 2 368 |0 7 8 5 6 3| 369 +----+----+----+----+----+----+ 370 |cccc|ccug|cccc|cccc|cccc|cccc| 371 +----+----+----+----+----+----+ 373 written in Internet standard bit-order , where "u" is the 374 universal/local bit, "g" is the individual/group bit, and "c" are the 375 bits of the company_id. Appendix A: "Creating Modified EUI-64 format 376 Interface Identifiers" provides examples on the creation of Modified 377 EUI-64 format based interface identifiers. 379 The motivation for inverting the "u" bit when forming an interface 380 identifier is to make it easy for system administrators to hand 381 configure non-global identifiers when hardware tokens are not 382 available. This is expected to be case for serial links, tunnel end- 383 points, etc. The alternative would have been for these to be of the 384 form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 385 0:0:0:1, 0:0:0:2, etc. 387 IPv6 nodes are not required to validate that interface identifiers 388 created with modified EUI-64 tokens with the "u" bit set to universal 389 are unique. 391 The use of the universal/local bit in the Modified EUI-64 format 392 identifier is to allow development of future technology that can take 393 advantage of interface identifiers with universal scope. 395 The details of forming interface identifiers are defined in the 396 appropriate "IPv6 over " specification such as "IPv6 over 397 Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. 399 2.5.2 The Unspecified Address 401 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It 402 must never be assigned to any node. It indicates the absence of an 403 address. One example of its use is in the Source Address field of 404 any IPv6 packets sent by an initializing host before it has learned 405 its own address. 407 The unspecified address must not be used as the destination address 408 of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a 409 source address of unspecified must never be forwarded by an IPv6 410 router. 412 2.5.3 The Loopback Address 414 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. 415 It may be used by a node to send an IPv6 packet to itself. It must 416 not be assigned to any physical interface. It is treated as having 417 link-local scope, and may be thought of as the link-local unicast 418 address of a virtual interface (typically called "the loopback 419 interface") to an imaginary link that goes nowhere. 421 The loopback address must not be used as the source address in IPv6 422 packets that are sent outside of a single node. An IPv6 packet with 423 a destination address of loopback must never be sent outside of a 424 single node and must never be forwarded by an IPv6 router. A packet 425 received on an interface with destination address of loopback must be 426 dropped. 428 2.5.4 Global Unicast Addresses 430 The general format for IPv6 global unicast addresses is as follows: 432 | n bits | m bits | 128-n-m bits | 433 +------------------------+-----------+----------------------------+ 434 | global routing prefix | subnet ID | interface ID | 435 +------------------------+-----------+----------------------------+ 437 where the global routing prefix is a (typically hierarchically- 438 structured) value assigned to a site (a cluster of subnets/links), 439 the subnet ID is an identifier of a link within the site, and the 440 interface ID is as defined in Section 2.5.1. 442 All global unicast addresses other than those that start with binary 443 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as 444 described in Section 2.5.1. Global unicast addresses that start with 445 binary 000 have no such constraint on the size or structure of the 446 interface ID field. 448 Examples of global unicast addresses that start with binary 000 are 449 the IPv6 address with embedded IPv4 addresses described in Section 450 2.5.5. An example of global addresses starting with a binary value 451 other than 000 (and therefore having a 64-bit interface ID field) can 452 be found in [GLOBAL]. 454 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses 456 Two types of IPv6 addresses are defined that carry an IPv4 address in 457 the low-order 32 bits of the address. These are the "IPv4-Compatible 458 IPv6 Address" and the "IPv4-Mapped IPv6 Address". 460 2.5.5.1 IPv4-Compatible IPv6 Address 462 The "IPv4-compatible IPv6 address", was defined to assist in the IPv6 463 transition. The format of the "IPv4-compatible IPv6 address" is: 465 | 80 bits | 16 | 32 bits | 466 +--------------------------------------+--------------------------+ 467 |0000..............................0000|0000| IPv4 address | 468 +--------------------------------------+----+---------------------+ 470 Note: The IPv4 address used in the "IPv4-compatible IPv6 address" 471 must be a globally-unique IPv4 unicast address. 473 The "IPv4-compatible IPv6 address" is now deprecated because the 474 current IPv6 transition mechanisms no longer use these addresses. 475 New or updated implementations are not required to support this 476 address type. 478 2.5.5.2 IPv4-Mapped IPv6 Address 480 A second type of IPv6 address that holds an embedded IPv4 address is 481 defined. This address type is used to represent the addresses of 482 IPv4 nodes as IPv6 addresses. The format of the "IPv4-mapped IPv6 483 address" is: 485 | 80 bits | 16 | 32 bits | 486 +--------------------------------------+--------------------------+ 487 |0000..............................0000|FFFF| IPv4 address | 488 +--------------------------------------+----+---------------------+ 490 See [RFC4038] for background on the usage of the "IPv4-mapped IPv6 491 address". 493 2.5.6 Link-Local IPv6 Unicast Addresses 495 Link-Local addresses are for use on a single link. Link-Local 496 addresses have the following format: 498 | 10 | 499 | bits | 54 bits | 64 bits | 500 +----------+-------------------------+----------------------------+ 501 |1111111010| 0 | interface ID | 502 +----------+-------------------------+----------------------------+ 504 Link-Local addresses are designed to be used for addressing on a 505 single link for purposes such as automatic address configuration, 506 neighbor discovery, or when no routers are present. 508 Routers must not forward any packets with link-local source or 509 destination addresses to other links. 511 2.5.7 Site-Local IPv6 Unicast Addresses 513 Site-local addresses were originally designed to be used for 514 addressing inside of a site without the need for a global prefix. 515 Site-Local addresses are now deprecated as defined in [SLDEP]. 517 Site-Local addresses have the following format: 519 | 10 | 520 | bits | 54 bits | 64 bits | 521 +----------+-------------------------+----------------------------+ 522 |1111111011| subnet ID | interface ID | 523 +----------+-------------------------+----------------------------+ 525 The special behavior of this prefix defined in [RFC3513] must no 526 longer be supported in new implementations (i.e., new implementations 527 must treat this prefix as Global Unicast). 529 Existing implementations and deployments may continue to use this 530 prefix. 532 2.6 Anycast Addresses 534 An IPv6 anycast address is an address that is assigned to more than 535 one interface (typically belonging to different nodes), with the 536 property that a packet sent to an anycast address is routed to the 537 "nearest" interface having that address, according to the routing 538 protocols' measure of distance. 540 Anycast addresses are allocated from the unicast address space, using 541 any of the defined unicast address formats. Thus, anycast addresses 542 are syntactically indistinguishable from unicast addresses. When a 543 unicast address is assigned to more than one interface, thus turning 544 it into an anycast address, the nodes to which the address is 545 assigned must be explicitly configured to know that it is an anycast 546 address. 548 For any assigned anycast address, there is a longest prefix P of that 549 address that identifies the topological region in which all 550 interfaces belonging to that anycast address reside. Within the 551 region identified by P, the anycast address must be maintained as a 552 separate entry in the routing system (commonly referred to as a "host 553 route"); outside the region identified by P, the anycast address may 554 be aggregated into the routing entry for prefix P. 556 Note that in the worst case, the prefix P of an anycast set may be 557 the null prefix, i.e., the members of the set may have no topological 558 locality. In that case, the anycast address must be maintained as a 559 separate routing entry throughout the entire Internet, which presents 560 a severe scaling limit on how many such "global" anycast sets may be 561 supported. Therefore, it is expected that support for global anycast 562 sets may be unavailable or very restricted. 564 One expected use of anycast addresses is to identify the set of 565 routers belonging to an organization providing Internet service. 566 Such addresses could be used as intermediate addresses in an IPv6 567 Routing header, to cause a packet to be delivered via a particular 568 service provider or sequence of service providers. 570 Some other possible uses are to identify the set of routers attached 571 to a particular subnet, or the set of routers providing entry into a 572 particular routing domain. 574 2.6.1 Required Anycast Address 576 The Subnet-Router anycast address is predefined. Its format is as 577 follows: 579 | n bits | 128-n bits | 580 +------------------------------------------------+----------------+ 581 | subnet prefix | 00000000000000 | 582 +------------------------------------------------+----------------+ 584 The "subnet prefix" in an anycast address is the prefix which 585 identifies a specific link. This anycast address is syntactically 586 the same as a unicast address for an interface on the link with the 587 interface identifier set to zero. 589 Packets sent to the Subnet-Router anycast address will be delivered 590 to one router on the subnet. All routers are required to support the 591 Subnet-Router anycast addresses for the subnets to which they have 592 interfaces. 594 The subnet-router anycast address is intended to be used for 595 applications where a node needs to communicate with any one of the 596 set of routers. 598 2.7 Multicast Addresses 600 An IPv6 multicast address is an identifier for a group of interfaces 601 (typically on different nodes). An interface may belong to any 602 number of multicast groups. Multicast addresses have the following 603 format: 605 | 8 | 4 | 4 | 112 bits | 606 +------ -+----+----+---------------------------------------------+ 607 |11111111|flgs|scop| group ID | 608 +--------+----+----+---------------------------------------------+ 610 binary 11111111 at the start of the address identifies the 611 address as being a multicast address. 613 +-+-+-+-+ 614 flgs is a set of 4 flags: |0|0|0|T| 615 +-+-+-+-+ 617 The high-order 3 flags are reserved, and must be 618 initialized to 0. 620 T = 0 indicates a permanently-assigned ("well-known") 621 multicast address, assigned by the Internet Assigned Number 622 Authority (IANA). 624 T = 1 indicates a non-permanently-assigned ("transient") 625 multicast address. 627 scop is a 4-bit multicast scope value used to limit the scope of 628 the multicast group. The values are: 630 0 reserved 631 1 interface-local scope 632 2 link-local scope 633 3 reserved 634 4 admin-local scope 635 5 site-local scope 636 6 (unassigned) 637 7 (unassigned) 638 8 organization-local scope 639 9 (unassigned) 640 A (unassigned) 641 B (unassigned) 642 C (unassigned) 643 D (unassigned) 644 E global scope 645 F reserved 647 interface-local scope spans only a single interface on a 648 node, and is useful only for loopback transmission of 649 multicast. 651 link-local multicast scope spans the same 652 topological region as the corresponding unicast scope. 654 admin-local scope is the smallest scope that must be 655 administratively configured, i.e., not automatically 656 derived from physical connectivity or other, non- 657 multicast-related configuration. 659 site-local scope is intended to span a single site. 661 organization-local scope is intended to span multiple 662 sites belonging to a single organization. 664 scopes labeled "(unassigned)" are available for 665 administrators to define additional multicast regions. 667 group ID identifies the multicast group, either permanent or 668 transient, within the given scope. 670 The "meaning" of a permanently-assigned multicast address is 671 independent of the scope value. For example, if the "NTP servers 672 group" is assigned a permanent multicast address with a group ID of 673 101 (hex), then: 675 FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface 676 (i.e., the same node) as the sender. 678 FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as 679 the sender. 681 FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as 682 the sender. 684 FF0E:0:0:0:0:0:0:101 means all NTP servers in the Internet. 686 Non-permanently-assigned multicast addresses are meaningful only 687 within a given scope. For example, a group identified by the non- 688 permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one 689 site bears no relationship to a group using the same address at a 690 different site, nor to a non-permanent group using the same group ID 691 with different scope, nor to a permanent group with the same group 692 ID. 694 Multicast addresses must not be used as source addresses in IPv6 695 packets or appear in any Routing header. 697 Routers must not forward any multicast packets beyond of the scope 698 indicated by the scop field in the destination multicast address. 700 Nodes must not originate a packet to a multicast address whose scop 701 field contains the reserved value 0; if such a packet is received, it 702 must be silently dropped. Nodes should not originate a packet to a 703 multicast address whose scop field contains the reserved value F; if 704 such a packet is sent or received, it must be treated the same as 705 packets destined to a global (scop E) multicast address. 707 2.7.1 Pre-Defined Multicast Addresses 709 The following well-known multicast addresses are pre-defined. The 710 group ID's defined in this section are defined for explicit scope 711 values. 713 Use of these group IDs for any other scope values, with the T flag 714 equal to 0, is not allowed. 716 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 717 FF01:0:0:0:0:0:0:0 718 FF02:0:0:0:0:0:0:0 719 FF03:0:0:0:0:0:0:0 720 FF04:0:0:0:0:0:0:0 721 FF05:0:0:0:0:0:0:0 722 FF06:0:0:0:0:0:0:0 723 FF07:0:0:0:0:0:0:0 724 FF08:0:0:0:0:0:0:0 725 FF09:0:0:0:0:0:0:0 726 FF0A:0:0:0:0:0:0:0 727 FF0B:0:0:0:0:0:0:0 728 FF0C:0:0:0:0:0:0:0 729 FF0D:0:0:0:0:0:0:0 730 FF0E:0:0:0:0:0:0:0 731 FF0F:0:0:0:0:0:0:0 733 The above multicast addresses are reserved and shall never be 734 assigned to any multicast group. 736 All Nodes Addresses: FF01:0:0:0:0:0:0:1 737 FF02:0:0:0:0:0:0:1 739 The above multicast addresses identify the group of all IPv6 nodes, 740 within scope 1 (interface-local) or 2 (link-local). 742 All Routers Addresses: FF01:0:0:0:0:0:0:2 743 FF02:0:0:0:0:0:0:2 744 FF05:0:0:0:0:0:0:2 746 The above multicast addresses identify the group of all IPv6 routers, 747 within scope 1 (interface-local), 2 (link-local), or 5 (site-local). 749 Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX 751 Solicited-node multicast address are computed as a function of a 752 node's unicast and anycast addresses. A solicited-node multicast 753 address is formed by taking the low-order 24 bits of an address 754 (unicast or anycast) and appending those bits to the prefix 755 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 756 range 758 FF02:0:0:0:0:1:FF00:0000 760 to 762 FF02:0:0:0:0:1:FFFF:FFFF 764 For example, the solicited node multicast address corresponding to 765 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 766 addresses that differ only in the high-order bits, e.g. due to 767 multiple high-order prefixes associated with different aggregations, 768 will map to the same solicited-node address thereby, reducing the 769 number of multicast addresses a node must join. 771 A node is required to compute and join (on the appropriate interface) 772 the associated Solicited-Node multicast addresses for all Unicast and 773 Anycast Addresses that have been configured for the node's interfaces 774 (manually or automatically). 776 2.8 A Node's Required Addresses 778 A host is required to recognize the following addresses as 779 identifying itself: 781 o Its required Link-Local Address for each interface. 782 o Any additional Unicast and Anycast Addresses that have been 783 configured for the node's interfaces (manually or 784 automatically). 785 o The loopback address. 786 o The All-Nodes Multicast Addresses defined in Section 2.7.1. 787 o The Solicited-Node Multicast Address for each of its unicast and 788 anycast addresses. 789 o Multicast Addresses of all other groups to which the node 790 belongs. 792 A router is required to recognize all addresses that a host is 793 required to recognize, plus the following addresses as identifying 794 itself: 796 o The Subnet-Router Anycast Addresses for all interfaces for which 797 it is configured to act as a router. 798 o All other Anycast Addresses with which the router has been 799 configured. 800 o The All-Routers Multicast Addresses defined in Section 2.7.1. 802 3. Security Considerations 804 IPv6 addressing documents do not have any direct impact on Internet 805 infrastructure security. Authentication of IPv6 packets is defined 806 in [AUTH]. 808 4. IANA Considerations 810 The "IPv4-compatible IPv6 address" is deprecated by this document. 811 The IANA should continue to list the address block containing this 812 address as "Reserved by IETF" and not reassign it for any other 813 purpose. 815 The IANA should update the references for the IPv6 Address 816 Architecture in the IANA registries to this RFC when it is published. 818 5. References 820 5.1 Normative References 822 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 823 (IPv6) Specification", RFC2460, December 1998. 825 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 826 3", RFC2026, BCP00009, October 1996. 828 5.2 Non-Normative References 830 [ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host 831 Anycasting Service", RFC1546, November 1993. 833 [AUTH] Kent, S., and R. Atkinson, "IP Authentication Header", 834 RFC2402, November 1998. 836 [CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless 837 Inter-Domain Routing (CIDR): An Address Assignment and 838 Aggregation Strategy", RFC1519, September 1993. 840 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 841 Networks", RFC2464, December 1998. 843 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 844 Registration Authority", 845 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 846 , March 1997. 848 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 849 Networks", RFC2467, December 1998. 851 [GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 852 Unicast Address Format", RFC3587, August 2003. 854 [MASGN] Hinden, R., "IPv6 Multicast Address Assignments", RFC2375, 855 July 1998. 857 [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless 858 Address Autoconfiguration in IPv6", RFC3041, January 2001. 860 [RFC4038] Shin, M-K., et. al., "Application Aspects of IPv6 861 Transition", RFC4038, March 2005. 863 [SLDEP] Huitema, C. and B. Carpenter, "Deprecating Site Local 864 Addresses", RFC3879, September 2004. 866 [TOKEN] Crawford, M., Narten, T., and S. Thomas, "Transmission of 867 IPv6 Packets over Token Ring Networks", RFC2470, December 868 1998. 870 [TRAN] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 871 IPv6 Hosts and Routers", RFC2893, August 2000. 873 6. Author's Addresses 875 Robert M. Hinden 876 Nokia 877 313 Fairchild Drive 878 Mountain View, CA 94043 879 USA 881 phone: +1 650 625-2004 882 email: bob.hinden@nokia.com 884 Stephen E. Deering 885 Cisco Systems, Inc. 886 170 West Tasman Drive 887 San Jose, CA 95134-1706 888 USA 890 7. Disclaimer of Validity 892 This document and the information contained herein are provided on an 893 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 894 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 895 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 896 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 897 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 898 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 900 8. Copyright Statement 902 Copyright (C) The Internet Society (2005). This document is subject 903 to the rights, licenses and restrictions contained in BCP 78, and 904 except as set forth therein, the authors retain all their rights. 906 9. Intellectual Property 908 The IETF takes no position regarding the validity or scope of any 909 Intellectual Property Rights or other rights that might be claimed to 910 pertain to the implementation or use of the technology described in 911 this document or the extent to which any license under such rights 912 might or might not be available; nor does it represent that it has 913 made any independent effort to identify any such rights. Information 914 on the procedures with respect to rights in RFC documents can be 915 found in BCP 78 and BCP 79. 917 Copies of IPR disclosures made to the IETF Secretariat and any 918 assurances of licenses to be made available, or the result of an 919 attempt made to obtain a general license or permission for the use of 920 such proprietary rights by implementers or users of this 921 specification can be obtained from the IETF on-line IPR repository at 922 http://www.ietf.org/ipr. 924 The IETF invites any interested party to bring to its attention any 925 copyrights, patents or patent applications, or other proprietary 926 rights that may cover technology that may be required to implement 927 this standard. Please address the information to the IETF at ietf- 928 ipr@ietf.org. 930 APPENDIX A: Creating Modified EUI-64 format Interface Identifiers 931 ------------------------------------------------------------------ 933 Depending on the characteristics of a specific link or node there are 934 a number of approaches for creating Modified EUI-64 format interface 935 identifiers. This appendix describes some of these approaches. 937 Links or Nodes with IEEE EUI-64 Identifiers 939 The only change needed to transform an IEEE EUI-64 identifier to an 940 interface identifier is to invert the "u" (universal/local) bit. For 941 example, a globally unique IEEE EUI-64 identifier of the form: 943 |0 1|1 3|3 4|4 6| 944 |0 5|6 1|2 7|8 3| 945 +----------------+----------------+----------------+----------------+ 946 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 947 +----------------+----------------+----------------+----------------+ 949 where "c" are the bits of the assigned company_id, "0" is the value 950 of the universal/local bit to indicate universal scope, "g" is 951 individual/group bit, and "m" are the bits of the manufacturer- 952 selected extension identifier. The IPv6 interface identifier would 953 be of the form: 955 |0 1|1 3|3 4|4 6| 956 |0 5|6 1|2 7|8 3| 957 +----------------+----------------+----------------+----------------+ 958 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 959 +----------------+----------------+----------------+----------------+ 961 The only change is inverting the value of the universal/local bit. 963 Links or Nodes with IEEE 802 48 bit MAC's 965 [EUI64] defines a method to create a IEEE EUI-64 identifier from an 966 IEEE 48bit MAC identifier. This is to insert two octets, with 967 hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC 968 (between the company_id and vendor supplied id). For example the 48 969 bit IEEE MAC with global scope: 971 |0 1|1 3|3 4| 972 |0 5|6 1|2 7| 973 +----------------+----------------+----------------+ 974 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 975 +----------------+----------------+----------------+ 977 where "c" are the bits of the assigned company_id, "0" is the value 978 of the universal/local bit to indicate global scope, "g" is 979 individual/group bit, and "m" are the bits of the manufacturer- 980 selected extension identifier. The interface identifier would be of 981 the form: 983 |0 1|1 3|3 4|4 6| 984 |0 5|6 1|2 7|8 3| 985 +----------------+----------------+----------------+----------------+ 986 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 987 +----------------+----------------+----------------+----------------+ 989 When IEEE 802 48bit MAC addresses are available (on an interface or a 990 node), an implementation may use them to create interface identifiers 991 due to their availability and uniqueness properties. 993 Links with Other Kinds of Identifiers 995 There are a number of types of links that have link-layer interface 996 identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples 997 include LocalTalk and Arcnet. The method to create an Modified 998 EUI-64 format identifier is to take the link identifier (e.g., the 999 LocalTalk 8 bit node identifier) and zero fill it to the left. For 1000 example a LocalTalk 8 bit node identifier of hexadecimal value 0x4F 1001 results in the following interface identifier: 1003 |0 1|1 3|3 4|4 6| 1004 |0 5|6 1|2 7|8 3| 1005 +----------------+----------------+----------------+----------------+ 1006 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 1007 +----------------+----------------+----------------+----------------+ 1009 Note that this results in the universal/local bit set to "0" to 1010 indicate local scope. 1012 Links without Identifiers 1014 There are a number of links that do not have any type of built-in 1015 identifier. The most common of these are serial links and configured 1016 tunnels. Interface identifiers must be chosen that are unique within 1017 a subnet-prefix. 1019 When no built-in identifier is available on a link the preferred 1020 approach is to use a universal interface identifier from another 1021 interface or one which is assigned to the node itself. When using 1022 this approach no other interface connecting the same node to the same 1023 subnet-prefix may use the same identifier. 1025 If there is no universal interface identifier available for use on 1026 the link the implementation needs to create a local-scope interface 1027 identifier. The only requirement is that it be unique within a 1028 subnet prefix. There are many possible approaches to select a 1029 subnet-prefix-unique interface identifier. These include: 1031 Manual Configuration 1032 Node Serial Number 1033 Other node-specific token 1035 The subnet-prefix-unique interface identifier should be generated in 1036 a manner that it does not change after a reboot of a node or if 1037 interfaces are added or deleted from the node. 1039 The selection of the appropriate algorithm is link and implementation 1040 dependent. The details on forming interface identifiers are defined 1041 in the appropriate "IPv6 over " specification. It is strongly 1042 recommended that a collision detection algorithm be implemented as 1043 part of any automatic algorithm. 1045 APPENDIX B: Changes from RFC-3513 1046 --------------------------------- 1048 The following changes were made from RFC-3513 "IP Version 6 1049 Addressing Architecture": 1051 o The restrictions on using IPv6 anycast addresses were removed 1052 because there is now sufficient experience with the use of anycast 1053 addresses, the issues are not specific to IPv6, and the GROW 1054 working group is working in this area. 1056 o Deprecated the Site-Local unicast prefix. Changes included 1057 - Removed Site-Local from special list of prefixes in Section 1058 2.4. 1059 - Split section titled "Local-use IPv6 Unicast Addresses" into 1060 two sections, "Link-Local IPv6 Unicast Addresses" and "Site- 1061 Local IPv6 Unicast Addresses". 1062 - Added text to new section describing Site-Local deprecation. 1064 o Changes to resolve issues raised in IAB response to Robert Elz 1065 appeal. Changes include: 1066 - Added clarification to Section 2.5 that nodes should make no 1067 assumptions about the structure of an IPv6 address. 1068 - Changed the text in Section 2.5.1 and Appendix A to refer to 1069 the modified EUI-64 format interface identifiers with the "u" 1070 bit set to one (1) as universal. 1071 - Added clarification to Section 2.5.1 that IPv6 nodes are not 1072 required to validate that interface identifiers created in 1073 modified EUI-64 format with the "u" bit set to one are unique. 1075 o Changed the reference indicated in Section 2.5.4 "Global Unicast 1076 Addresses" to RFC3587. 1078 o Removed mention of NSAP addresses in examples. 1080 o Clarified that the "x" in the textual representation can be one to 1081 four digits. 1083 o Deprecated the "IPv6 Compatible Address" because it is not being 1084 used in the IPv6 transition mechanisms. 1086 o Editorial changes.