idnits 2.17.1 draft-ietf-ipv6-addr-arch-v4-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IPV6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 21 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 214 has weird spacing: '...address is ...' == Line 217 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 502, but not defined ** Obsolete undefined reference: RFC 3513 (Obsoleted by RFC 4291) == Unused Reference: 'MASGN' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'TOKEN' is defined on line 1008, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'SLDEP' -- 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 1888 (ref. 'NSAP') (Obsoleted by RFC 4048) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. 'PRIV') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 2893 (ref. 'TRAN') (Obsoleted by RFC 4213) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 October 9, 2003 S. Deering, Cisco Systems 4 IP Version 6 Addressing Architecture 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of [RFC2026]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the list Internet-Draft Shadow Directories, see 24 http://www.ietf.org/shadow.html. 26 This Internet Draft expires May 14, 2004. 28 Abstract 30 This specification defines the addressing architecture of the IP 31 Version 6 protocol [IPV6]. The document includes the IPv6 addressing 32 model, text representations of IPv6 addresses, definition of IPv6 33 unicast addresses, anycast addresses, and multicast addresses, and an 34 IPv6 node's required addresses. 36 This document obsoletes RFC-3513 "IP Version 6 Addressing 37 Architecture". 39 Table of Contents 41 1. Introduction.................................................3 43 2. IPv6 Addressing..............................................3 44 2.1 Addressing Model.........................................4 45 2.2 Text Representation of Addresses.........................4 46 2.3 Text Representation of Address Prefixes..................5 47 2.4 Address Type Identification..............................7 48 2.5 Unicast Addresses........................................7 49 2.5.1 Interface Identifiers................................8 50 2.5.2 The Unspecified Address.............................10 51 2.5.3 The Loopback Address................................10 52 2.5.4 Global Unicast Addresses............................10 53 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.........11 54 2.5.6 Link-Local IPv6 Unicast Addresses...................12 55 2.5.7 Site-Local IPv6 Unicast Addresses...................12 56 2.6 Anycast Addresses.......................................12 57 2.6.1 Required Anycast Address............................14 58 2.7 Multicast Addresses.....................................14 59 2.7.1 Pre-Defined Multicast Addresses.....................16 60 2.8 A Node's Required Addresses.............................18 62 3. Security Considerations.....................................18 64 4. IANA Considerations.........................................19 66 APPENDIX A: Creating Modified EUI-64 format Interface IDs......20 68 APPENDIX B: Changes from RFC-3513..............................23 70 REFERENCES.....................................................24 72 AUTHOR'S ADDRESSES.............................................25 74 1.0 INTRODUCTION 76 This specification defines the addressing architecture of the IP 77 Version 6 protocol. It includes the basic formats for the various 78 types of IPv6 addresses (unicast, anycast, and multicast). 80 The authors would like to acknowledge the contributions of Paul 81 Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, 82 Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, 83 Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg 84 Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, 85 Sue Thomson, Markku Savela, and Larry Masinter. 87 2.0 IPv6 ADDRESSING 89 IPv6 addresses are 128-bit identifiers for interfaces and sets of 90 interfaces (where "interface" is as defined in section 2 of [IPV6]). 91 There are three types of addresses: 93 Unicast: An identifier for a single interface. A packet sent to a 94 unicast address is delivered to the interface identified 95 by that address. 97 Anycast: An identifier for a set of interfaces (typically 98 belonging to different nodes). A packet sent to an 99 anycast address is delivered to one of the interfaces 100 identified by that address (the "nearest" one, according 101 to the routing protocols' measure of distance). 103 Multicast: An identifier for a set of interfaces (typically 104 belonging to different nodes). A packet sent to a 105 multicast address is delivered to all interfaces 106 identified by that address. 108 There are no broadcast addresses in IPv6, their function being 109 superseded by multicast addresses. 111 In this document, fields in addresses are given a specific name, for 112 example "subnet". When this name is used with the term "ID" for 113 identifier after the name (e.g., "subnet ID"), it refers to the 114 contents of the named field. When it is used with the term "prefix" 115 (e.g., "subnet prefix") it refers to all of the address from the left 116 up to and including this field. 118 In IPv6, all zeros and all ones are legal values for any field, 119 unless specifically excluded. Specifically, prefixes may contain, or 120 end with, zero-valued fields. 122 2.1 Addressing Model 124 IPv6 addresses of all types are assigned to interfaces, not nodes. 125 An IPv6 unicast address refers to a single interface. Since each 126 interface belongs to a single node, any of that node's interfaces' 127 unicast addresses may be used as an identifier for the node. 129 All interfaces are required to have at least one link-local unicast 130 address (see section 2.8 for additional required addresses). A 131 single interface may also have multiple IPv6 addresses of any type 132 (unicast, anycast, and multicast) or scope. Unicast addresses with 133 scope greater than link-scope are not needed for interfaces that are 134 not used as the origin or destination of any IPv6 packets to or from 135 non-neighbors. This is sometimes convenient for point-to-point 136 interfaces. There is one exception to this addressing model: 138 A unicast address or a set of unicast addresses may be assigned to 139 multiple physical interfaces if the implementation treats the 140 multiple physical interfaces as one interface when presenting it 141 to the internet layer. This is useful for load-sharing over 142 multiple physical interfaces. 144 Currently IPv6 continues the IPv4 model that a subnet prefix is 145 associated with one link. Multiple subnet prefixes may be assigned 146 to the same link. 148 2.2 Text Representation of Addresses 150 There are three conventional forms for representing IPv6 addresses as 151 text strings: 153 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the 154 hexadecimal values of the eight 16-bit pieces of the address. 155 Examples: 157 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 159 1080:0:0:0:8:800:200C:417A 161 Note that it is not necessary to write the leading zeros in an 162 individual field, but there must be at least one numeral in every 163 field (except for the case described in 2.). 165 2. Due to some methods of allocating certain styles of IPv6 166 addresses, it will be common for addresses to contain long strings 167 of zero bits. In order to make writing addresses containing zero 168 bits easier a special syntax is available to compress the zeros. 169 The use of "::" indicates one or more groups of 16 bits of zeros. 170 The "::" can only appear once in an address. The "::" can also be 171 used to compress leading or trailing zeros in an address. 173 For example the following addresses: 175 1080:0:0:0:8:800:200C:417A a unicast address 176 FF01:0:0:0:0:0:0:101 a multicast address 177 0:0:0:0:0:0:0:1 the loopback address 178 0:0:0:0:0:0:0:0 the unspecified addresses 180 may be represented as: 182 1080::8:800:200C:417A a unicast address 183 FF01::101 a multicast address 184 ::1 the loopback address 185 :: the unspecified addresses 187 3. An alternative form that is sometimes more convenient when dealing 188 with a mixed environment of IPv4 and IPv6 nodes is 189 x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of 190 the six high-order 16-bit pieces of the address, and the 'd's are 191 the decimal values of the four low-order 8-bit pieces of the 192 address (standard IPv4 representation). Examples: 194 0:0:0:0:0:0:13.1.68.3 196 0:0:0:0:0:FFFF:129.144.52.38 198 or in compressed form: 200 ::13.1.68.3 202 ::FFFF:129.144.52.38 204 2.3 Text Representation of Address Prefixes 206 The text representation of IPv6 address prefixes is similar to the 207 way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An 208 IPv6 address prefix is represented by the notation: 210 ipv6-address/prefix-length 212 where 214 ipv6-address is an IPv6 address in any of the notations listed 215 in section 2.2. 217 prefix-length is a decimal value specifying how many of the 218 leftmost contiguous bits of the address comprise 219 the prefix. 221 For example, the following are legal representations of the 60-bit 222 prefix 12AB00000000CD3 (hexadecimal): 224 12AB:0000:0000:CD30:0000:0000:0000:0000/60 225 12AB::CD30:0:0:0:0/60 226 12AB:0:0:CD30::/60 228 The following are NOT legal representations of the above prefix: 230 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, 231 within any 16-bit chunk of the address 233 12AB::CD30/60 address to left of "/" expands to 234 12AB:0000:0000:0000:0000:000:0000:CD30 236 12AB::CD3/60 address to left of "/" expands to 237 12AB:0000:0000:0000:0000:000:0000:0CD3 239 When writing both a node address and a prefix of that node address 240 (e.g., the node's subnet prefix), the two can combined as follows: 242 the node address 12AB:0:0:CD30:123:4567:89AB:CDEF 243 and its subnet number 12AB:0:0:CD30::/60 245 can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 247 2.4 Address Type Identification 249 The type of an IPv6 address is identified by the high-order bits of 250 the address, as follows: 252 Address type Binary prefix IPv6 notation Section 253 ------------ ------------- ------------- ------- 254 Unspecified 00...0 (128 bits) ::/128 2.5.2 255 Loopback 00...1 (128 bits) ::1/128 2.5.3 256 Multicast 11111111 FF00::/8 2.7 257 Link-local unicast 1111111010 FE80::/10 2.5.6 258 Global unicast (everything else) 260 Anycast addresses are taken from the unicast address spaces (of any 261 scope) and are not syntactically distinguishable from unicast 262 addresses. 264 The general format of global unicast addresses is described in 265 section 2.5.4. Some special-purpose subtypes of global unicast 266 addresses which contain embedded IPv4 addresses (for the purposes of 267 IPv4-IPv6 interoperation) are described in section 2.5.5. 269 Future specifications may redefine one or more sub-ranges of the 270 global unicast space for other purposes, but unless and until that 271 happens, implementations must treat all addresses that do not start 272 with any of the above-listed prefixes as global unicast addresses. 274 2.5 Unicast Addresses 276 IPv6 unicast addresses are aggregatable with prefixes of arbitrary 277 bit-length similar to IPv4 addresses under Classless Interdomain 278 Routing. 280 There are several types of unicast addresses in IPv6, in particular 281 global unicast, site-local unicast (deprecated, see section 2.5.7), 282 and link-local unicast. There are also some special-purpose subtypes 283 of global unicast, such as IPv6 addresses with embedded IPv4 284 addresses or encoded NSAP addresses. Additional address types or 285 subtypes can be defined in the future. 287 IPv6 nodes may have considerable or little knowledge of the internal 288 structure of the IPv6 address, depending on the role the node plays 289 (for instance, host versus router). At a minimum, a node may 290 consider that unicast addresses (including its own) have no internal 291 structure: 293 | 128 bits | 294 +-----------------------------------------------------------------+ 295 | node address | 296 +-----------------------------------------------------------------+ 298 A slightly sophisticated host (but still rather simple) may 299 additionally be aware of subnet prefix(es) for the link(s) it is 300 attached to, where different addresses may have different values for 301 n: 303 | n bits | 128-n bits | 304 +------------------------------------------------+----------------+ 305 | subnet prefix | interface ID | 306 +------------------------------------------------+----------------+ 308 Though a very simple router may have no knowledge of the internal 309 structure of IPv6 unicast addresses, routers will more generally have 310 knowledge of one or more of the hierarchical boundaries for the 311 operation of routing protocols. The known boundaries will differ 312 from router to router, depending on what positions the router holds 313 in the routing hierarchy. 315 Except for the knowledge of the subnet boundary discussed in the 316 pervious paragraphs nodes should not make any assumptions about the 317 structure of an IPv6 address. 319 2.5.1 Interface Identifiers 321 Interface identifiers in IPv6 unicast addresses are used to identify 322 interfaces on a link. They are required to be unique within a subnet 323 prefix. It is recommended that the same interface identifier not be 324 assigned to different nodes on a link. They may also be unique over 325 a broader scope. In some cases an interface's identifier will be 326 derived directly from that interface's link-layer address. The same 327 interface identifier may be used on multiple interfaces on a single 328 node, as long as they are attached to different subnets. 330 Note that the uniqueness of interface identifiers is independent of 331 the uniqueness of IPv6 addresses. For example, a global unicast 332 address may be created with a local scope interface identifier and a 333 link-local address may be created with a universal scope interface 334 identifier. 336 For all unicast addresses, except those that start with binary value 337 000, Interface IDs are required to be 64 bits long and to be 338 constructed in Modified EUI-64 format. 340 Modified EUI-64 format based Interface identifiers may have universal 341 scope when derived from a universal token (e.g., IEEE 802 48-bit MAC 342 or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a 343 global token is not available (e.g., serial links, tunnel end-points, 344 etc.) or where global tokens are undesirable (e.g., temporary tokens 345 for privacy [PRIV]). 347 Modified EUI-64 format interface identifiers are formed by inverting 348 the "u" bit (universal/local bit in IEEE EUI-64 terminology) when 349 forming the interface identifier from IEEE EUI-64 identifiers. In 350 the resulting Modified EUI-64 format the "u" bit is set to one (1) to 351 indicate universal scope, and it is set to zero (0) to indicate local 352 scope. The first three octets in binary of an IEEE EUI-64 identifier 353 are as follows: 355 0 0 0 1 1 2 356 |0 7 8 5 6 3| 357 +----+----+----+----+----+----+ 358 |cccc|ccug|cccc|cccc|cccc|cccc| 359 +----+----+----+----+----+----+ 361 written in Internet standard bit-order , where "u" is the 362 universal/local bit, "g" is the individual/group bit, and "c" are the 363 bits of the company_id. Appendix A: "Creating Modified EUI-64 format 364 Interface Identifiers" provides examples on the creation of Modified 365 EUI-64 format based interface identifiers. 367 The motivation for inverting the "u" bit when forming an interface 368 identifier is to make it easy for system administrators to hand 369 configure non-global identifiers when hardware tokens are not 370 available. This is expected to be case for serial links, tunnel end- 371 points, etc. The alternative would have been for these to be of the 372 form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2, 373 etc. 375 IPv6 nodes are not required to validate that interface identifiers 376 created with modified EUI-64 tokens with the "u" bit set to universal 377 are unique. 379 The use of the universal/local bit in the Modified EUI-64 format 380 identifier is to allow development of future technology that can take 381 advantage of interface identifiers with universal scope. 383 The details of forming interface identifiers are defined in the 384 appropriate "IPv6 over " specification such as "IPv6 over 385 Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. 387 2.5.2 The Unspecified Address 389 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It 390 must never be assigned to any node. It indicates the absence of an 391 address. One example of its use is in the Source Address field of 392 any IPv6 packets sent by an initializing host before it has learned 393 its own address. 395 The unspecified address must not be used as the destination address 396 of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a 397 source address of unspecified must never be forwarded by an IPv6 398 router. 400 2.5.3 The Loopback Address 402 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. 403 It may be used by a node to send an IPv6 packet to itself. It may 404 never be assigned to any physical interface. It is treated as 405 having link-local scope, and may be thought of as the link-local 406 unicast address of a virtual interface (typically called "the 407 loopback interface") to an imaginary link that goes nowhere. 409 The loopback address must not be used as the source address in IPv6 410 packets that are sent outside of a single node. An IPv6 packet with 411 a destination address of loopback must never be sent outside of a 412 single node and must never be forwarded by an IPv6 router. A packet 413 received on an interface with destination address of loopback must be 414 dropped. 416 2.5.4 Global Unicast Addresses 418 The general format for IPv6 global unicast addresses is as follows: 420 | n bits | m bits | 128-n-m bits | 421 +------------------------+-----------+----------------------------+ 422 | global routing prefix | subnet ID | interface ID | 423 +------------------------+-----------+----------------------------+ 425 where the global routing prefix is a (typically hierarchically- 426 structured) value assigned to a site (a cluster of subnets/links), 427 the subnet ID is an identifier of a link within the site, and the 428 interface ID is as defined in section 2.5.1. 430 All global unicast addresses other than those that start with binary 431 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as 432 described in section 2.5.1. Global unicast addresses that start with 433 binary 000 have no such constraint on the size or structure of the 434 interface ID field. 436 Examples of global unicast addresses that start with binary 000 are 437 the IPv6 address with embedded IPv4 addresses described in section 438 2.5.5 and the IPv6 address containing encoded NSAP addresses 439 specified in [NSAP]. An example of global addresses starting with a 440 binary value other than 000 (and therefore having a 64-bit interface 441 ID field) can be found in [GLOBAL]. 443 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses 445 The IPv6 transition mechanisms [TRAN] include a technique for hosts 446 and routers to dynamically tunnel IPv6 packets over IPv4 routing 447 infrastructure. IPv6 nodes that use this technique are assigned 448 special IPv6 unicast addresses that carry a global IPv4 address in 449 the low-order 32 bits. This type of address is termed an 450 "IPv4-compatible IPv6 address" and has the format: 452 | 80 bits | 16 | 32 bits | 453 +--------------------------------------+--------------------------+ 454 |0000..............................0000|0000| IPv4 address | 455 +--------------------------------------+----+---------------------+ 457 Note: The IPv4 address used in the "IPv4-compatible IPv6 address" 458 must be a globally-unique IPv4 unicast address. 460 A second type of IPv6 address which holds an embedded IPv4 address is 461 also defined. This address type is used to represent the addresses 462 of IPv4 nodes as IPv6 addresses. This type of address is termed an 463 "IPv4-mapped IPv6 address" and has the format: 465 | 80 bits | 16 | 32 bits | 466 +--------------------------------------+--------------------------+ 467 |0000..............................0000|FFFF| IPv4 address | 468 +--------------------------------------+----+---------------------+ 470 2.5.6 Link-Local IPv6 Unicast Addresses 472 Link-Local addresses are for use on a single link. Link-Local 473 addresses have the following format: 475 | 10 | 476 | bits | 54 bits | 64 bits | 477 +----------+-------------------------+----------------------------+ 478 |1111111010| 0 | interface ID | 479 +----------+-------------------------+----------------------------+ 481 Link-Local addresses are designed to be used for addressing on a 482 single link for purposes such as automatic address configuration, 483 neighbor discovery, or when no routers are present. 485 Routers must not forward any packets with link-local source or 486 destination addresses to other links. 488 2.5.7 Site-Local IPv6 Unicast Addresses 490 Site-local addresses were originally designed to be used for 491 addressing inside of a site without the need for a global prefix. 492 Site-Local addresses are now deprecated as defined in [SLDEP]. 494 Site-Local addresses have the following format: 496 | 10 | 497 | bits | 54 bits | 64 bits | 498 +----------+-------------------------+----------------------------+ 499 |1111111011| subnet ID | interface ID | 500 +----------+-------------------------+----------------------------+ 502 The special behavior of this prefix defined in [RFC3513] must no 503 longer be supported in new implementations (i.e., new implementations 504 must treat this prefix as Global Unicast). 506 Existing implementations and deployments may continue to use this 507 prefix. 509 Note: The text in this section of this internet-draft is dependent 510 on [SLDEP] and is subject to change. 512 2.6 Anycast Addresses 514 An IPv6 anycast address is an address that is assigned to more than 515 one interface (typically belonging to different nodes), with the 516 property that a packet sent to an anycast address is routed to the 517 "nearest" interface having that address, according to the routing 518 protocols' measure of distance. 520 Anycast addresses are allocated from the unicast address space, using 521 any of the defined unicast address formats. Thus, anycast addresses 522 are syntactically indistinguishable from unicast addresses. When a 523 unicast address is assigned to more than one interface, thus turning 524 it into an anycast address, the nodes to which the address is 525 assigned must be explicitly configured to know that it is an anycast 526 address. 528 For any assigned anycast address, there is a longest prefix P of that 529 address that identifies the topological region in which all 530 interfaces belonging to that anycast address reside. Within the 531 region identified by P, the anycast address must be maintained as a 532 separate entry in the routing system (commonly referred to as a "host 533 route"); outside the region identified by P, the anycast address may 534 be aggregated into the routing entry for prefix P. 536 Note that in the worst case, the prefix P of an anycast set may be 537 the null prefix, i.e., the members of the set may have no topological 538 locality. In that case, the anycast address must be maintained as a 539 separate routing entry throughout the entire internet, which presents 540 a severe scaling limit on how many such "global" anycast sets may be 541 supported. Therefore, it is expected that support for global anycast 542 sets may be unavailable or very restricted. 544 One expected use of anycast addresses is to identify the set of 545 routers belonging to an organization providing internet service. 546 Such addresses could be used as intermediate addresses in an IPv6 547 Routing header, to cause a packet to be delivered via a particular 548 service provider or sequence of service providers. 550 Some other possible uses are to identify the set of routers attached 551 to a particular subnet, or the set of routers providing entry into a 552 particular routing domain. 554 There is little experience with widespread, arbitrary use of internet 555 anycast addresses, and some known complications and hazards when 556 using them in their full generality [ANYCST]. Until more experience 557 has been gained and solutions are specified, the following 558 restrictions are imposed on IPv6 anycast addresses: 560 o An anycast address must not be used as the source address of an 561 IPv6 packet. 563 o An anycast address must not be assigned to an IPv6 host, that 564 is, it may be assigned to an IPv6 router only. 566 2.6.1 Required Anycast Address 568 The Subnet-Router anycast address is predefined. Its format is as 569 follows: 571 | n bits | 128-n bits | 572 +------------------------------------------------+----------------+ 573 | subnet prefix | 00000000000000 | 574 +------------------------------------------------+----------------+ 576 The "subnet prefix" in an anycast address is the prefix which 577 identifies a specific link. This anycast address is syntactically 578 the same as a unicast address for an interface on the link with the 579 interface identifier set to zero. 581 Packets sent to the Subnet-Router anycast address will be delivered 582 to one router on the subnet. All routers are required to support the 583 Subnet-Router anycast addresses for the subnets to which they have 584 interfaces. 586 The subnet-router anycast address is intended to be used for 587 applications where a node needs to communicate with any one of the 588 set of routers. 590 2.7 Multicast Addresses 592 An IPv6 multicast address is an identifier for a group of interfaces 593 (typically on different nodes). An interface may belong to any 594 number of multicast groups. Multicast addresses have the following 595 format: 597 | 8 | 4 | 4 | 112 bits | 598 +------ -+----+----+---------------------------------------------+ 599 |11111111|flgs|scop| group ID | 600 +--------+----+----+---------------------------------------------+ 602 binary 11111111 at the start of the address identifies the 603 address as being a multicast address. 605 +-+-+-+-+ 606 flgs is a set of 4 flags: |0|0|0|T| 607 +-+-+-+-+ 609 The high-order 3 flags are reserved, and must be 610 initialized to 0. 612 T = 0 indicates a permanently-assigned ("well-known") 613 multicast address, assigned by the Internet Assigned Number 614 Authority (IANA). 616 T = 1 indicates a non-permanently-assigned ("transient") 617 multicast address. 619 scop is a 4-bit multicast scope value used to limit the scope of 620 the multicast group. The values are: 622 0 reserved 623 1 interface-local scope 624 2 link-local scope 625 3 reserved 626 4 admin-local scope 627 5 site-local scope 628 6 (unassigned) 629 7 (unassigned) 630 8 organization-local scope 631 9 (unassigned) 632 A (unassigned) 633 B (unassigned) 634 C (unassigned) 635 D (unassigned) 636 E global scope 637 F reserved 639 interface-local scope spans only a single interface on a 640 node, and is useful only for loopback transmission of 641 multicast. 643 link-local and site-local multicast scopes span the same 644 topological regions as the corresponding unicast scopes. 646 admin-local scope is the smallest scope that must be 647 administratively configured, i.e., not automatically 648 derived from physical connectivity or other, non- 649 multicast-related configuration. 651 organization-local scope is intended to span multiple 652 sites belonging to a single organization. 654 scopes labeled "(unassigned)" are available for 655 administrators to define additional multicast regions. 657 group ID identifies the multicast group, either permanent or 658 transient, within the given scope. 660 The "meaning" of a permanently-assigned multicast address is 661 independent of the scope value. For example, if the "NTP servers 662 group" is assigned a permanent multicast address with a group ID of 663 101 (hex), then: 665 FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface 666 (i.e., the same node) as the sender. 668 FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as 669 the sender. 671 FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as 672 the sender. 674 FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet. 676 Non-permanently-assigned multicast addresses are meaningful only 677 within a given scope. For example, a group identified by the non- 678 permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one 679 site bears no relationship to a group using the same address at a 680 different site, nor to a non-permanent group using the same group ID 681 with different scope, nor to a permanent group with the same group 682 ID. 684 Multicast addresses must not be used as source addresses in IPv6 685 packets or appear in any Routing header. 687 Routers must not forward any multicast packets beyond of the scope 688 indicated by the scop field in the destination multicast address. 690 Nodes must not originate a packet to a multicast address whose scop 691 field contains the reserved value 0; if such a packet is received, it 692 must be silently dropped. Nodes should not originate a packet to a 693 multicast address whose scop field contains the reserved value F; if 694 such a packet is sent or received, it must be treated the same as 695 packets destined to a global (scop E) multicast address. 697 2.7.1 Pre-Defined Multicast Addresses 699 The following well-known multicast addresses are pre-defined. The 700 group ID's defined in this section are defined for explicit scope 701 values. 703 Use of these group IDs for any other scope values, with the T flag 704 equal to 0, is not allowed. 706 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 707 FF01:0:0:0:0:0:0:0 708 FF02:0:0:0:0:0:0:0 709 FF03:0:0:0:0:0:0:0 710 FF04:0:0:0:0:0:0:0 711 FF05:0:0:0:0:0:0:0 712 FF06:0:0:0:0:0:0:0 713 FF07:0:0:0:0:0:0:0 714 FF08:0:0:0:0:0:0:0 715 FF09:0:0:0:0:0:0:0 716 FF0A:0:0:0:0:0:0:0 717 FF0B:0:0:0:0:0:0:0 718 FF0C:0:0:0:0:0:0:0 719 FF0D:0:0:0:0:0:0:0 720 FF0E:0:0:0:0:0:0:0 721 FF0F:0:0:0:0:0:0:0 723 The above multicast addresses are reserved and shall never be 724 assigned to any multicast group. 726 All Nodes Addresses: FF01:0:0:0:0:0:0:1 727 FF02:0:0:0:0:0:0:1 729 The above multicast addresses identify the group of all IPv6 nodes, 730 within scope 1 (interface-local) or 2 (link-local). 732 All Routers Addresses: FF01:0:0:0:0:0:0:2 733 FF02:0:0:0:0:0:0:2 734 FF05:0:0:0:0:0:0:2 736 The above multicast addresses identify the group of all IPv6 routers, 737 within scope 1 (interface-local), 2 (link-local), or 5 (site-local). 739 Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX 741 Solicited-node multicast address are computed as a function of a 742 node's unicast and anycast addresses. A solicited-node multicast 743 address is formed by taking the low-order 24 bits of an address 744 (unicast or anycast) and appending those bits to the prefix 745 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 746 range 748 FF02:0:0:0:0:1:FF00:0000 750 to 751 FF02:0:0:0:0:1:FFFF:FFFF 753 For example, the solicited node multicast address corresponding to 754 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 755 addresses that differ only in the high-order bits, e.g. due to 756 multiple high-order prefixes associated with different aggregations, 757 will map to the same solicited-node address thereby, reducing the 758 number of multicast addresses a node must join. 760 A node is required to compute and join (on the appropriate interface) 761 the associated Solicited-Node multicast addresses for every unicast 762 and anycast address it is assigned. 764 2.8 A Node's Required Addresses 766 A host is required to recognize the following addresses as 767 identifying itself: 769 o Its required Link-Local Address for each interface. 770 o Any additional Unicast and Anycast Addresses that have been 771 configured for the node's interfaces (manually or 772 automatically). 773 o The loopback address. 774 o The All-Nodes Multicast Addresses defined in section 2.7.1. 775 o The Solicited-Node Multicast Address for each of its unicast and 776 anycast addresses. 777 o Multicast Addresses of all other groups to which the node 778 belongs. 780 A router is required to recognize all addresses that a host is 781 required to recognize, plus the following addresses as identifying 782 itself: 784 o The Subnet-Router Anycast Addresses for all interfaces for which 785 it is configured to act as a router. 786 o All other Anycast Addresses with which the router has been 787 configured. 788 o The All-Routers Multicast Addresses defined in section 2.7.1. 790 3. Security Considerations 792 IPv6 addressing documents do not have any direct impact on Internet 793 infrastructure security. Authentication of IPv6 packets is defined 794 in [AUTH]. 796 4. IANA Considerations 798 IANA is requested to reserve and not to reassign the FEC0::/10 prefix 799 (binary 1111111011) unless requested to do so by a future IETF 800 standards action. 802 The table at http://www.isi.edu/in- 803 notes/iana/assignments/ipv6-address-space.txt should have the line 804 for "Site-Local Unicast Addresses" replaced with 806 Reserved 1111 1110 11 1/1024 808 The following note should also be added to the same page: 810 3) The FEC0::/10 prefix (binary 1111111011) was previously known 811 as site-local. It's usage as Site-Local is now deprecated and 812 is currently reserved. 814 APPENDIX A: Creating Modified EUI-64 format Interface Identifiers 815 ------------------------------------------------------------------ 817 Depending on the characteristics of a specific link or node there are 818 a number of approaches for creating Modified EUI-64 format interface 819 identifiers. This appendix describes some of these approaches. 821 Links or Nodes with IEEE EUI-64 Identifiers 823 The only change needed to transform an IEEE EUI-64 identifier to an 824 interface identifier is to invert the "u" (universal/local) bit. For 825 example, a globally unique IEEE EUI-64 identifier of the form: 827 |0 1|1 3|3 4|4 6| 828 |0 5|6 1|2 7|8 3| 829 +----------------+----------------+----------------+----------------+ 830 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 831 +----------------+----------------+----------------+----------------+ 833 where "c" are the bits of the assigned company_id, "0" is the value 834 of the universal/local bit to indicate universal scope, "g" is 835 individual/group bit, and "m" are the bits of the manufacturer- 836 selected extension identifier. The IPv6 interface identifier would 837 be of the form: 839 |0 1|1 3|3 4|4 6| 840 |0 5|6 1|2 7|8 3| 841 +----------------+----------------+----------------+----------------+ 842 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 843 +----------------+----------------+----------------+----------------+ 845 The only change is inverting the value of the universal/local bit. 847 Links or Nodes with IEEE 802 48 bit MAC's 849 [EUI64] defines a method to create a IEEE EUI-64 identifier from an 850 IEEE 48bit MAC identifier. This is to insert two octets, with 851 hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC 852 (between the company_id and vendor supplied id). For example the 48 853 bit IEEE MAC with global scope: 855 |0 1|1 3|3 4| 856 |0 5|6 1|2 7| 857 +----------------+----------------+----------------+ 858 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 859 +----------------+----------------+----------------+ 861 where "c" are the bits of the assigned company_id, "0" is the value 862 of the universal/local bit to indicate global scope, "g" is 863 individual/group bit, and "m" are the bits of the manufacturer- 864 selected extension identifier. The interface identifier would be of 865 the form: 867 |0 1|1 3|3 4|4 6| 868 |0 5|6 1|2 7|8 3| 869 +----------------+----------------+----------------+----------------+ 870 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 871 +----------------+----------------+----------------+----------------+ 873 When IEEE 802 48bit MAC addresses are available (on an interface or a 874 node), an implementation may use them to create interface identifiers 875 due to their availability and uniqueness properties. 877 Links with Other Kinds of Identifiers 879 There are a number of types of links that have link-layer interface 880 identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs. Examples 881 include LocalTalk and Arcnet. The method to create an Modified 882 EUI-64 format identifier is to take the link identifier (e.g., the 883 LocalTalk 8 bit node identifier) and zero fill it to the left. For 884 example a LocalTalk 8 bit node identifier of hexadecimal value 0x4F 885 results in the following interface identifier: 887 |0 1|1 3|3 4|4 6| 888 |0 5|6 1|2 7|8 3| 889 +----------------+----------------+----------------+----------------+ 890 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 891 +----------------+----------------+----------------+----------------+ 893 Note that this results in the universal/local bit set to "0" to 894 indicate local scope. 896 Links without Identifiers 898 There are a number of links that do not have any type of built-in 899 identifier. The most common of these are serial links and configured 900 tunnels. Interface identifiers must be chosen that are unique within 901 a subnet-prefix. 903 When no built-in identifier is available on a link the preferred 904 approach is to use a universal interface identifier from another 905 interface or one which is assigned to the node itself. When using 906 this approach no other interface connecting the same node to the same 907 subnet-prefix may use the same identifier. 909 If there is no universal interface identifier available for use on 910 the link the implementation needs to create a local-scope interface 911 identifier. The only requirement is that it be unique within a 912 subnet prefix. There are many possible approaches to select a 913 subnet-prefix-unique interface identifier. These include: 915 Manual Configuration 916 Node Serial Number 917 Other node-specific token 919 The subnet-prefix-unique interface identifier should be generated in 920 a manner that it does not change after a reboot of a node or if 921 interfaces are added or deleted from the node. 923 The selection of the appropriate algorithm is link and implementation 924 dependent. The details on forming interface identifiers are defined 925 in the appropriate "IPv6 over " specification. It is strongly 926 recommended that a collision detection algorithm be implemented as 927 part of any automatic algorithm. 929 APPENDIX B: Changes from RFC-3513 930 --------------------------------- 932 The following changes were made from RFC-3513 "IP Version 6 933 Addressing Architecture": 935 o Deprecated the Site-Local prefix. Changes included 936 - Removed Site-Local from special list of prefixes in section 937 2.4. 938 - Split section titled "Local-use IPv6 Unicast Addresses" into 939 two sections, "Link-Local IPv6 Unicast Addresses" and "Site- 940 Local IPv6 Unicast Addresses". 941 - Added text to new section describing Site-Local deprecation. 942 - Added instructions in IANA Considerations to reserve and not 943 reassign the site-local prefix. 945 o Changes to resolve issues raised in IAB response to Robert Elz 946 appeal. Changes include: 947 - Added clarification to section 2.5 that nodes should make no 948 assumptions about the structure of an IPv6 address. 949 - Changed the text in section 2.5.1 and Appendix A to refer to 950 the modified EUI-64 format interface identifiers with the "u" 951 bit set to one (1) as universal. 952 - Added clarification to section 2.5.1 that IPv6 nodes are not 953 required to validate that interface identifiers created in 954 modified EUI-64 format with the "u" bit set to one are unique. 956 - Changed the reference indicated in section 2.5.4 "Global Unicast 957 Addresses" to RFC3587. 959 REFERENCES 961 Normative References 963 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 964 (IPv6) Specification", RFC2460, December 1998. 966 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 967 3", RFC2026, BCP00009, October 1996. 969 [SLDEP] C. Huitema, B. Carpenter, "Deprecating Site Local 970 Addresses", Internet Draft, , September 2003. 973 Non-Normative References 975 [ANYCST] Partridge, C., T. Mendez, and W. Milliken, "Host Anycasting 976 Service", RFC1546, November 1993. 978 [AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402, 979 November 1998. 981 [CIDR] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless Inter- 982 Domain Routing (CIDR): An Address Assignment and 983 Aggregation Strategy", RFC1519, September 1993. 985 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 986 Networks", RFC2464, December 1998. 988 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 989 Registration Authority", 990 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 991 , March 1997. 993 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 994 Networks", RFC2467, December 1998. 996 [GLOBAL] Hinden, R., S. Deering, E. Nordmark, "IPv6 Global Unicast 997 Address Format", RFC3587, August 2003. 999 [MASGN] Hinden, R., "IPv6 Multicast Address Assignments", RFC2375, 1000 July 1998. 1002 [NSAP] Bound, J., B. Carpenter, D. Harrington, J. Houldsworth, A. 1003 Lloyd, "OSI NSAPs and IPv6", RFC1888, August 1996. 1005 [PRIV] Narten, T., R. Draves, "Privacy Extensions for Stateless 1006 Address Autoconfiguration in IPv6", RFC3041, January 2001. 1008 [TOKEN] Crawford, M., T. Narten, S. Thomas, "Transmission of IPv6 1009 Packets over Token Ring Networks", RFC2470, December 1998. 1011 [TRAN] Gilligan, R., E. Nordmark, "Transition Mechanisms for IPv6 1012 Hosts and Routers", RFC2893, August 2000. 1014 AUTHOR'S ADDRESSES 1016 Robert M. Hinden 1017 Nokia 1018 313 Fairchild Drive 1019 Mountain View, CA 94043 1020 USA 1022 phone: +1 650 625-2004 1023 email: hinden@iprg.nokia.com 1025 Stephen E. Deering 1026 Cisco Systems, Inc. 1027 170 West Tasman Drive 1028 San Jose, CA 95134-1706 1029 USA 1031 phone: +1 408 527-8213 1032 email: deering@cisco.com