idnits 2.17.1 draft-ietf-ipngwg-addr-arch-v2-02.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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: 'RFC 2119' is mentioned on line 87, but not defined == Missing Reference: 'EUI-64' is mentioned on line 370, but not defined == Missing Reference: 'RFC1972' is mentioned on line 758, but not defined ** Obsolete undefined reference: RFC 1972 (Obsoleted by RFC 2464) == Unused Reference: 'ALLOC' is defined on line 938, but no explicit reference was found in the text == Unused Reference: 'MULT' is defined on line 971, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 977, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AGGR' ** Downref: Normative reference to an Informational RFC: RFC 1887 (ref. 'ALLOC') ** Obsolete normative reference: RFC 1826 (ref. 'AUTH') (Obsoleted by RFC 2402) ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. 'ANYCST') ** Obsolete normative reference: RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) -- Possible downref: Non-RFC (?) normative reference: ref. 'ETHER' -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. 'FDDI' ** Obsolete normative reference: RFC 1883 (ref. 'IPV6') (Obsoleted by RFC 2460) -- Possible downref: Non-RFC (?) normative reference: ref. 'MASGN' ** Obsolete normative reference: RFC 1888 (ref. 'NSAP') (Obsoleted by RFC 4048) -- Possible downref: Non-RFC (?) normative reference: ref. 'TOKEN' Summary: 16 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Hinden, Ipsilon Networks 3 July 16, 1997 S. Deering, Cisco Systems 5 IP Version 6 Addressing Architecture 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 23 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 This Internet Draft expires January 17, 1998. 29 Abstract 31 This specification defines the addressing architecture of the IP 32 Version 6 protocol [IPV6]. The document includes the IPv6 addressing 33 model, text representations of IPv6 addresses, definition of IPv6 34 unicast addresses, anycast addresses, and multicast addresses, and an 35 IPv6 node's required addresses. 37 Table of Contents 39 1. Introduction.................................................3 41 2. IPv6 Addressing..............................................3 42 2.1 Addressing Model.........................................4 43 2.2 Text Representation of Addresses.........................4 44 2.3 Text Representation of Address Prefixes..................5 45 2.4 Address Type Representation..............................6 46 2.5 Unicast Addresses........................................8 47 2.5.1 Interface Identifiers................................9 48 2.5.2 The Unspecified Address.............................10 49 2.5.3 The Loopback Address................................10 50 2.5.4 IPv6 Addresses with Embedded IPv4 Addresses.........10 51 2.5.5 NSAP Addresses......................................11 52 2.5.6 IPX Addresses.......................................11 53 2.5.7 Aggregatable Global Unicast Addresses...............12 54 2.5.8 Local-use IPv6 Unicast Addresses....................12 55 2.6 Anycast Addresses.......................................13 56 2.6.1 Required Anycast Address............................14 57 2.7 Multicast Addresses.....................................15 58 2.7.1 Pre-Defined Multicast Addresses.....................16 59 2.7.2 Assignment of New IPv6 Multicast Addresses..........18 60 2.8 A Node's Required Addresses.............................18 62 APPENDIX A: Creating EUI-64 based Interface Identifiers........20 64 REFERENCES.....................................................23 66 SECURITY CONSIDERATIONS........................................24 68 AUTHOR'S ADDRESSES.............................................24 70 CHANGES FROM RFC-1884..........................................25 72 1.0 INTRODUCTION 74 This specification defines the addressing architecture of the IP 75 Version 6 protocol. It includes a detailed description of the 76 currently defined address formats for IPv6 [IPV6]. 78 The authors would like to acknowledge the contributions of Paul 79 Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, 80 Deborah Estrin, Bob Fink, Peter Ford, Bob Gilligan, Dimitry Haskin, 81 Christian Huitema, Tony Li, Greg Minshall, Thomas Narten, Erik 82 Nordmark, Yakov Rekhter, Bill Simpson, and Sue Thomson. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC 2119]. 88 2.0 IPv6 ADDRESSING 90 IPv6 addresses are 128-bit identifiers for interfaces and sets of 91 interfaces. 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 "subscriber". When this name is used with the term "ID" for 113 identifier after the name (e.g., "subscriber ID"), it refers to the 114 contents of the named field. When it is used with the term "prefix" 115 (e.g. "subscriber prefix") it refers to all of the address up to and 116 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 120 zero-valued fields or end in zeros. 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 be assigned multiple IPv6 addresses of any 132 type (unicast, anycast, and multicast) or scope. Unicast addresses 133 with scope greater than link-scope are not needed for interfaces that 134 are not used as the origin or destination of any IPv6 packets to or 135 from non-neighbors. This is sometimes convenient for point-to-point 136 interfaces. There is one exception to this addressing model: 138 An unicast address or a set of unicast addresses may be assigned 139 to 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 multiple groups of 16-bits of zeros. 170 The "::" can only appear once in an address. The "::" can also be 171 used to compress the leading and/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:43 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::43 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. An IPv6 208 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 Representation 249 The specific type of an IPv6 address is indicated by the leading bits 250 in the address. The variable-length field comprising these leading 251 bits is called the Format Prefix (FP). The initial allocation of 252 these prefixes is as follows: 254 Allocation Prefix Fraction of 255 (binary) Address Space 256 ----------------------------------- -------- ------------- 257 Reserved 0000 0000 1/256 258 Unassigned 0000 0001 1/256 260 Reserved for NSAP Allocation 0000 001 1/128 261 Reserved for IPX Allocation 0000 010 1/128 263 Unassigned 0000 011 1/128 264 Unassigned 0000 1 1/32 265 Unassigned 0001 1/16 267 Aggregatable Global Unicast Addresses 001 1/8 268 Unassigned 010 1/8 269 Unassigned 011 1/8 270 Unassigned 100 1/8 271 Unassigned 101 1/8 272 Unassigned 110 1/8 274 Unassigned 1110 1/16 275 Unassigned 1111 0 1/32 276 Unassigned 1111 10 1/64 277 Unassigned 1111 110 1/128 278 Unassigned 1111 1110 0 1/512 280 Link-Local Unicast Addresses 1111 1110 10 1/1024 281 Site-Local Unicast Addresses 1111 1110 11 1/1024 283 Multicast Addresses 1111 1111 1/256 285 Notes: 287 (1) The "unspecified address" (see section 2.5.2), the loopback 288 address (see section 2.5.3), and the IPv6 Addresses with 289 Embedded IPv4 Addresses (see section 2.5.4), are assigned out 290 of the 0000 0000 format prefix space. 292 (2) The format prefixes 001 through 111, except for Multicast 293 Addresses (1111 1111), are all required to have to have 64-bit 294 interface identifiers in EUI-64 format. See section 2.5.1 for 295 definitions. 297 This allocation supports the direct allocation of aggregation 298 addresses, local use addresses, and multicast addresses. Space is 299 reserved for NSAP addresses and IPX addresses. The remainder of the 300 address space is unassigned for future use. This can be used for 301 expansion of existing use (e.g., additional aggregatable addresses, 302 etc.) or new uses (e.g., separate locators and identifiers). Fifteen 303 percent of the address space is initially allocated. The remaining 304 85% is reserved for future use. 306 Unicast addresses are distinguished from multicast addresses by the 307 value of the high-order octet of the addresses: a value of FF 308 (11111111) identifies an address as a multicast address; any other 309 value identifies an address as a unicast address. Anycast addresses 310 are taken from the unicast address space, and are not syntactically 311 distinguishable from unicast addresses. 313 2.5 Unicast Addresses 315 The IPv6 unicast address are aggregatable with contiguous bit-wise 316 masks similar to IPv4 addresses under Class-less Interdomain Routing 317 [CIDR]. 319 There are several forms of unicast address assignment in IPv6, 320 including the global aggregatable global unicast address, the NSAP 321 address, the IPX hierarchical address, the site-local address, the 322 link-local address, and the IPv4-capable host address. Additional 323 address types can be defined in the future. 325 IPv6 nodes may have considerable or little knowledge of the internal 326 structure of the IPv6 address, depending on the role the node plays 327 (for instance, host versus router). At a minimum, a node may 328 consider that unicast addresses (including its own) have no internal 329 structure: 331 | 128 bits | 332 +-----------------------------------------------------------------+ 333 | node address | 334 +-----------------------------------------------------------------+ 336 A slightly sophisticated host (but still rather simple) may 337 additionally be aware of subnet prefix(es) for the link(s) it is 338 attached to, where different addresses may have different values for 339 n: 341 | n bits | 128-n bits | 342 +------------------------------------------------+----------------+ 343 | subnet prefix | interface ID | 344 +------------------------------------------------+----------------+ 345 Still more sophisticated hosts may be aware of other hierarchical 346 boundaries in the unicast address. Though a very simple router may 347 have no knowledge of the internal structure of IPv6 unicast 348 addresses, routers will more generally have knowledge of one or more 349 of the hierarchical boundaries for the operation of routing 350 protocols. The known boundaries will differ from router to router, 351 depending on what positions the router holds in the routing 352 hierarchy. 354 2.5.1 Interface Identifiers 356 Interface identifiers in IPv6 unicast addresses are used to identify 357 interfaces on a link. They are required to be unique on that link. 358 They may also be unique over a broader scope. In many cases an 359 interface's identifier will be the same as that interface's link- 360 layer address. The same interface identifier may be used on multiple 361 interfaces on a single node. 363 Note that the use of the same interface identifier on multiple 364 interfaces of a single node does not affect the interface 365 identifier's global uniqueness or each IPv6 addresses global 366 uniqueness created using that interface identifier. 368 In a number of the format prefixes (see section 2.4) Interface IDs 369 are required to be 64 bits long and to be constructed in IEEE EUI-64 370 format [EUI-64]. EUI-64 based Interface identifiers may have global 371 scope when a global token is available (e.g., IEEE 48bit MAC) or may 372 have local scope where a global token is not available (e.g., serial 373 links, tunnel end-points, etc.). It is required that the "u" bit 374 (universal/local bit in IEEE EUI-64 terminology) be inverted when 375 forming the interface identifier from the EUI-64. The "u" bit is set 376 to one (1) to indicate global scope, and it is set to zero (0) to 377 indicate local scope. The first three octets in binary of an EUI-64 378 identifier are as follows: 380 0 0 0 1 1 2 381 |0 7 8 5 6 3| 382 +----+----+----+----+----+----+ 383 |cccc|ccug|cccc|cccc|cccc|cccc| 384 +----+----+----+----+----+----+ 386 written in Internet standard bit-order , where "u" is the 387 universal/local bit, "g" is the individual/group bit, and "c" are the 388 bits of the company_id. Appendix A: "Creating EUI-64 based Interface 389 Identifiers" provides examples on the creation of different EUI-64 390 based interface identifiers. 392 This use of the universal/local bit in the IEEE EUI-64 identifier is 393 to allow development of future technology that can take advantage of 394 interface identifiers with global scope. 396 The details of forming interface identifiers are defined in the 397 appropriate "IPv6 over " specification such as "IPv6 over 398 Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. 400 2.5.2 The Unspecified Address 402 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It 403 must never be assigned to any node. It indicates the absence of an 404 address. One example of its use is in the Source Address field of 405 any IPv6 packets sent by an initializing host before it has learned 406 its own address. 408 The unspecified address must not be used as the destination address 409 of IPv6 packets or in IPv6 Routing Headers. 411 2.5.3 The Loopback Address 413 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. 414 It may be used by a node to send an IPv6 packet to itself. It may 415 never be assigned to any physical interface. It may be thought of as 416 being associated with a virtual interface (e.g., the loopback 417 interface). 419 The loopback address must not be used as the source address in IPv6 420 packets that are sent outside of a single node. An IPv6 packet with 421 a destination address of loopback must never be sent outside of a 422 single node and must never be forwarded by an IPv6 router. 424 2.5.4 IPv6 Addresses with Embedded IPv4 Addresses 426 The IPv6 transition mechanisms include a technique for hosts and 427 routers to dynamically tunnel IPv6 packets over IPv4 routing 428 infrastructure. IPv6 nodes that utilize this technique are assigned 429 special IPv6 unicast addresses that carry an IPv4 address in the low- 430 order 32-bits. This type of address is termed an "IPv4-compatible 431 IPv6 address" and has the format: 433 | 80 bits | 16 | 32 bits | 434 +--------------------------------------+--------------------------+ 435 |0000..............................0000|0000| IPv4 address | 436 +--------------------------------------+----+---------------------+ 438 A second type of IPv6 address which holds an embedded IPv4 address is 439 also defined. This address is used to represent the addresses of 440 IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. 441 This type of address is termed an "IPv4-mapped IPv6 address" and has 442 the format: 444 | 80 bits | 16 | 32 bits | 445 +--------------------------------------+--------------------------+ 446 |0000..............................0000|FFFF| IPv4 address | 447 +--------------------------------------+----+---------------------+ 449 2.5.5 NSAP Addresses 451 This mapping of NSAP address into IPv6 addresses is defined in 452 [NSAP]. This document recommends that network implementors who have 453 planned or deployed an OSI NSAP addressing plan, and who wish to 454 deploy or transition to IPv6, should redesign a native IPv6 455 addressing plan to meet their needs. However, it also defines a set 456 of mechanisms for the support of OSI NSAP addressing in an IPv6 457 network. These mechanisms are the ones that must be used if such 458 support is required. This document also defines a mapping of IPv6 459 addresses within the OSI address format, should this be required. 461 2.5.6 IPX Addresses 463 This mapping of IPX address into IPv6 addresses is as follows: 465 | 7 | 121 bits | 466 +-------+---------------------------------------------------------+ 467 |0000010| to be defined | 468 +-------+---------------------------------------------------------+ 470 The draft definition, motivation, and usage are under study. 472 2.5.7 Aggregatable Global Unicast Addresses 474 The global aggregatable global unicast address is defined in [AGGR]. 475 This address format is designed to support both the current provider 476 based aggregation and a new type of aggregation called exchanges. 477 The combination will allow efficient routing aggregation for both 478 sites which connect directly to providers and who connect to 479 exchanges. Sites will have the choice to connect to either type of 480 aggregation point. 482 The IPv6 aggregatable global unicast address format is as follows: 484 | 3 | 13 | 32 | 16 | 64 bits | 485 +---+-----+-----------+--------+--------------------------------+ 486 |FP | TLA | NLA ID | SLA ID | Interface ID | 487 | | ID | | | | 488 +---+-----+-----------+--------+--------------------------------+ 490 Where 492 001 Format Prefix (3 bit) for Aggregatable Global 493 Unicast Addresses 494 TLA ID Top-Level Aggregation Identifier 495 NLA ID Next-Level Aggregation Identifier 496 SLA ID Site-Level Aggregation Identifier 497 INTERFACE ID Interface Identifier 499 The contents, field sizes, and assignment rules are defined in 500 [AGGR]. 502 2.5.8 Local-Use IPv6 Unicast Addresses 504 There are two types of local-use unicast addresses defined. These 505 are Link-Local and Site-Local. The Link-Local is for use on a single 506 link and the Site-Local is for use in a single site. Link-Local 507 addresses have the following format: 509 | 10 | 510 | bits | 54 bits | 64 bits | 511 +----------+-------------------------+----------------------------+ 512 |1111111010| 0 | interface ID | 513 +----------+-------------------------+----------------------------+ 515 Link-Local addresses are designed to be used for addressing on a 516 single link for purposes such as auto-address configuration, neighbor 517 discovery, or when no routers are present. 519 Routers must not forward any packets with link-local source or 520 destination addresses to other links. 522 Site-Local addresses have the following format: 524 | 10 | 525 | bits | 38 bits | 16 bits | 64 bits | 526 +----------+-------------+-----------+----------------------------+ 527 |1111111011| 0 | subnet ID | interface ID | 528 +----------+-------------+-----------+----------------------------+ 530 Site-Local addresses are designed to be used for addressing inside of 531 a site without the need for a global prefix. 533 Routers must not forward any packets with site-local source or 534 destination addresses outside of the site. 536 2.6 Anycast Addresses 538 An IPv6 anycast address is an address that is assigned to more than 539 one interface (typically belonging to different nodes), with the 540 property that a packet sent to an anycast address is routed to the 541 "nearest" interface having that address, according to the routing 542 protocols' measure of distance. 544 Anycast addresses are allocated from the unicast address space, using 545 any of the defined unicast address formats. Thus, anycast addresses 546 are syntactically indistinguishable from unicast addresses. When a 547 unicast address is assigned to more than one interface, thus turning 548 it into an anycast address, the nodes to which the address is 549 assigned must be explicitly configured to know that it is an anycast 550 address. 552 For any assigned anycast address, there is a longest address prefix P 553 that identifies the topological region in which all interfaces 554 belonging to that anycast address reside. Within the region 555 identified by P, each member of the anycast set must be advertised as 556 a separate entry in the routing system (commonly referred to as a 557 "host route"); outside the region identified by P, the anycast 558 address may be aggregated into the routing advertisement for prefix 559 P. 561 Note that in, the worst case, the prefix P of an anycast set may be 562 the null prefix, i.e., the members of the set may have no topological 563 locality. In that case, the anycast address must be advertised as a 564 separate routing entry throughout the entire internet, which presents 565 a severe scaling limit on how many such "global" anycast sets may be 566 supported. Therefore, it is expected that support for global anycast 567 sets may be unavailable or very restricted. 569 One expected use of anycast addresses is to identify the set of 570 routers belonging to an organization providing internet service. 571 Such addresses could be used as intermediate addresses in an IPv6 572 Routing header, to cause a packet to be delivered via a particular 573 aggregation or sequence of aggregations. Some other possible uses 574 are to identify the set of routers attached to a particular subnet, 575 or the set of routers providing entry into a particular routing 576 domain. 578 There is little experience with widespread, arbitrary use of internet 579 anycast addresses, and some known complications and hazards when 580 using them in their full generality [ANYCST]. Until more experience 581 has been gained and solutions agreed upon for those problems, the 582 following restrictions are imposed on IPv6 anycast addresses: 584 o An anycast address must not be used as the source address of an 585 IPv6 packet. 587 o An anycast address must not be assigned to an IPv6 host, that 588 is, it may be assigned to an IPv6 router only. 590 2.6.1 Required Anycast Address 592 The Subnet-Router anycast address is predefined. Its format is as 593 follows: 595 | n bits | 128-n bits | 596 +------------------------------------------------+----------------+ 597 | subnet prefix | 00000000000000 | 598 +------------------------------------------------+----------------+ 600 The "subnet prefix" in an anycast address is the prefix which 601 identifies a specific link. This anycast address is syntactically 602 the same as a unicast address for an interface on the link with the 603 interface identifier set to zero. 605 Packets sent to the Subnet-Router anycast address will be delivered 606 to one router on the subnet. All routers are required to support the 607 Subnet-Router anycast addresses for the subnets which they have 608 interfaces. 610 The subnet-router anycast address is intended to be used for 611 applications where a node needs to communicate with one of a set of 612 routers on a remote subnet. For example when a mobile host needs to 613 communicate with one of the mobile agents on its "home" subnet. 615 2.7 Multicast Addresses 617 An IPv6 multicast address is an identifier for a group of nodes. A 618 node may belong to any number of multicast groups. Multicast 619 addresses have the following format: 621 | 8 | 4 | 4 | 112 bits | 622 +------ -+----+----+---------------------------------------------+ 623 |11111111|flgs|scop| group ID | 624 +--------+----+----+---------------------------------------------+ 626 11111111 at the start of the address identifies the address as 627 being a multicast address. 629 +-+-+-+-+ 630 flgs is a set of 4 flags: |0|0|0|T| 631 +-+-+-+-+ 633 The high-order 3 flags are reserved, and must be 634 initialized to 0. 636 T = 0 indicates a permanently-assigned ("well-known") 637 multicast address, assigned by the global internet 638 numbering authority. 640 T = 1 indicates a non-permanently-assigned ("transient") 641 multicast address. 643 scop is a 4-bit multicast scope value used to limit the scope of 644 the multicast group. The values are: 646 0 reserved 647 1 node-local scope 648 2 link-local scope 649 3 (unassigned) 650 4 (unassigned) 651 5 site-local scope 652 6 (unassigned) 653 7 (unassigned) 654 8 organization-local scope 655 9 (unassigned) 656 A (unassigned) 657 B (unassigned) 658 C (unassigned) 659 D (unassigned) 660 E global scope 661 F reserved 663 group ID identifies the multicast group, either permanent or 664 transient, within the given scope. 666 The "meaning" of a permanently-assigned multicast address is 667 independent of the scope value. For example, if the "NTP servers 668 group" is assigned a permanent multicast address with a group ID of 669 43 (hex), then: 671 FF01:0:0:0:0:0:0:43 means all NTP servers on the same node as 672 the sender. 674 FF02:0:0:0:0:0:0:43 means all NTP servers on the same link as 675 the sender. 677 FF05:0:0:0:0:0:0:43 means all NTP servers at the same site as 678 the sender. 680 FF0E:0:0:0:0:0:0:43 means all NTP servers in the internet. 682 Non-permanently-assigned multicast addresses are meaningful only 683 within a given scope. For example, a group identified by the non- 684 permanent, site-local multicast address FF15:0:0:0:0:0:0:43 at one 685 site bears no relationship to a group using the same address at a 686 different site, nor to a non-permanent group using the same group ID 687 with different scope, nor to a permanent group with the same group 688 ID. 690 Multicast addresses must not be used as source addresses in IPv6 691 packets or appear in any routing header. 693 2.7.1 Pre-Defined Multicast Addresses 695 The following well-known multicast addresses are pre-defined: 697 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 698 FF01:0:0:0:0:0:0:0 699 FF02:0:0:0:0:0:0:0 700 FF03:0:0:0:0:0:0:0 701 FF04:0:0:0:0:0:0:0 702 FF05:0:0:0:0:0:0:0 703 FF06:0:0:0:0:0:0:0 704 FF07:0:0:0:0:0:0:0 705 FF08:0:0:0:0:0:0:0 706 FF09:0:0:0:0:0:0:0 707 FF0A:0:0:0:0:0:0:0 708 FF0B:0:0:0:0:0:0:0 709 FF0C:0:0:0:0:0:0:0 710 FF0D:0:0:0:0:0:0:0 711 FF0E:0:0:0:0:0:0:0 712 FF0F:0:0:0:0:0:0:0 714 The above multicast addresses are reserved and shall never be 715 assigned to any multicast group. 717 All Nodes Addresses: FF01:0:0:0:0:0:0:1 718 FF02:0:0:0:0:0:0:1 720 The above multicast addresses identify the group of all IPv6 nodes, 721 within scope 1 (node-local) or 2 (link-local). 723 All Routers Addresses: FF01:0:0:0:0:0:0:2 724 FF02:0:0:0:0:0:0:2 725 FF05:0:0:0:0:0:0:2 727 The above multicast addresses identify the group of all IPv6 routers, 728 within scope 1 (node-local), 2 (link-local), or 5 (site-local). 730 Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX 732 The above multicast address is computed as a function of a node's 733 unicast and anycast addresses. The solicited-node multicast address 734 is formed by taking the low-order 24 bits of the address (unicast or 735 anycast) and appending those bits to the prefix 736 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 737 range 739 FF02:0:0:0:0:1:FF00:0000 741 to 743 FF02:0:0:0:0:1:FFFF:FFFF 745 For example, the solicited node multicast address corresponding to 746 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 747 addresses that differ only in the high-order bits, e.g. due to 748 multiple high-order prefixes associated with different aggregations, 749 will map to the same solicited-node address thereby reducing the 750 number of multicast addresses a node must join. 752 A node is required to compute and join the associated Solicited-Node 753 multicast addresses for every unicast and anycast address it is 754 assigned. 756 2.7.2 Assignment of New IPv6 Multicast Addresses 758 The current approach [RFC1972] to map IPv6 multicast addresses into 759 IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 760 multicast address and uses it to create a MAC address. Note that 761 Token Ring networks are handled differently. This is defined in 762 [TOKEN]. Group ID's less than or equal to 32 bits will generate 763 unique MAC addresses. Due to this new IPv6 multicast addresses 764 should be assigned so that the group identifier is always in the low 765 order 32 bits as shown in the following: 767 | 8 | 4 | 4 | 80 bits | 32 bits | 768 +------ -+----+----+---------------------------+-----------------+ 769 |11111111|flgs|scop| reserved must be zero | group ID | 770 +--------+----+----+---------------------------+-----------------+ 772 While this limits the number of permanent IPv6 multicast groups to 773 2^32 this is unlikely to be a limitation in the future. If it 774 becomes necessary to exceed this limit in the future multicast will 775 still work but the processing will be sightly slower. 777 Additional IPv6 multicast addresses are defined and registered by the 778 IANA [MASGN]. 780 2.8 A Node's Required Addresses 782 A host is required to recognize the following addresses as 783 identifying itself: 785 o Its Link-Local Address for each interface 786 o Assigned Unicast Addresses 787 o Loopback Address 788 o All-Nodes Multicast Address 789 o Solicited-Node Multicast Address for each of its assigned 790 unicast and anycast addresses 791 o Multicast Addresses of all other groups to which the host 792 belongs. 794 A router is required to recognize all addresses that a host is 795 required to recognize, plus the following addresses as identifying 796 itself: 798 o The Subnet-Router anycast addresses for the interfaces it is 799 configured to act as a router on. 800 o All other Anycast addresses with which the router has been 801 configured. 802 o All-Routers Multicast Address 803 o Solicited-Node Multicast Address for each of its assigned 804 unicast and anycast addresses 805 o Multicast Addresses of all other groups to which the router 806 belongs. 808 The only address prefixes which should be predefined in an 809 implementation are the: 811 o Unspecified Address 812 o Loopback Address 813 o Multicast Prefix (FF) 814 o Local-Use Prefixes (Link-Local and Site-Local) 815 o Pre-Defined Multicast Addresses 816 o IPv4-Compatible Prefixes 818 Implementations should assume all other addresses are unicast unless 819 specifically configured (e.g., anycast addresses). 821 APPENDIX A : Creating EUI-64 based Interface Identifiers 822 -------------------------------------------------------- 824 Depending on the characteristics of a specific link or node there are a 825 number of approaches for creating EUI-64 based interface identifiers. 826 This appendix describes some of these approaches. 828 Links or Nodes with EUI-64 Identifiers 830 The only changed needed to transform an EUI-64 identifier to an 831 interface identifier is to invert the "u" (universal/local) bit. For 832 example, a globally unique EUI-64 identifier of the form: 834 |0 1|1 3|3 4|4 6| 835 |0 5|6 1|2 7|8 3| 836 +----------------+----------------+----------------+----------------+ 837 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 838 +----------------+----------------+----------------+----------------+ 840 where "c" are the bits of the assigned company_id, "0" is the value 841 of the universal/local bit to indicate global scope, "g" is 842 individual/group bit, and "m" are the bits of the manufacturer- 843 selected extension identifier. The IPv6 interface identifier would 844 be of the form: 846 |0 1|1 3|3 4|4 6| 847 |0 5|6 1|2 7|8 3| 848 +----------------+----------------+----------------+----------------+ 849 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 850 +----------------+----------------+----------------+----------------+ 852 The only change is inverting the value of the universal/local bit. 854 Links or Nodes with IEEE 802 48 bit MAC's 856 [EUI64] defines a method to create a EUI-64 identifier from an IEEE 857 48bit MAC identifier. This is to insert two octets, with hexadecimal 858 values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the 859 company_id and vendor supplied id). For example the 48 bit MAC with 860 global scope: 862 |0 1|1 3|3 4| 863 |0 5|6 1|2 7| 864 +----------------+----------------+----------------+ 865 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 866 +----------------+----------------+----------------+ 868 where "c" are the bits of the assigned company_id, "0" is the value 869 of the universal/local bit to indicate global scope, "g" is 870 individual/group bit, and "m" are the bits of the manufacturer- 871 selected extension identifier. The interface identifier would be of 872 the form: 874 |0 1|1 3|3 4|4 6| 875 |0 5|6 1|2 7|8 3| 876 +----------------+----------------+----------------+----------------+ 877 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 878 +----------------+----------------+----------------+----------------+ 880 When IEEE 802 48bit MAC addresses are available (on an interface or a 881 node), an implementation should use them to create interface 882 identifiers due to their availability and uniqueness properties. 884 Links with Non-Global Identifiers 886 There are a number of types of links that, while multi-access, do not 887 have globally unique link identifiers. Examples include LocalTalk 888 and Arcnet. The method to create an EUI-64 formatted identifier is 889 to take the link identifier (e.g., the LocalTalk 8 bit node 890 identifier) and zero fill it to the left. For example a LocalTalk 8 891 bit node identifier of hexadecimal value 0x4F results in the 892 following interface identifier: 894 |0 1|1 3|3 4|4 6| 895 |0 5|6 1|2 7|8 3| 896 +----------------+----------------+----------------+----------------+ 897 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 898 +----------------+----------------+----------------+----------------+ 900 Note that this results in the universal/local bit set to "0" to 901 indicate local scope. 903 Links without Identifiers 905 There are a number of links that do not have any type of built-in 906 identifier. The most common of these are serial links and configured 907 tunnels. Interface identifiers must be chosen that are unique for 908 the link. 910 When no built-in identifier is available on a link the preferred 911 approach is to use a global interface identifier from another 912 interface or one which is assigned to the node itself. To use this 913 approach no other interface connecting the same node to the same link 914 may use the same identifier. 916 If there is no global interface identifier available for use on the 917 link the implementation needs to create a local scope interface 918 identifier. The only requirement is that it be unique on the link. 919 There are many possible approaches to select a link-unique interface 920 identifier. They include: 922 Manual Configuration 923 Generated Random Number 924 Node Serial Number (or other node-specific token) 926 The selection of the appropriate algorithm is link and implementation 927 dependent. The details on forming interface identifiers are defined 928 in the appropriate "IPv6 over " specification. It is strongly 929 recommended that a collision detection algorithm be implemented as 930 part of any automatic algorithm. 932 REFERENCES 934 [AGGR] Hinden, R., S. Deering, M. O'Dell, "An Aggregatable Global 935 Unicast Address Format", internet draft, , May 1997. 938 [ALLOC] Rekhter, Y., T. Li, "An Architecture for IPv6 Unicast 939 Address Allocation", RFC1887, December 1995. 941 [AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August 942 1995. 944 [ANYCST] Partridge, C., T. Mendez, and W. Milliken, "Host Anycasting 945 Service", RFC1546, November 1993. 947 [CIDR] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless Inter- 948 Domain Routing (CIDR): An Address Assignment and 949 Aggregation Strategy", RFC1519, September 1993. 951 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 952 Networks", Internet Draft, , March 1997. 955 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 956 Registration Authority", 957 http://standards.ieee.org/db/oui/tutorials/EUI64.html, 958 March 1997. 960 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 961 Networks", Internet Draft, , March 1997. 964 [IPV6] Deering, S., R. Hinden, Editors, "Internet Protocol, 965 Version 6 (IPv6) Specification", RFC1883, December 1995. 967 [MASGN] Hinden, R., "IPv6 Multicast Address Assignments", Internet 968 Draft, , May 969 1997. 971 [MULT] Deering, S., "Host Extensions for IP multicasting", RFC 972 1112. 974 [NSAP] Bound, J., B. Carpenter, D. Harrington, J. Houldsworth, A. 975 Lloyd, "OSI NSAPs and IPv6", RFC1888, August 1996. 977 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 978 Requirement Levels", RFC2119, BCP14, March 1997. 980 [TOKEN] Thomas, S., "Transmission of IPv6 Packets over Token Ring 981 Networks", Internet Draft, June 1997. 983 SECURITY CONSIDERATIONS 985 IPv6 addressing documents do not have any direct impact on Internet 986 infrastructure security. Authentication of IPv6 packets is defined 987 in [AUTH]. 989 AUTHOR'S ADDRESSES 991 Robert M. Hinden Stephen E. Deering 992 Ipsilon Networks, Inc. Cisco Systems, Inc. 993 232 Java Drive 170 West Tasman Drive 994 Sunnyvale, CA 94089 San Jose, CA 95134-1706 995 USA USA 997 phone: +1 408 990-2004 phone: +1 408 527-8213 998 fax: +1 408 743-5677 fax: +1 408 527-8254 999 email: hinden@ipsilon.com email: deering@cisco.com 1001 CHANGES FROM RFC-1884 1003 1005 - Clarification of Address Model based on comments. 1006 - Changed aggregation format terminology to be consistent with 1007 aggregation draft. 1008 - Many small text clarifications and improvements. 1010 1012 - Added text to allow interface identifier to be used on more than 1013 one interface on same node. 1014 - Added rules for defining new multicast addresses. 1015 - Added appendix describing procedures for creating EUI-64 based 1016 interface ID's. 1017 - Minor text clarifications and improvements. 1019 1021 - Added notation for defining IPv6 prefixes. 1022 - Changed solicited node multicast definition to use a longer 1023 prefix. 1024 - Added site scope all routers multicast address. 1025 - Defined Aggregatable Global Unicast Addresses to use "001" Format 1026 Prefix. 1027 - Changed "010" (Provider-Based Unicast) and "100" (Reserved for 1028 Geographic) Format Prefixes to Unassigned. 1029 - Added section on Interface ID definition for unicast addresses. 1030 Requires use of EUI-64 in range of format prefixes and rules for 1031 setting global/local scope bit in EUI-64. 1032 - Updated NSAP text to reflect working in RFC1888. 1033 - Removed protocol specific IPv6 multicast addresses (e.g., DHCP) 1034 and referenced the IANA definitions. 1035 - Removed section "Unicast Address Example". Had become OBE. 1036 - Added new and updated references. 1037 - Minor text clarifications and improvements.