idnits 2.17.00 (12 Aug 2021) /tmp/idnits62830/draft-ietf-ipv6-addr-arch-v4-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 910. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 916. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IPV6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 14 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 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 513, but not defined ** Obsolete undefined reference: RFC 3513 (Obsoleted by RFC 4291) == Unused Reference: 'RFC2026' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'MASGN' is defined on line 849, but no explicit reference was found in the text == Unused Reference: 'TOKEN' is defined on line 855, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'AUTH') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. 'PRIV') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 2893 (ref. 'TRAN') (Obsoleted by RFC 4213) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 February 17, 2005 S. Deering, Cisco Systems 4 IP Version 6 Addressing Architecture 6 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 or will be disclosed, and any of which I become aware will be 13 disclosed, in accordance with RFC 3668. 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 August 22, 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.......................................12 62 2.6.1 Required Anycast Address............................14 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.........................................20 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 The IPv6 transition mechanisms [TRAN] include a technique for hosts 457 and routers to dynamically tunnel IPv6 packets over IPv4 routing 458 infrastructure. IPv6 nodes that use this technique are assigned 459 special IPv6 unicast addresses that carry a global IPv4 address in 460 the low-order 32 bits. This type of address is termed an 461 "IPv4-compatible IPv6 address" and has the format: 463 | 80 bits | 16 | 32 bits | 464 +--------------------------------------+--------------------------+ 465 |0000..............................0000|0000| IPv4 address | 466 +--------------------------------------+----+---------------------+ 468 Note: The IPv4 address used in the "IPv4-compatible IPv6 address" 469 must be a globally-unique IPv4 unicast address. 471 A second type of IPv6 address which holds an embedded IPv4 address is 472 also defined. This address type is used to represent the addresses 473 of IPv4 nodes as IPv6 addresses. This type of address is termed an 474 "IPv4-mapped IPv6 address" and has the format: 476 | 80 bits | 16 | 32 bits | 477 +--------------------------------------+--------------------------+ 478 |0000..............................0000|FFFF| IPv4 address | 479 +--------------------------------------+----+---------------------+ 481 2.5.6 Link-Local IPv6 Unicast Addresses 483 Link-Local addresses are for use on a single link. Link-Local 484 addresses have the following format: 486 | 10 | 487 | bits | 54 bits | 64 bits | 488 +----------+-------------------------+----------------------------+ 489 |1111111010| 0 | interface ID | 490 +----------+-------------------------+----------------------------+ 492 Link-Local addresses are designed to be used for addressing on a 493 single link for purposes such as automatic address configuration, 494 neighbor discovery, or when no routers are present. 496 Routers must not forward any packets with link-local source or 497 destination addresses to other links. 499 2.5.7 Site-Local IPv6 Unicast Addresses 501 Site-local addresses were originally designed to be used for 502 addressing inside of a site without the need for a global prefix. 503 Site-Local addresses are now deprecated as defined in [SLDEP]. 505 Site-Local addresses have the following format: 507 | 10 | 508 | bits | 54 bits | 64 bits | 509 +----------+-------------------------+----------------------------+ 510 |1111111011| subnet ID | interface ID | 511 +----------+-------------------------+----------------------------+ 513 The special behavior of this prefix defined in [RFC3513] must no 514 longer be supported in new implementations (i.e., new implementations 515 must treat this prefix as Global Unicast). 517 Existing implementations and deployments may continue to use this 518 prefix. 520 2.6 Anycast Addresses 522 An IPv6 anycast address is an address that is assigned to more than 523 one interface (typically belonging to different nodes), with the 524 property that a packet sent to an anycast address is routed to the 525 "nearest" interface having that address, according to the routing 526 protocols' measure of distance. 528 Anycast addresses are allocated from the unicast address space, using 529 any of the defined unicast address formats. Thus, anycast addresses 530 are syntactically indistinguishable from unicast addresses. When a 531 unicast address is assigned to more than one interface, thus turning 532 it into an anycast address, the nodes to which the address is 533 assigned must be explicitly configured to know that it is an anycast 534 address. 536 For any assigned anycast address, there is a longest prefix P of that 537 address that identifies the topological region in which all 538 interfaces belonging to that anycast address reside. Within the 539 region identified by P, the anycast address must be maintained as a 540 separate entry in the routing system (commonly referred to as a "host 541 route"); outside the region identified by P, the anycast address may 542 be aggregated into the routing entry for prefix P. 544 Note that in the worst case, the prefix P of an anycast set may be 545 the null prefix, i.e., the members of the set may have no topological 546 locality. In that case, the anycast address must be maintained as a 547 separate routing entry throughout the entire Internet, which presents 548 a severe scaling limit on how many such "global" anycast sets may be 549 supported. Therefore, it is expected that support for global anycast 550 sets may be unavailable or very restricted. 552 One expected use of anycast addresses is to identify the set of 553 routers belonging to an organization providing Internet service. 554 Such addresses could be used as intermediate addresses in an IPv6 555 Routing header, to cause a packet to be delivered via a particular 556 service provider or sequence of service providers. 558 Some other possible uses are to identify the set of routers attached 559 to a particular subnet, or the set of routers providing entry into a 560 particular routing domain. 562 There is little experience with widespread, arbitrary use of Internet 563 anycast addresses, and some known complications and hazards when 564 using them in their full generality [ANYCST]. Until more experience 565 has been gained and solutions are specified, the following 566 restrictions are imposed on IPv6 anycast addresses: 568 o An anycast address must not be used as the source address of an 569 IPv6 packet. 571 o An anycast address must not be assigned to an IPv6 host, that 572 is, it may be assigned to an IPv6 router only. 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 and site-local multicast scopes span the same 652 topological regions as the corresponding unicast scopes. 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 organization-local scope is intended to span multiple 660 sites belonging to a single organization. 662 scopes labeled "(unassigned)" are available for 663 administrators to define additional multicast regions. 665 group ID identifies the multicast group, either permanent or 666 transient, within the given scope. 668 The "meaning" of a permanently-assigned multicast address is 669 independent of the scope value. For example, if the "NTP servers 670 group" is assigned a permanent multicast address with a group ID of 671 101 (hex), then: 673 FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface 674 (i.e., the same node) as the sender. 676 FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as 677 the sender. 679 FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as 680 the sender. 682 FF0E:0:0:0:0:0:0:101 means all NTP servers in the Internet. 684 Non-permanently-assigned multicast addresses are meaningful only 685 within a given scope. For example, a group identified by the non- 686 permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one 687 site bears no relationship to a group using the same address at a 688 different site, nor to a non-permanent group using the same group ID 689 with different scope, nor to a permanent group with the same group 690 ID. 692 Multicast addresses must not be used as source addresses in IPv6 693 packets or appear in any Routing header. 695 Routers must not forward any multicast packets beyond of the scope 696 indicated by the scop field in the destination multicast address. 698 Nodes must not originate a packet to a multicast address whose scop 699 field contains the reserved value 0; if such a packet is received, it 700 must be silently dropped. Nodes should not originate a packet to a 701 multicast address whose scop field contains the reserved value F; if 702 such a packet is sent or received, it must be treated the same as 703 packets destined to a global (scop E) multicast address. 705 2.7.1 Pre-Defined Multicast Addresses 707 The following well-known multicast addresses are pre-defined. The 708 group ID's defined in this section are defined for explicit scope 709 values. 711 Use of these group IDs for any other scope values, with the T flag 712 equal to 0, is not allowed. 714 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 715 FF01:0:0:0:0:0:0:0 716 FF02:0:0:0:0:0:0:0 717 FF03:0:0:0:0:0:0:0 718 FF04:0:0:0:0:0:0:0 719 FF05:0:0:0:0:0:0:0 720 FF06:0:0:0:0:0:0:0 721 FF07:0:0:0:0:0:0:0 722 FF08:0:0:0:0:0:0:0 723 FF09:0:0:0:0:0:0:0 724 FF0A:0:0:0:0:0:0:0 725 FF0B:0:0:0:0:0:0:0 726 FF0C:0:0:0:0:0:0:0 727 FF0D:0:0:0:0:0:0:0 728 FF0E:0:0:0:0:0:0:0 729 FF0F:0:0:0:0:0:0:0 731 The above multicast addresses are reserved and shall never be 732 assigned to any multicast group. 734 All Nodes Addresses: FF01:0:0:0:0:0:0:1 735 FF02:0:0:0:0:0:0:1 737 The above multicast addresses identify the group of all IPv6 nodes, 738 within scope 1 (interface-local) or 2 (link-local). 740 All Routers Addresses: FF01:0:0:0:0:0:0:2 741 FF02:0:0:0:0:0:0:2 742 FF05:0:0:0:0:0:0:2 744 The above multicast addresses identify the group of all IPv6 routers, 745 within scope 1 (interface-local), 2 (link-local), or 5 (site-local). 747 Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX 749 Solicited-node multicast address are computed as a function of a 750 node's unicast and anycast addresses. A solicited-node multicast 751 address is formed by taking the low-order 24 bits of an address 752 (unicast or anycast) and appending those bits to the prefix 753 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 754 range 756 FF02:0:0:0:0:1:FF00:0000 758 to 760 FF02:0:0:0:0:1:FFFF:FFFF 762 For example, the solicited node multicast address corresponding to 763 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 764 addresses that differ only in the high-order bits, e.g. due to 765 multiple high-order prefixes associated with different aggregations, 766 will map to the same solicited-node address thereby, reducing the 767 number of multicast addresses a node must join. 769 A node is required to compute and join (on the appropriate interface) 770 the associated Solicited-Node multicast addresses for all Unicast and 771 Anycast Addresses that have been configured for the node's interfaces 772 (manually or automatically). 774 2.8 A Node's Required Addresses 776 A host is required to recognize the following addresses as 777 identifying itself: 779 o Its required Link-Local Address for each interface. 780 o Any additional Unicast and Anycast Addresses that have been 781 configured for the node's interfaces (manually or 782 automatically). 783 o The loopback address. 784 o The All-Nodes Multicast Addresses defined in Section 2.7.1. 785 o The Solicited-Node Multicast Address for each of its unicast and 786 anycast addresses. 787 o Multicast Addresses of all other groups to which the node 788 belongs. 790 A router is required to recognize all addresses that a host is 791 required to recognize, plus the following addresses as identifying 792 itself: 794 o The Subnet-Router Anycast Addresses for all interfaces for which 795 it is configured to act as a router. 796 o All other Anycast Addresses with which the router has been 797 configured. 798 o The All-Routers Multicast Addresses defined in Section 2.7.1. 800 3. Security Considerations 802 IPv6 addressing documents do not have any direct impact on Internet 803 infrastructure security. Authentication of IPv6 packets is defined 804 in [AUTH]. 806 4. IANA Considerations 808 None. 810 5. References 812 5.1 Normative References 814 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 815 (IPv6) Specification", RFC2460, December 1998. 817 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 818 3", RFC2026, BCP00009, October 1996. 820 [SLDEP] C. Huitema, B. Carpenter, "Deprecating Site Local 821 Addresses", RFC3879, September 2004. 823 5.2 Non-Normative References 825 [ANYCST] Partridge, C., T. Mendez, and W. Milliken, "Host Anycasting 826 Service", RFC1546, November 1993. 828 [AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402, 829 November 1998. 831 [CIDR] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless Inter- 832 Domain Routing (CIDR): An Address Assignment and 833 Aggregation Strategy", RFC1519, September 1993. 835 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 836 Networks", RFC2464, December 1998. 838 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 839 Registration Authority", 840 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 841 , March 1997. 843 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 844 Networks", RFC2467, December 1998. 846 [GLOBAL] Hinden, R., S. Deering, E. Nordmark, "IPv6 Global Unicast 847 Address Format", RFC3587, August 2003. 849 [MASGN] Hinden, R., "IPv6 Multicast Address Assignments", RFC2375, 850 July 1998. 852 [PRIV] Narten, T., R. Draves, "Privacy Extensions for Stateless 853 Address Autoconfiguration in IPv6", RFC3041, January 2001. 855 [TOKEN] Crawford, M., T. Narten, S. Thomas, "Transmission of IPv6 856 Packets over Token Ring Networks", RFC2470, December 1998. 858 [TRAN] Gilligan, R., E. Nordmark, "Transition Mechanisms for IPv6 859 Hosts and Routers", RFC2893, August 2000. 861 6. Author's Addresses 863 Robert M. Hinden 864 Nokia 865 313 Fairchild Drive 866 Mountain View, CA 94043 867 USA 869 phone: +1 650 625-2004 870 email: bob.hinden@nokia.com 872 Stephen E. Deering 873 Cisco Systems, Inc. 874 170 West Tasman Drive 875 San Jose, CA 95134-1706 876 USA 878 7. Disclaimer of Validity 880 This document and the information contained herein are provided on an 881 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 882 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 883 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 884 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 885 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 886 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 888 8. Copyright Statement 890 Copyright (C) The Internet Society (2005). This document is subject 891 to the rights, licenses and restrictions contained in BCP 78, and 892 except as set forth therein, the authors retain all their rights. 894 9. Intellectual Property 896 The IETF takes no position regarding the validity or scope of any 897 Intellectual Property Rights or other rights that might be claimed to 898 pertain to the implementation or use of the technology described in 899 this document or the extent to which any license under such rights 900 might or might not be available; nor does it represent that it has 901 made any independent effort to identify any such rights. Information 902 on the procedures with respect to rights in RFC documents can be 903 found in BCP 78 and BCP 79. 905 Copies of IPR disclosures made to the IETF Secretariat and any 906 assurances of licenses to be made available, or the result of an 907 attempt made to obtain a general license or permission for the use of 908 such proprietary rights by implementers or users of this 909 specification can be obtained from the IETF on-line IPR repository at 910 http://www.ietf.org/ipr. 912 The IETF invites any interested party to bring to its attention any 913 copyrights, patents or patent applications, or other proprietary 914 rights that may cover technology that may be required to implement 915 this standard. Please address the information to the IETF at ietf- 916 ipr@ietf.org. 918 APPENDIX A: Creating Modified EUI-64 format Interface Identifiers 919 ------------------------------------------------------------------ 921 Depending on the characteristics of a specific link or node there are 922 a number of approaches for creating Modified EUI-64 format interface 923 identifiers. This appendix describes some of these approaches. 925 Links or Nodes with IEEE EUI-64 Identifiers 927 The only change needed to transform an IEEE EUI-64 identifier to an 928 interface identifier is to invert the "u" (universal/local) bit. For 929 example, a globally unique IEEE EUI-64 identifier of the form: 931 |0 1|1 3|3 4|4 6| 932 |0 5|6 1|2 7|8 3| 933 +----------------+----------------+----------------+----------------+ 934 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 935 +----------------+----------------+----------------+----------------+ 937 where "c" are the bits of the assigned company_id, "0" is the value 938 of the universal/local bit to indicate universal scope, "g" is 939 individual/group bit, and "m" are the bits of the manufacturer- 940 selected extension identifier. The IPv6 interface identifier would 941 be of the form: 943 |0 1|1 3|3 4|4 6| 944 |0 5|6 1|2 7|8 3| 945 +----------------+----------------+----------------+----------------+ 946 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 947 +----------------+----------------+----------------+----------------+ 949 The only change is inverting the value of the universal/local bit. 951 Links or Nodes with IEEE 802 48 bit MAC's 953 [EUI64] defines a method to create a IEEE EUI-64 identifier from an 954 IEEE 48bit MAC identifier. This is to insert two octets, with 955 hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC 956 (between the company_id and vendor supplied id). For example the 48 957 bit IEEE MAC with global scope: 959 |0 1|1 3|3 4| 960 |0 5|6 1|2 7| 961 +----------------+----------------+----------------+ 962 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 963 +----------------+----------------+----------------+ 965 where "c" are the bits of the assigned company_id, "0" is the value 966 of the universal/local bit to indicate global scope, "g" is 967 individual/group bit, and "m" are the bits of the manufacturer- 968 selected extension identifier. The interface identifier would be of 969 the form: 971 |0 1|1 3|3 4|4 6| 972 |0 5|6 1|2 7|8 3| 973 +----------------+----------------+----------------+----------------+ 974 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 975 +----------------+----------------+----------------+----------------+ 977 When IEEE 802 48bit MAC addresses are available (on an interface or a 978 node), an implementation may use them to create interface identifiers 979 due to their availability and uniqueness properties. 981 Links with Other Kinds of Identifiers 983 There are a number of types of links that have link-layer interface 984 identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples 985 include LocalTalk and Arcnet. The method to create an Modified 986 EUI-64 format identifier is to take the link identifier (e.g., the 987 LocalTalk 8 bit node identifier) and zero fill it to the left. For 988 example a LocalTalk 8 bit node identifier of hexadecimal value 0x4F 989 results in the following interface identifier: 991 |0 1|1 3|3 4|4 6| 992 |0 5|6 1|2 7|8 3| 993 +----------------+----------------+----------------+----------------+ 994 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 995 +----------------+----------------+----------------+----------------+ 997 Note that this results in the universal/local bit set to "0" to 998 indicate local scope. 1000 Links without Identifiers 1002 There are a number of links that do not have any type of built-in 1003 identifier. The most common of these are serial links and configured 1004 tunnels. Interface identifiers must be chosen that are unique within 1005 a subnet-prefix. 1007 When no built-in identifier is available on a link the preferred 1008 approach is to use a universal interface identifier from another 1009 interface or one which is assigned to the node itself. When using 1010 this approach no other interface connecting the same node to the same 1011 subnet-prefix may use the same identifier. 1013 If there is no universal interface identifier available for use on 1014 the link the implementation needs to create a local-scope interface 1015 identifier. The only requirement is that it be unique within a 1016 subnet prefix. There are many possible approaches to select a 1017 subnet-prefix-unique interface identifier. These include: 1019 Manual Configuration 1020 Node Serial Number 1021 Other node-specific token 1023 The subnet-prefix-unique interface identifier should be generated in 1024 a manner that it does not change after a reboot of a node or if 1025 interfaces are added or deleted from the node. 1027 The selection of the appropriate algorithm is link and implementation 1028 dependent. The details on forming interface identifiers are defined 1029 in the appropriate "IPv6 over " specification. It is strongly 1030 recommended that a collision detection algorithm be implemented as 1031 part of any automatic algorithm. 1033 APPENDIX B: Changes from RFC-3513 1034 --------------------------------- 1036 The following changes were made from RFC-3513 "IP Version 6 1037 Addressing Architecture": 1039 o Deprecated the Site-Local prefix. Changes included 1040 - Removed Site-Local from special list of prefixes in Section 1041 2.4. 1042 - Split section titled "Local-use IPv6 Unicast Addresses" into 1043 two sections, "Link-Local IPv6 Unicast Addresses" and "Site- 1044 Local IPv6 Unicast Addresses". 1045 - Added text to new section describing Site-Local deprecation. 1047 o Changes to resolve issues raised in IAB response to Robert Elz 1048 appeal. Changes include: 1049 - Added clarification to Section 2.5 that nodes should make no 1050 assumptions about the structure of an IPv6 address. 1051 - Changed the text in Section 2.5.1 and Appendix A to refer to 1052 the modified EUI-64 format interface identifiers with the "u" 1053 bit set to one (1) as universal. 1054 - Added clarification to Section 2.5.1 that IPv6 nodes are not 1055 required to validate that interface identifiers created in 1056 modified EUI-64 format with the "u" bit set to one are unique. 1058 o Changed the reference indicated in Section 2.5.4 "Global Unicast 1059 Addresses" to RFC3587. 1061 o Removed mention of NSAP addresses in examples. 1063 o Clarified that the "x" in the textual representation can be one to 1064 four digits. 1066 o Editorial changes.