idnits 2.17.1 draft-ietf-ipv6-addr-arch-v4-04.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 907. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 924. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 931. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 937. ** 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 : ---------------------------------------------------------------------------- == 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 821, but not defined ** Obsolete undefined reference: RFC 3513 (Obsoleted by RFC 4291) -- Looks like a reference, but probably isn't: '1' on line 821 -- Looks like a reference, but probably isn't: '5' on line 826 == Unused Reference: 'RFC2026' is defined on line 840, 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) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 May 20, 2005 S. Deering, Cisco Systems 3 Obsoletes: RFC3513 5 IP Version 6 Addressing Architecture 7 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 November 25, 2005. 34 Abstract 36 This specification defines the addressing architecture of the IP 37 Version 6 protocol. The document includes the IPv6 addressing model, 38 text representations of IPv6 addresses, definition of IPv6 unicast 39 addresses, anycast addresses, and multicast addresses, and an IPv6 40 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............................13 64 2.7 Multicast Addresses.....................................14 65 2.7.1 Pre-Defined Multicast Addresses.....................16 66 2.8 A Node's Required Addresses.............................18 68 3. Security Considerations.....................................18 70 4. IANA Considerations.........................................19 72 5. References..................................................19 74 6. Author's Addresses..........................................20 76 7. Disclaimer of Validity......................................20 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 previous 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 2.6.1 Required Anycast Address 577 The Subnet-Router anycast address is predefined. Its format is as 578 follows: 580 | n bits | 128-n bits | 581 +------------------------------------------------+----------------+ 582 | subnet prefix | 00000000000000 | 583 +------------------------------------------------+----------------+ 585 The "subnet prefix" in an anycast address is the prefix which 586 identifies a specific link. This anycast address is syntactically 587 the same as a unicast address for an interface on the link with the 588 interface identifier set to zero. 590 Packets sent to the Subnet-Router anycast address will be delivered 591 to one router on the subnet. All routers are required to support the 592 Subnet-Router anycast addresses for the subnets to which they have 593 interfaces. 595 The subnet-router anycast address is intended to be used for 596 applications where a node needs to communicate with any one of the 597 set of routers. 599 2.7 Multicast Addresses 601 An IPv6 multicast address is an identifier for a group of interfaces 602 (typically on different nodes). An interface may belong to any 603 number of multicast groups. Multicast addresses have the following 604 format: 606 | 8 | 4 | 4 | 112 bits | 607 +------ -+----+----+---------------------------------------------+ 608 |11111111|flgs|scop| group ID | 609 +--------+----+----+---------------------------------------------+ 611 binary 11111111 at the start of the address identifies the address 612 as being a multicast address. 614 +-+-+-+-+ 615 flgs is a set of 4 flags: |0|R|P|T| 616 +-+-+-+-+ 618 The high-order flag is reserved, and must be initialized to 0. 620 T = 0 indicates a permanently-assigned ("well-known") multicast 621 address, assigned by the Internet Assigned Number Authority 622 (IANA). 624 T = 1 indicates a non-permanently-assigned ("transient" or 625 "dynamically" assigned) multicast address. 627 The P flag's definition and usage can be found in [RFC3306]. 629 The R flag's definition and usage can be found in [RFC3956]. 631 scop is a 4-bit multicast scope value used to limit the scope of 632 the multicast group. The values are: 634 0 reserved 635 1 interface-local scope 636 2 link-local scope 637 3 reserved 638 4 admin-local scope 639 5 site-local scope 640 6 (unassigned) 641 7 (unassigned) 642 8 organization-local scope 643 9 (unassigned) 644 A (unassigned) 645 B (unassigned) 646 C (unassigned) 647 D (unassigned) 648 E global scope 649 F reserved 651 interface-local scope spans only a single interface on a 652 node, and is useful only for loopback transmission of 653 multicast. 655 link-local multicast scope spans the same 656 topological region as the corresponding unicast scope. 658 admin-local scope is the smallest scope that must be 659 administratively configured, i.e., not automatically 660 derived from physical connectivity or other, non- 661 multicast-related configuration. 663 site-local scope is intended to span a single site. 665 organization-local scope is intended to span multiple 666 sites belonging to a single organization. 668 scopes labeled "(unassigned)" are available for 669 administrators to define additional multicast regions. 671 group ID identifies the multicast group, either permanent or 672 transient, within the given scope. Additional definitions of the 673 multicast group ID field structure is defined in [RFC3306]. 675 The "meaning" of a permanently-assigned multicast address is 676 independent of the scope value. For example, if the "NTP servers 677 group" is assigned a permanent multicast address with a group ID of 678 101 (hex), then: 680 FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface 681 (i.e., the same node) as the sender. 683 FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the 684 sender. 686 FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the 687 sender. 689 FF0E:0:0:0:0:0:0:101 means all NTP servers in the Internet. 691 Non-permanently-assigned multicast addresses are meaningful only 692 within a given scope. For example, a group identified by the non- 693 permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one 694 site bears no relationship to a group using the same address at a 695 different site, nor to a non-permanent group using the same group ID 696 with different scope, nor to a permanent group with the same group 697 ID. 699 Multicast addresses must not be used as source addresses in IPv6 700 packets or appear in any Routing header. 702 Routers must not forward any multicast packets beyond of the scope 703 indicated by the scop field in the destination multicast address. 705 Nodes must not originate a packet to a multicast address whose scop 706 field contains the reserved value 0; if such a packet is received, it 707 must be silently dropped. Nodes should not originate a packet to a 708 multicast address whose scop field contains the reserved value F; if 709 such a packet is sent or received, it must be treated the same as 710 packets destined to a global (scop E) multicast address. 712 2.7.1 Pre-Defined Multicast Addresses 714 The following well-known multicast addresses are pre-defined. The 715 group ID's defined in this section are defined for explicit scope 716 values. 718 Use of these group IDs for any other scope values, with the T flag 719 equal to 0, is not allowed. 721 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 722 FF01:0:0:0:0:0:0:0 723 FF02:0:0:0:0:0:0:0 724 FF03:0:0:0:0:0:0:0 725 FF04:0:0:0:0:0:0:0 726 FF05:0:0:0:0:0:0:0 727 FF06:0:0:0:0:0:0:0 728 FF07:0:0:0:0:0:0:0 729 FF08:0:0:0:0:0:0:0 730 FF09:0:0:0:0:0:0:0 731 FF0A:0:0:0:0:0:0:0 732 FF0B:0:0:0:0:0:0:0 733 FF0C:0:0:0:0:0:0:0 734 FF0D:0:0:0:0:0:0:0 735 FF0E:0:0:0:0:0:0:0 736 FF0F:0:0:0:0:0:0:0 738 The above multicast addresses are reserved and shall never be 739 assigned to any multicast group. 741 All Nodes Addresses: FF01:0:0:0:0:0:0:1 742 FF02:0:0:0:0:0:0:1 744 The above multicast addresses identify the group of all IPv6 nodes, 745 within scope 1 (interface-local) or 2 (link-local). 747 All Routers Addresses: FF01:0:0:0:0:0:0:2 748 FF02:0:0:0:0:0:0:2 749 FF05:0:0:0:0:0:0:2 751 The above multicast addresses identify the group of all IPv6 routers, 752 within scope 1 (interface-local), 2 (link-local), or 5 (site-local). 754 Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX 756 Solicited-node multicast address are computed as a function of a 757 node's unicast and anycast addresses. A solicited-node multicast 758 address is formed by taking the low-order 24 bits of an address 759 (unicast or anycast) and appending those bits to the prefix 760 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 761 range 763 FF02:0:0:0:0:1:FF00:0000 765 to 767 FF02:0:0:0:0:1:FFFF:FFFF 769 For example, the solicited node multicast address corresponding to 770 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 771 addresses that differ only in the high-order bits, e.g. due to 772 multiple high-order prefixes associated with different aggregations, 773 will map to the same solicited-node address thereby, reducing the 774 number of multicast addresses a node must join. 776 A node is required to compute and join (on the appropriate interface) 777 the associated Solicited-Node multicast addresses for all Unicast and 778 Anycast Addresses that have been configured for the node's interfaces 779 (manually or automatically). 781 2.8 A Node's Required Addresses 783 A host is required to recognize the following addresses as 784 identifying itself: 786 o Its required Link-Local Address for each interface. 787 o Any additional Unicast and Anycast Addresses that have been 788 configured for the node's interfaces (manually or 789 automatically). 790 o The loopback address. 791 o The All-Nodes Multicast Addresses defined in Section 2.7.1. 792 o The Solicited-Node Multicast Address for each of its unicast and 793 anycast addresses. 794 o Multicast Addresses of all other groups to which the node 795 belongs. 797 A router is required to recognize all addresses that a host is 798 required to recognize, plus the following addresses as identifying 799 itself: 801 o The Subnet-Router Anycast Addresses for all interfaces for which 802 it is configured to act as a router. 803 o All other Anycast Addresses with which the router has been 804 configured. 805 o The All-Routers Multicast Addresses defined in Section 2.7.1. 807 3. Security Considerations 809 IPv6 addressing documents do not have any direct impact on Internet 810 infrastructure security. Authentication of IPv6 packets is defined 811 in [AUTH]. 813 4. IANA Considerations 815 The "IPv4-compatible IPv6 address" is deprecated by this document. 816 The IANA should continue to list the address block containing these 817 addresses at http://www.iana.org/assignments/ipv6-address-space as 818 "Reserved by IETF" and not reassign it for any other purpose. For 819 example: 821 0000::/8 Reserved by IETF [RFC3513] [1] 823 The IANA is requested to add the following note and link it to this 824 address block. 826 [5] 0000::/96 was previously defined as the "IPv4-compatible IPv6 827 address" prefix. This definition has been deprecated by 828 [RFC-ietf-ipv6-addr-arch-v4-04.txt]. 830 The IANA is requested to update the references for the IPv6 Address 831 Architecture in the IANA registries to this RFC when it is published. 833 5. References 835 5.1 Normative References 837 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 838 (IPv6) Specification", RFC2460, December 1998. 840 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 841 3", RFC2026, BCP00009, October 1996. 843 5.2 Non-Normative References 845 [AUTH] Kent, S., and R. Atkinson, "IP Authentication Header", 846 RFC2402, November 1998. 848 [CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless 849 Inter-Domain Routing (CIDR): An Address Assignment and 850 Aggregation Strategy", RFC1519, September 1993. 852 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 853 Networks", RFC2464, December 1998. 855 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 856 Registration Authority", 857 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, 858 March 1997. 860 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 861 Networks", RFC2467, December 1998. 863 [GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 864 Unicast Address Format", RFC3587, August 2003. 866 [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless 867 Address Autoconfiguration in IPv6", RFC3041, January 2001. 869 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 870 Multicast Addresses", RFC 3306, August 2002. 872 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point 873 (RP) Address in an IPv6 Multicast Address", RFC 3956, 874 November 2004. 876 [RFC4038] Shin, M-K., et. al., "Application Aspects of IPv6 877 Transition", RFC4038, March 2005. 879 [SLDEP] Huitema, C. and B. Carpenter, "Deprecating Site Local 880 Addresses", RFC3879, September 2004. 882 6. Author's Addresses 884 Robert M. Hinden 885 Nokia 886 313 Fairchild Drive 887 Mountain View, CA 94043 888 USA 890 phone: +1 650 625-2004 891 email: bob.hinden@nokia.com 893 Stephen E. Deering 894 Cisco Systems, Inc. 895 170 West Tasman Drive 896 San Jose, CA 95134-1706 897 USA 899 7. Disclaimer of Validity 901 This document and the information contained herein are provided on an 902 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 903 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 904 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 905 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 906 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 907 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 909 8. Copyright Statement 911 Copyright (C) The Internet Society (2005). This document is subject 912 to the rights, licenses and restrictions contained in BCP 78, and 913 except as set forth therein, the authors retain all their rights. 915 9. Intellectual Property 917 The IETF takes no position regarding the validity or scope of any 918 Intellectual Property Rights or other rights that might be claimed to 919 pertain to the implementation or use of the technology described in 920 this document or the extent to which any license under such rights 921 might or might not be available; nor does it represent that it has 922 made any independent effort to identify any such rights. Information 923 on the procedures with respect to rights in RFC documents can be 924 found in BCP 78 and BCP 79. 926 Copies of IPR disclosures made to the IETF Secretariat and any 927 assurances of licenses to be made available, or the result of an 928 attempt made to obtain a general license or permission for the use of 929 such proprietary rights by implementers or users of this 930 specification can be obtained from the IETF on-line IPR repository at 931 http://www.ietf.org/ipr. 933 The IETF invites any interested party to bring to its attention any 934 copyrights, patents or patent applications, or other proprietary 935 rights that may cover technology that may be required to implement 936 this standard. Please address the information to the IETF at ietf- 937 ipr@ietf.org. 939 APPENDIX A: Creating Modified EUI-64 format Interface Identifiers 940 ------------------------------------------------------------------ 942 Depending on the characteristics of a specific link or node there are 943 a number of approaches for creating Modified EUI-64 format interface 944 identifiers. This appendix describes some of these approaches. 946 Links or Nodes with IEEE EUI-64 Identifiers 948 The only change needed to transform an IEEE EUI-64 identifier to an 949 interface identifier is to invert the "u" (universal/local) bit. For 950 example, a globally unique IEEE EUI-64 identifier of the form: 952 |0 1|1 3|3 4|4 6| 953 |0 5|6 1|2 7|8 3| 954 +----------------+----------------+----------------+----------------+ 955 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 956 +----------------+----------------+----------------+----------------+ 958 where "c" are the bits of the assigned company_id, "0" is the value 959 of the universal/local bit to indicate universal scope, "g" is 960 individual/group bit, and "m" are the bits of the manufacturer- 961 selected extension identifier. The IPv6 interface identifier would 962 be of the form: 964 |0 1|1 3|3 4|4 6| 965 |0 5|6 1|2 7|8 3| 966 +----------------+----------------+----------------+----------------+ 967 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 968 +----------------+----------------+----------------+----------------+ 970 The only change is inverting the value of the universal/local bit. 972 Links or Nodes with IEEE 802 48 bit MAC's 974 [EUI64] defines a method to create a IEEE EUI-64 identifier from an 975 IEEE 48bit MAC identifier. This is to insert two octets, with 976 hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC 977 (between the company_id and vendor supplied id). For example the 48 978 bit IEEE MAC with global scope: 980 |0 1|1 3|3 4| 981 |0 5|6 1|2 7| 982 +----------------+----------------+----------------+ 983 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 984 +----------------+----------------+----------------+ 986 where "c" are the bits of the assigned company_id, "0" is the value 987 of the universal/local bit to indicate global scope, "g" is 988 individual/group bit, and "m" are the bits of the manufacturer- 989 selected extension identifier. The interface identifier would be of 990 the form: 992 |0 1|1 3|3 4|4 6| 993 |0 5|6 1|2 7|8 3| 994 +----------------+----------------+----------------+----------------+ 995 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 996 +----------------+----------------+----------------+----------------+ 998 When IEEE 802 48bit MAC addresses are available (on an interface or a 999 node), an implementation may use them to create interface identifiers 1000 due to their availability and uniqueness properties. 1002 Links with Other Kinds of Identifiers 1004 There are a number of types of links that have link-layer interface 1005 identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples 1006 include LocalTalk and Arcnet. The method to create an Modified 1007 EUI-64 format identifier is to take the link identifier (e.g., the 1008 LocalTalk 8 bit node identifier) and zero fill it to the left. For 1009 example a LocalTalk 8 bit node identifier of hexadecimal value 0x4F 1010 results in the following interface identifier: 1012 |0 1|1 3|3 4|4 6| 1013 |0 5|6 1|2 7|8 3| 1014 +----------------+----------------+----------------+----------------+ 1015 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 1016 +----------------+----------------+----------------+----------------+ 1018 Note that this results in the universal/local bit set to "0" to 1019 indicate local scope. 1021 Links without Identifiers 1023 There are a number of links that do not have any type of built-in 1024 identifier. The most common of these are serial links and configured 1025 tunnels. Interface identifiers must be chosen that are unique within 1026 a subnet-prefix. 1028 When no built-in identifier is available on a link the preferred 1029 approach is to use a universal interface identifier from another 1030 interface or one which is assigned to the node itself. When using 1031 this approach no other interface connecting the same node to the same 1032 subnet-prefix may use the same identifier. 1034 If there is no universal interface identifier available for use on 1035 the link the implementation needs to create a local-scope interface 1036 identifier. The only requirement is that it be unique within a 1037 subnet prefix. There are many possible approaches to select a 1038 subnet-prefix-unique interface identifier. These include: 1040 Manual Configuration 1041 Node Serial Number 1042 Other node-specific token 1044 The subnet-prefix-unique interface identifier should be generated in 1045 a manner that it does not change after a reboot of a node or if 1046 interfaces are added or deleted from the node. 1048 The selection of the appropriate algorithm is link and implementation 1049 dependent. The details on forming interface identifiers are defined 1050 in the appropriate "IPv6 over " specification. It is strongly 1051 recommended that a collision detection algorithm be implemented as 1052 part of any automatic algorithm. 1054 APPENDIX B: Changes from RFC-3513 1055 --------------------------------- 1057 The following changes were made from RFC-3513 "IP Version 6 1058 Addressing Architecture": 1060 o The restrictions on using IPv6 anycast addresses were removed 1061 because there is now sufficient experience with the use of anycast 1062 addresses, the issues are not specific to IPv6, and the GROW 1063 working group is working in this area. 1065 o Deprecated the Site-Local unicast prefix. Changes included 1066 - Removed Site-Local from special list of prefixes in Section 1067 2.4. 1068 - Split section titled "Local-use IPv6 Unicast Addresses" into 1069 two sections, "Link-Local IPv6 Unicast Addresses" and "Site- 1070 Local IPv6 Unicast Addresses". 1071 - Added text to new section describing Site-Local deprecation. 1073 o Changes to resolve issues raised in IAB response to Robert Elz 1074 appeal. Changes include: 1075 - Added clarification to Section 2.5 that nodes should make no 1076 assumptions about the structure of an IPv6 address. 1077 - Changed the text in Section 2.5.1 and Appendix A to refer to 1078 the modified EUI-64 format interface identifiers with the "u" 1079 bit set to one (1) as universal. 1080 - Added clarification to Section 2.5.1 that IPv6 nodes are not 1081 required to validate that interface identifiers created in 1082 modified EUI-64 format with the "u" bit set to one are unique. 1084 o Changed the reference indicated in Section 2.5.4 "Global Unicast 1085 Addresses" to RFC3587. 1087 o Removed mention of NSAP addresses in examples. 1089 o Clarified that the "x" in the textual representation can be one to 1090 four digits. 1092 o Deprecated the "IPv6 Compatible Address" because it is not being 1093 used in the IPv6 transition mechanisms. 1095 o Added the "R" and "P" flags to Section 2.7 on Multicast addresses, 1096 and pointers to the documents that define them. 1098 o Editorial changes.