idnits 2.17.1 draft-ietf-ipngwg-addr-arch-v2-06.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 216 has weird spacing: '...address is ...' == Line 219 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 89, but not defined == Unused Reference: 'RFC2119' is defined on line 1037, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ABNF' -- Possible downref: Non-RFC (?) normative reference: ref. 'AGGR' ** 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' ** Downref: Normative reference to an Informational RFC: RFC 1993 (ref. 'TRAN') Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 January 22, 1998 S. Deering, Cisco Systems 4 IP Version 6 Addressing Architecture 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 22 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 This Internet Draft expires July 22, 1998. 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 Table of Contents 38 1. Introduction.................................................3 40 2. IPv6 Addressing..............................................3 41 2.1 Addressing Model.........................................4 42 2.2 Text Representation of Addresses.........................4 43 2.3 Text Representation of Address Prefixes..................5 44 2.4 Address Type Representation..............................6 45 2.5 Unicast Addresses........................................8 46 2.5.1 Interface Identifiers................................9 47 2.5.2 The Unspecified Address.............................10 48 2.5.3 The Loopback Address................................10 49 2.5.4 IPv6 Addresses with Embedded IPv4 Addresses.........10 50 2.5.5 NSAP Addresses......................................11 51 2.5.6 IPX Addresses.......................................11 52 2.5.7 Aggregatable Global Unicast Addresses...............12 53 2.5.8 Local-use IPv6 Unicast Addresses....................12 54 2.6 Anycast Addresses.......................................13 55 2.6.1 Required Anycast Address............................14 56 2.7 Multicast Addresses.....................................15 57 2.7.1 Pre-Defined Multicast Addresses.....................16 58 2.7.2 Assignment of New IPv6 Multicast Addresses..........18 59 2.8 A Node's Required Addresses.............................18 61 3. Security Considerations.....................................19 63 APPENDIX A: Creating EUI-64 based Interface Identifiers........20 65 APPENDIX B: ABNF Description of Text Representations...........22 67 APPENDIX C: CHANGES FROM RFC-1884..............................23 69 REFERENCES.....................................................24 71 AUTHOR'S ADDRESSES.............................................25 73 1.0 INTRODUCTION 75 This specification defines the addressing architecture of the IP 76 Version 6 protocol. It includes a detailed description of the 77 currently defined address formats for IPv6 [IPV6]. 79 The authors would like to acknowledge the contributions of Paul 80 Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, 81 Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, 82 Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg 83 Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, 84 and Sue Thomson. 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC 2119]. 90 2.0 IPv6 ADDRESSING 92 IPv6 addresses are 128-bit identifiers for interfaces and sets of 93 interfaces. There are three types of addresses: 95 Unicast: An identifier for a single interface. A packet sent to a 96 unicast address is delivered to the interface identified 97 by that address. 99 Anycast: An identifier for a set of interfaces (typically 100 belonging to different nodes). A packet sent to an 101 anycast address is delivered to one of the interfaces 102 identified by that address (the "nearest" one, according 103 to the routing protocols' measure of distance). 105 Multicast: An identifier for a set of interfaces (typically 106 belonging to different nodes). A packet sent to a 107 multicast address is delivered to all interfaces 108 identified by that address. 110 There are no broadcast addresses in IPv6, their function being 111 superseded by multicast addresses. 113 In this document, fields in addresses are given a specific name, for 114 example "subscriber". When this name is used with the term "ID" for 115 identifier after the name (e.g., "subscriber ID"), it refers to the 116 contents of the named field. When it is used with the term "prefix" 117 (e.g. "subscriber prefix") it refers to all of the address up to and 118 including this field. 120 In IPv6, all zeros and all ones are legal values for any field, 121 unless specifically excluded. Specifically, prefixes may contain 122 zero-valued fields or end in zeros. 124 2.1 Addressing Model 126 IPv6 addresses of all types are assigned to interfaces, not nodes. 127 An IPv6 unicast address refers to a single interface. Since each 128 interface belongs to a single node, any of that node's interfaces' 129 unicast addresses may be used as an identifier for the node. 131 All interfaces are required to have at least one link-local unicast 132 address (see section 2.8 for additional required addresses). A 133 single interface may also be assigned multiple IPv6 addresses of any 134 type (unicast, anycast, and multicast) or scope. Unicast addresses 135 with scope greater than link-scope are not needed for interfaces that 136 are not used as the origin or destination of any IPv6 packets to or 137 from non-neighbors. This is sometimes convenient for point-to-point 138 interfaces. There is one exception to this addressing model: 140 An unicast address or a set of unicast addresses may be assigned 141 to multiple physical interfaces if the implementation treats the 142 multiple physical interfaces as one interface when presenting it 143 to the internet layer. This is useful for load-sharing over 144 multiple physical interfaces. 146 Currently IPv6 continues the IPv4 model that a subnet prefix is 147 associated with one link. Multiple subnet prefixes may be assigned 148 to the same link. 150 2.2 Text Representation of Addresses 152 There are three conventional forms for representing IPv6 addresses as 153 text strings: 155 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the 156 hexadecimal values of the eight 16-bit pieces of the address. 157 Examples: 159 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 161 1080:0:0:0:8:800:200C:417A 163 Note that it is not necessary to write the leading zeros in an 164 individual field, but there must be at least one numeral in every 165 field (except for the case described in 2.). 167 2. Due to some methods of allocating certain styles of IPv6 168 addresses, it will be common for addresses to contain long strings 169 of zero bits. In order to make writing addresses containing zero 170 bits easier a special syntax is available to compress the zeros. 171 The use of "::" indicates multiple groups of 16-bits of zeros. 172 The "::" can only appear once in an address. The "::" can also be 173 used to compress the leading and/or trailing zeros in an address. 175 For example the following addresses: 177 1080:0:0:0:8:800:200C:417A a unicast address 178 FF01:0:0:0:0:0:0:101 a multicast address 179 0:0:0:0:0:0:0:1 the loopback address 180 0:0:0:0:0:0:0:0 the unspecified addresses 182 may be represented as: 184 1080::8:800:200C:417A a unicast address 185 FF01::101 a multicast address 186 ::1 the loopback address 187 :: the unspecified addresses 189 3. An alternative form that is sometimes more convenient when dealing 190 with a mixed environment of IPv4 and IPv6 nodes is 191 x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of 192 the six high-order 16-bit pieces of the address, and the 'd's are 193 the decimal values of the four low-order 8-bit pieces of the 194 address (standard IPv4 representation). Examples: 196 0:0:0:0:0:0:13.1.68.3 198 0:0:0:0:0:FFFF:129.144.52.38 200 or in compressed form: 202 ::13.1.68.3 204 ::FFFF:129.144.52.38 206 2.3 Text Representation of Address Prefixes 208 The text representation of IPv6 address prefixes is similar to the 209 way IPv4 addresses prefixes are written in CIDR notation. An IPv6 210 address prefix is represented by the notation: 212 ipv6-address/prefix-length 214 where 216 ipv6-address is an IPv6 address in any of the notations listed 217 in section 2.2. 219 prefix-length is a decimal value specifying how many of the 220 leftmost contiguous bits of the address comprise 221 the prefix. 223 For example, the following are legal representations of the 60-bit 224 prefix 12AB00000000CD3 (hexadecimal): 226 12AB:0000:0000:CD30:0000:0000:0000:0000/60 227 12AB::CD30:0:0:0:0/60 228 12AB:0:0:CD30::/60 230 The following are NOT legal representations of the above prefix: 232 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, 233 within any 16-bit chunk of the address 235 12AB::CD30/60 address to left of "/" expands to 236 12AB:0000:0000:0000:0000:000:0000:CD30 238 12AB::CD3/60 address to left of "/" expands to 239 12AB:0000:0000:0000:0000:000:0000:0CD3 241 When writing both a node address and a prefix of that node address 242 (e.g., the node's subnet prefix), the two can combined as follows: 244 the node address 12AB:0:0:CD30:123:4567:89AB:CDEF 245 and its subnet number 12AB:0:0:CD30::/60 247 can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 249 2.4 Address Type Representation 251 The specific type of an IPv6 address is indicated by the leading bits 252 in the address. The variable-length field comprising these leading 253 bits is called the Format Prefix (FP). The initial allocation of 254 these prefixes is as follows: 256 Allocation Prefix Fraction of 257 (binary) Address Space 258 ----------------------------------- -------- ------------- 259 Reserved 0000 0000 1/256 260 Unassigned 0000 0001 1/256 262 Reserved for NSAP Allocation 0000 001 1/128 263 Reserved for IPX Allocation 0000 010 1/128 265 Unassigned 0000 011 1/128 266 Unassigned 0000 1 1/32 267 Unassigned 0001 1/16 269 Aggregatable Global Unicast Addresses 001 1/8 270 Unassigned 010 1/8 271 Unassigned 011 1/8 272 Unassigned 100 1/8 273 Unassigned 101 1/8 274 Unassigned 110 1/8 276 Unassigned 1110 1/16 277 Unassigned 1111 0 1/32 278 Unassigned 1111 10 1/64 279 Unassigned 1111 110 1/128 280 Unassigned 1111 1110 0 1/512 282 Link-Local Unicast Addresses 1111 1110 10 1/1024 283 Site-Local Unicast Addresses 1111 1110 11 1/1024 285 Multicast Addresses 1111 1111 1/256 287 Notes: 289 (1) The "unspecified address" (see section 2.5.2), the loopback 290 address (see section 2.5.3), and the IPv6 Addresses with 291 Embedded IPv4 Addresses (see section 2.5.4), are assigned out 292 of the 0000 0000 format prefix space. 294 (2) The format prefixes 001 through 111, except for Multicast 295 Addresses (1111 1111), are all required to have to have 64-bit 296 interface identifiers in EUI-64 format. See section 2.5.1 for 297 definitions. 299 This allocation supports the direct allocation of aggregation 300 addresses, local use addresses, and multicast addresses. Space is 301 reserved for NSAP addresses and IPX addresses. The remainder of the 302 address space is unassigned for future use. This can be used for 303 expansion of existing use (e.g., additional aggregatable addresses, 304 etc.) or new uses (e.g., separate locators and identifiers). Fifteen 305 percent of the address space is initially allocated. The remaining 306 85% is reserved for future use. 308 Unicast addresses are distinguished from multicast addresses by the 309 value of the high-order octet of the addresses: a value of FF 310 (11111111) identifies an address as a multicast address; any other 311 value identifies an address as a unicast address. Anycast addresses 312 are taken from the unicast address space, and are not syntactically 313 distinguishable from unicast addresses. 315 2.5 Unicast Addresses 317 IPv6 unicast addresses are aggregatable with contiguous bit-wise 318 masks similar to IPv4 addresses under Class-less Interdomain Routing 319 [CIDR]. 321 There are several forms of unicast address assignment in IPv6, 322 including the global aggregatable global unicast address, the NSAP 323 address, the IPX hierarchical address, the site-local address, the 324 link-local address, and the IPv4-capable host address. Additional 325 address types can be defined in the future. 327 IPv6 nodes may have considerable or little knowledge of the internal 328 structure of the IPv6 address, depending on the role the node plays 329 (for instance, host versus router). At a minimum, a node may 330 consider that unicast addresses (including its own) have no internal 331 structure: 333 | 128 bits | 334 +-----------------------------------------------------------------+ 335 | node address | 336 +-----------------------------------------------------------------+ 338 A slightly sophisticated host (but still rather simple) may 339 additionally be aware of subnet prefix(es) for the link(s) it is 340 attached to, where different addresses may have different values for 341 n: 343 | n bits | 128-n bits | 344 +------------------------------------------------+----------------+ 345 | subnet prefix | interface ID | 346 +------------------------------------------------+----------------+ 347 Still more sophisticated hosts may be aware of other hierarchical 348 boundaries in the unicast address. Though a very simple router may 349 have no knowledge of the internal structure of IPv6 unicast 350 addresses, routers will more generally have knowledge of one or more 351 of the hierarchical boundaries for the operation of routing 352 protocols. The known boundaries will differ from router to router, 353 depending on what positions the router holds in the routing 354 hierarchy. 356 2.5.1 Interface Identifiers 358 Interface identifiers in IPv6 unicast addresses are used to identify 359 interfaces on a link. They are required to be unique on that link. 360 They may also be unique over a broader scope. In many cases an 361 interface's identifier will be the same as that interface's link- 362 layer address. The same interface identifier may be used on multiple 363 interfaces on a single node. 365 Note that the use of the same interface identifier on multiple 366 interfaces of a single node does not affect the interface 367 identifier's global uniqueness or each IPv6 addresses global 368 uniqueness created using that interface identifier. 370 In a number of the format prefixes (see section 2.4) Interface IDs 371 are required to be 64 bits long and to be constructed in IEEE EUI-64 372 format [EUI64]. EUI-64 based Interface identifiers may have global 373 scope when a global token is available (e.g., IEEE 48bit MAC) or may 374 have local scope where a global token is not available (e.g., serial 375 links, tunnel end-points, etc.). It is required that the "u" bit 376 (universal/local bit in IEEE EUI-64 terminology) be inverted when 377 forming the interface identifier from the EUI-64. The "u" bit is set 378 to one (1) to indicate global scope, and it is set to zero (0) to 379 indicate local scope. The first three octets in binary of an EUI-64 380 identifier are as follows: 382 0 0 0 1 1 2 383 |0 7 8 5 6 3| 384 +----+----+----+----+----+----+ 385 |cccc|ccug|cccc|cccc|cccc|cccc| 386 +----+----+----+----+----+----+ 388 written in Internet standard bit-order , where "u" is the 389 universal/local bit, "g" is the individual/group bit, and "c" are the 390 bits of the company_id. Appendix A: "Creating EUI-64 based Interface 391 Identifiers" provides examples on the creation of different EUI-64 392 based interface identifiers. 394 This use of the universal/local bit in the IEEE EUI-64 identifier is 395 to allow development of future technology that can take advantage of 396 interface identifiers with global scope. 398 The details of forming interface identifiers are defined in the 399 appropriate "IPv6 over " specification such as "IPv6 over 400 Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. 402 2.5.2 The Unspecified Address 404 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It 405 must never be assigned to any node. It indicates the absence of an 406 address. One example of its use is in the Source Address field of 407 any IPv6 packets sent by an initializing host before it has learned 408 its own address. 410 The unspecified address must not be used as the destination address 411 of IPv6 packets or in IPv6 Routing Headers. 413 2.5.3 The Loopback Address 415 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. 416 It may be used by a node to send an IPv6 packet to itself. It may 417 never be assigned to any physical interface. It may be thought of as 418 being associated with a virtual interface (e.g., the loopback 419 interface). 421 The loopback address must not be used as the source address in IPv6 422 packets that are sent outside of a single node. An IPv6 packet with 423 a destination address of loopback must never be sent outside of a 424 single node and must never be forwarded by an IPv6 router. 426 2.5.4 IPv6 Addresses with Embedded IPv4 Addresses 428 The IPv6 transition mechanisms [TRAN] include a technique for hosts 429 and routers to dynamically tunnel IPv6 packets over IPv4 routing 430 infrastructure. IPv6 nodes that utilize this technique are assigned 431 special IPv6 unicast addresses that carry an IPv4 address in the low- 432 order 32-bits. This type of address is termed an "IPv4-compatible 433 IPv6 address" and has the format: 435 | 80 bits | 16 | 32 bits | 436 +--------------------------------------+--------------------------+ 437 |0000..............................0000|0000| IPv4 address | 438 +--------------------------------------+----+---------------------+ 440 A second type of IPv6 address which holds an embedded IPv4 address is 441 also defined. This address is used to represent the addresses of 442 IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. 443 This type of address is termed an "IPv4-mapped IPv6 address" and has 444 the format: 446 | 80 bits | 16 | 32 bits | 447 +--------------------------------------+--------------------------+ 448 |0000..............................0000|FFFF| IPv4 address | 449 +--------------------------------------+----+---------------------+ 451 2.5.5 NSAP Addresses 453 This mapping of NSAP address into IPv6 addresses is defined in 454 [NSAP]. This document recommends that network implementors who have 455 planned or deployed an OSI NSAP addressing plan, and who wish to 456 deploy or transition to IPv6, should redesign a native IPv6 457 addressing plan to meet their needs. However, it also defines a set 458 of mechanisms for the support of OSI NSAP addressing in an IPv6 459 network. These mechanisms are the ones that must be used if such 460 support is required. This document also defines a mapping of IPv6 461 addresses within the OSI address format, should this be required. 463 2.5.6 IPX Addresses 465 This mapping of IPX address into IPv6 addresses is as follows: 467 | 7 | 121 bits | 468 +-------+---------------------------------------------------------+ 469 |0000010| to be defined | 470 +-------+---------------------------------------------------------+ 472 The draft definition, motivation, and usage are under study. 474 2.5.7 Aggregatable Global Unicast Addresses 476 The global aggregatable global unicast address is defined in [AGGR]. 477 This address format is designed to support both the current provider 478 based aggregation and a new type of aggregation called exchanges. 479 The combination will allow efficient routing aggregation for both 480 sites which connect directly to providers and who connect to 481 exchanges. Sites will have the choice to connect to either type of 482 aggregation point. 484 The IPv6 aggregatable global unicast address format is as follows: 486 | 3| 13 | 8 | 24 | 16 | 64 bits | 487 +--+-----+---+--------+--------+--------------------------------+ 488 |FP| TLA |RES| NLA | SLA | Interface ID | 489 | | ID | | ID | ID | | 490 +--+-----+---+--------+--------+--------------------------------+ 492 Where 494 001 Format Prefix (3 bit) for Aggregatable Global 495 Unicast Addresses 496 TLA ID Top-Level Aggregation Identifier 497 RES Reserved for future use 498 NLA ID Next-Level Aggregation Identifier 499 SLA ID Site-Level Aggregation Identifier 500 INTERFACE ID Interface Identifier 502 The contents, field sizes, and assignment rules are defined in 503 [AGGR]. 505 2.5.8 Local-Use IPv6 Unicast Addresses 507 There are two types of local-use unicast addresses defined. These 508 are Link-Local and Site-Local. The Link-Local is for use on a single 509 link and the Site-Local is for use in a single site. Link-Local 510 addresses have the following format: 512 | 10 | 513 | bits | 54 bits | 64 bits | 514 +----------+-------------------------+----------------------------+ 515 |1111111010| 0 | interface ID | 516 +----------+-------------------------+----------------------------+ 518 Link-Local addresses are designed to be used for addressing on a 519 single link for purposes such as auto-address configuration, neighbor 520 discovery, or when no routers are present. 522 Routers must not forward any packets with link-local source or 523 destination addresses to other links. 525 Site-Local addresses have the following format: 527 | 10 | 528 | bits | 38 bits | 16 bits | 64 bits | 529 +----------+-------------+-----------+----------------------------+ 530 |1111111011| 0 | subnet ID | interface ID | 531 +----------+-------------+-----------+----------------------------+ 533 Site-Local addresses are designed to be used for addressing inside of 534 a site without the need for a global prefix. 536 Routers must not forward any packets with site-local source or 537 destination addresses outside of the site. 539 2.6 Anycast Addresses 541 An IPv6 anycast address is an address that is assigned to more than 542 one interface (typically belonging to different nodes), with the 543 property that a packet sent to an anycast address is routed to the 544 "nearest" interface having that address, according to the routing 545 protocols' measure of distance. 547 Anycast addresses are allocated from the unicast address space, using 548 any of the defined unicast address formats. Thus, anycast addresses 549 are syntactically indistinguishable from unicast addresses. When a 550 unicast address is assigned to more than one interface, thus turning 551 it into an anycast address, the nodes to which the address is 552 assigned must be explicitly configured to know that it is an anycast 553 address. 555 For any assigned anycast address, there is a longest address prefix P 556 that identifies the topological region in which all interfaces 557 belonging to that anycast address reside. Within the region 558 identified by P, each member of the anycast set must be advertised as 559 a separate entry in the routing system (commonly referred to as a 560 "host route"); outside the region identified by P, the anycast 561 address may be aggregated into the routing advertisement for prefix 562 P. 564 Note that in, the worst case, the prefix P of an anycast set may be 565 the null prefix, i.e., the members of the set may have no topological 566 locality. In that case, the anycast address must be advertised as a 567 separate routing entry throughout the entire internet, which presents 568 a severe scaling limit on how many such "global" anycast sets may be 569 supported. Therefore, it is expected that support for global anycast 570 sets may be unavailable or very restricted. 572 One expected use of anycast addresses is to identify the set of 573 routers belonging to an organization providing internet service. 574 Such addresses could be used as intermediate addresses in an IPv6 575 Routing header, to cause a packet to be delivered via a particular 576 aggregation or sequence of aggregations. Some other possible uses 577 are to identify the set of routers attached to a particular subnet, 578 or the set of routers providing entry into a particular routing 579 domain. 581 There is little experience with widespread, arbitrary use of internet 582 anycast addresses, and some known complications and hazards when 583 using them in their full generality [ANYCST]. Until more experience 584 has been gained and solutions agreed upon for those problems, the 585 following restrictions are imposed on IPv6 anycast addresses: 587 o An anycast address must not be used as the source address of an 588 IPv6 packet. 590 o An anycast address must not be assigned to an IPv6 host, that 591 is, it may be assigned to an IPv6 router only. 593 2.6.1 Required Anycast Address 595 The Subnet-Router anycast address is predefined. Its format is as 596 follows: 598 | n bits | 128-n bits | 599 +------------------------------------------------+----------------+ 600 | subnet prefix | 00000000000000 | 601 +------------------------------------------------+----------------+ 603 The "subnet prefix" in an anycast address is the prefix which 604 identifies a specific link. This anycast address is syntactically 605 the same as a unicast address for an interface on the link with the 606 interface identifier set to zero. 608 Packets sent to the Subnet-Router anycast address will be delivered 609 to one router on the subnet. All routers are required to support the 610 Subnet-Router anycast addresses for the subnets which they have 611 interfaces. 613 The subnet-router anycast address is intended to be used for 614 applications where a node needs to communicate with one of a set of 615 routers on a remote subnet. For example when a mobile host needs to 616 communicate with one of the mobile agents on its "home" subnet. 618 2.7 Multicast Addresses 620 An IPv6 multicast address is an identifier for a group of nodes. A 621 node may belong to any number of multicast groups. Multicast 622 addresses have the following format: 624 | 8 | 4 | 4 | 112 bits | 625 +------ -+----+----+---------------------------------------------+ 626 |11111111|flgs|scop| group ID | 627 +--------+----+----+---------------------------------------------+ 629 11111111 at the start of the address identifies the address as 630 being a multicast address. 632 +-+-+-+-+ 633 flgs is a set of 4 flags: |0|0|0|T| 634 +-+-+-+-+ 636 The high-order 3 flags are reserved, and must be 637 initialized to 0. 639 T = 0 indicates a permanently-assigned ("well-known") 640 multicast address, assigned by the global internet 641 numbering authority. 643 T = 1 indicates a non-permanently-assigned ("transient") 644 multicast address. 646 scop is a 4-bit multicast scope value used to limit the scope of 647 the multicast group. The values are: 649 0 reserved 650 1 node-local scope 651 2 link-local scope 652 3 (unassigned) 653 4 (unassigned) 654 5 site-local scope 655 6 (unassigned) 656 7 (unassigned) 657 8 organization-local scope 658 9 (unassigned) 659 A (unassigned) 660 B (unassigned) 661 C (unassigned) 662 D (unassigned) 663 E global scope 664 F reserved 666 group ID identifies the multicast group, either permanent or 667 transient, within the given scope. 669 The "meaning" of a permanently-assigned multicast address is 670 independent of the scope value. For example, if the "NTP servers 671 group" is assigned a permanent multicast address with a group ID of 672 101 (hex), then: 674 FF01:0:0:0:0:0:0:101 means all NTP servers on the same node as 675 the sender. 677 FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as 678 the sender. 680 FF05:0:0:0:0:0:0:101 means all NTP servers at the same site as 681 the sender. 683 FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet. 685 Non-permanently-assigned multicast addresses are meaningful only 686 within a given scope. For example, a group identified by the non- 687 permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one 688 site bears no relationship to a group using the same address at a 689 different site, nor to a non-permanent group using the same group ID 690 with different scope, nor to a permanent group with the same group 691 ID. 693 Multicast addresses must not be used as source addresses in IPv6 694 packets or appear in any routing header. 696 2.7.1 Pre-Defined Multicast Addresses 698 The following well-known multicast addresses are pre-defined: 700 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 701 FF01:0:0:0:0:0:0:0 702 FF02:0:0:0:0:0:0:0 703 FF03:0:0:0:0:0:0:0 704 FF04:0:0:0:0:0:0:0 705 FF05:0:0:0:0:0:0:0 706 FF06:0:0:0:0:0:0:0 707 FF07:0:0:0:0:0:0:0 708 FF08:0:0:0:0:0:0:0 709 FF09:0:0:0:0:0:0:0 710 FF0A:0:0:0:0:0:0:0 711 FF0B:0:0:0:0:0:0:0 712 FF0C:0:0:0:0:0:0:0 713 FF0D:0:0:0:0:0:0:0 714 FF0E:0:0:0:0:0:0:0 715 FF0F:0:0:0:0:0:0:0 717 The above multicast addresses are reserved and shall never be 718 assigned to any multicast group. 720 All Nodes Addresses: FF01:0:0:0:0:0:0:1 721 FF02:0:0:0:0:0:0:1 723 The above multicast addresses identify the group of all IPv6 nodes, 724 within scope 1 (node-local) or 2 (link-local). 726 All Routers Addresses: FF01:0:0:0:0:0:0:2 727 FF02:0:0:0:0:0:0:2 728 FF05:0:0:0:0:0:0:2 730 The above multicast addresses identify the group of all IPv6 routers, 731 within scope 1 (node-local), 2 (link-local), or 5 (site-local). 733 Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX 735 The above multicast address is computed as a function of a node's 736 unicast and anycast addresses. The solicited-node multicast address 737 is formed by taking the low-order 24 bits of the address (unicast or 738 anycast) and appending those bits to the prefix 739 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 740 range 742 FF02:0:0:0:0:1:FF00:0000 744 to 746 FF02:0:0:0:0:1:FFFF:FFFF 748 For example, the solicited node multicast address corresponding to 749 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 750 addresses that differ only in the high-order bits, e.g. due to 751 multiple high-order prefixes associated with different aggregations, 752 will map to the same solicited-node address thereby reducing the 753 number of multicast addresses a node must join. 755 A node is required to compute and join the associated Solicited-Node 756 multicast addresses for every unicast and anycast address it is 757 assigned. 759 2.7.2 Assignment of New IPv6 Multicast Addresses 761 The current approach [ETHER] to map IPv6 multicast addresses into 762 IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 763 multicast address and uses it to create a MAC address. Note that 764 Token Ring networks are handled differently. This is defined in 765 [TOKEN]. Group ID's less than or equal to 32 bits will generate 766 unique MAC addresses. Due to this new IPv6 multicast addresses 767 should be assigned so that the group identifier is always in the low 768 order 32 bits as shown in the following: 770 | 8 | 4 | 4 | 80 bits | 32 bits | 771 +------ -+----+----+---------------------------+-----------------+ 772 |11111111|flgs|scop| reserved must be zero | group ID | 773 +--------+----+----+---------------------------+-----------------+ 775 While this limits the number of permanent IPv6 multicast groups to 776 2^32 this is unlikely to be a limitation in the future. If it 777 becomes necessary to exceed this limit in the future multicast will 778 still work but the processing will be sightly slower. 780 Additional IPv6 multicast addresses are defined and registered by the 781 IANA [MASGN]. 783 2.8 A Node's Required Addresses 785 A host is required to recognize the following addresses as 786 identifying itself: 788 o Its Link-Local Address for each interface 789 o Assigned Unicast Addresses 790 o Loopback Address 791 o All-Nodes Multicast Addresses 792 o Solicited-Node Multicast Address for each of its assigned 793 unicast and anycast addresses 794 o Multicast Addresses of all other groups to which the host 795 belongs. 797 A router is required to recognize all addresses that a host is 798 required to recognize, plus the following addresses as identifying 799 itself: 801 o The Subnet-Router anycast addresses for the interfaces it is 802 configured to act as a router on. 803 o All other Anycast addresses with which the router has been 804 configured. 805 o All-Routers Multicast Addresses 806 o Multicast Addresses of all other groups to which the router 807 belongs. 809 The only address prefixes which should be predefined in an 810 implementation are the: 812 o Unspecified Address 813 o Loopback Address 814 o Multicast Prefix (FF) 815 o Local-Use Prefixes (Link-Local and Site-Local) 816 o Pre-Defined Multicast Addresses 817 o IPv4-Compatible Prefixes 819 Implementations should assume all other addresses are unicast unless 820 specifically configured (e.g., anycast addresses). 822 3. Security Considerations 824 IPv6 addressing documents do not have any direct impact on Internet 825 infrastructure security. Authentication of IPv6 packets is defined 826 in [AUTH]. 828 APPENDIX A : Creating EUI-64 based Interface Identifiers 829 -------------------------------------------------------- 831 Depending on the characteristics of a specific link or node there are 832 a number of approaches for creating EUI-64 based interface 833 identifiers. This appendix describes some of these approaches. 835 Links or Nodes with EUI-64 Identifiers 837 The only change needed to transform an EUI-64 identifier to an 838 interface identifier is to invert the "u" (universal/local) bit. For 839 example, a globally unique EUI-64 identifier of the form: 841 |0 1|1 3|3 4|4 6| 842 |0 5|6 1|2 7|8 3| 843 +----------------+----------------+----------------+----------------+ 844 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 845 +----------------+----------------+----------------+----------------+ 847 where "c" are the bits of the assigned company_id, "0" is the value 848 of the universal/local bit to indicate global scope, "g" is 849 individual/group bit, and "m" are the bits of the manufacturer- 850 selected extension identifier. The IPv6 interface identifier would 851 be of the form: 853 |0 1|1 3|3 4|4 6| 854 |0 5|6 1|2 7|8 3| 855 +----------------+----------------+----------------+----------------+ 856 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 857 +----------------+----------------+----------------+----------------+ 859 The only change is inverting the value of the universal/local bit. 861 Links or Nodes with IEEE 802 48 bit MAC's 863 [EUI64] defines a method to create a EUI-64 identifier from an IEEE 864 48bit MAC identifier. This is to insert two octets, with hexadecimal 865 values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the 866 company_id and vendor supplied id). For example the 48 bit MAC with 867 global scope: 869 |0 1|1 3|3 4| 870 |0 5|6 1|2 7| 871 +----------------+----------------+----------------+ 872 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 873 +----------------+----------------+----------------+ 875 where "c" are the bits of the assigned company_id, "0" is the value 876 of the universal/local bit to indicate global scope, "g" is 877 individual/group bit, and "m" are the bits of the manufacturer- 878 selected extension identifier. The interface identifier would be of 879 the form: 881 |0 1|1 3|3 4|4 6| 882 |0 5|6 1|2 7|8 3| 883 +----------------+----------------+----------------+----------------+ 884 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 885 +----------------+----------------+----------------+----------------+ 887 When IEEE 802 48bit MAC addresses are available (on an interface or a 888 node), an implementation should use them to create interface 889 identifiers due to their availability and uniqueness properties. 891 Links with Non-Global Identifiers 893 There are a number of types of links that, while multi-access, do not 894 have globally unique link identifiers. Examples include LocalTalk 895 and Arcnet. The method to create an EUI-64 formatted identifier is 896 to take the link identifier (e.g., the LocalTalk 8 bit node 897 identifier) and zero fill it to the left. For example a LocalTalk 8 898 bit node identifier of hexadecimal value 0x4F results in the 899 following interface identifier: 901 |0 1|1 3|3 4|4 6| 902 |0 5|6 1|2 7|8 3| 903 +----------------+----------------+----------------+----------------+ 904 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 905 +----------------+----------------+----------------+----------------+ 907 Note that this results in the universal/local bit set to "0" to 908 indicate local scope. 910 Links without Identifiers 912 There are a number of links that do not have any type of built-in 913 identifier. The most common of these are serial links and configured 914 tunnels. Interface identifiers must be chosen that are unique for 915 the link. 917 When no built-in identifier is available on a link the preferred 918 approach is to use a global interface identifier from another 919 interface or one which is assigned to the node itself. To use this 920 approach no other interface connecting the same node to the same link 921 may use the same identifier. 923 If there is no global interface identifier available for use on the 924 link the implementation needs to create a local scope interface 925 identifier. The only requirement is that it be unique on the link. 926 There are many possible approaches to select a link-unique interface 927 identifier. They include: 929 Manual Configuration 930 Generated Random Number 931 Node Serial Number (or other node-specific token) 933 The link-unique interface identifier should be generated in a manner 934 that it does not change after a reboot of a node or if interfaces are 935 added or deleted from the node. 937 The selection of the appropriate algorithm is link and implementation 938 dependent. The details on forming interface identifiers are defined 939 in the appropriate "IPv6 over " specification. It is strongly 940 recommended that a collision detection algorithm be implemented as 941 part of any automatic algorithm. 943 APPENDIX B: ABNF Description of Text Representations 944 ---------------------------------------------------- 946 This appendix defines the text representation of IPv6 addresses and 947 prefixes in Augmented BNF [ABNF] for reference purposes. 949 IPv6address = hexpart [ ":" IPv4address ] 950 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 952 IPv6prefix = hexpart "/" 1*2DIGIT 954 hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] 955 hexseq = hex4 *( ":" hex4) 956 hex4 = 1*4HEXDIG 958 APPENDIX C: CHANGES FROM RFC-1884 959 --------------------------------- 961 The following changes were made from RFC-1884 "IP Version 6 962 Addressing Architecture": 964 - Added an appendix providing a ABNF description of text 965 representations. 966 - Clarification that link unique identifiers not change after 967 reboot or other interface reconfigurations. 968 - Clarification of Address Model based on comments. 969 - Changed aggregation format terminology to be consistent with 970 aggregation draft. 971 - Added text to allow interface identifier to be used on more than 972 one interface on same node. 973 - Added rules for defining new multicast addresses. 974 - Added appendix describing procedures for creating EUI-64 based 975 interface ID's. 976 - Added notation for defining IPv6 prefixes. 977 - Changed solicited node multicast definition to use a longer 978 prefix. 979 - Added site scope all routers multicast address. 980 - Defined Aggregatable Global Unicast Addresses to use "001" Format 981 Prefix. 982 - Changed "010" (Provider-Based Unicast) and "100" (Reserved for 983 Geographic) Format Prefixes to Unassigned. 984 - Added section on Interface ID definition for unicast addresses. 985 Requires use of EUI-64 in range of format prefixes and rules for 986 setting global/local scope bit in EUI-64. 987 - Updated NSAP text to reflect working in RFC1888. 988 - Removed protocol specific IPv6 multicast addresses (e.g., DHCP) 989 and referenced the IANA definitions. 990 - Removed section "Unicast Address Example". Had become OBE. 991 - Added new and updated references. 992 - Minor text clarifications and improvements. 994 REFERENCES 996 [ABNF] Crocker, D., P. Overell, "Augmented BNF for Syntax 997 Specifications: ABNF", Internet Draft, , October 1997. 1000 [AGGR] Hinden, R., S. Deering, M. O'Dell, "An Aggregatable Global 1001 Unicast Address Format", internet draft, , January 1998. 1004 [AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August 1005 1995. 1007 [ANYCST] Partridge, C., T. Mendez, and W. Milliken, "Host Anycasting 1008 Service", RFC1546, November 1993. 1010 [CIDR] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless Inter- 1011 Domain Routing (CIDR): An Address Assignment and 1012 Aggregation Strategy", RFC1519, September 1993. 1014 [ETHER] Crawford, M., "Transmission of IPv6 Pacekts over Ethernet 1015 Networks", Internet Draft, , November 1997. 1018 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 1019 Registration Authority", 1020 http://standards.ieee.org/db/oui/tutorials/EUI64.html, 1021 March 1997. 1023 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 1024 Networks", Internet Draft, , March 1997. 1027 [IPV6] Deering, S., R. Hinden, Editors, "Internet Protocol, 1028 Version 6 (IPv6) Specification", RFC1883, December 1995. 1030 [MASGN] Hinden, R., "IPv6 Multicast Address Assignments", Internet 1031 Draft, , May 1032 1997. 1034 [NSAP] Bound, J., B. Carpenter, D. Harrington, J. Houldsworth, A. 1035 Lloyd, "OSI NSAPs and IPv6", RFC1888, August 1996. 1037 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1038 Requirement Levels", RFC2119, BCP14, March 1997. 1040 [TOKEN] Thomas, S., "Transmission of IPv6 Packets over Token Ring 1041 Networks", Internet Draft, June 1997. 1043 [TRAN] Gilligan, R., E. Nordmark, "Transition Mechanisms for IPv6 1044 Hosts and Routers", RFC1993, April 1996. 1046 AUTHOR'S ADDRESSES 1048 Robert M. Hinden Stephen E. Deering 1049 Nokia Cisco Systems, Inc. 1050 232 Java Drive 170 West Tasman Drive 1051 Sunnyvale, CA 94089 San Jose, CA 95134-1706 1052 USA USA 1054 phone: +1 408 990-2004 phone: +1 408 527-8213 1055 fax: +1 408 743-5677 fax: +1 408 527-8254 1056 email: hinden@ipsilon.com email: deering@cisco.com