idnits 2.17.1 draft-ietf-ipngwg-addr-arch-v2-05.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-27) 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 1036, 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, Ipsilon Networks 2 November 10, 1997 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 May 10, 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 | 32 | 16 | 64 bits | 487 +---+-----+-----------+--------+--------------------------------+ 488 |FP | TLA | NLA ID | SLA ID | Interface ID | 489 | | ID | | | | 490 +---+-----+-----------+--------+--------------------------------+ 492 Where 494 001 Format Prefix (3 bit) for Aggregatable Global 495 Unicast Addresses 496 TLA ID Top-Level Aggregation Identifier 497 NLA ID Next-Level Aggregation Identifier 498 SLA ID Site-Level Aggregation Identifier 499 INTERFACE ID Interface Identifier 501 The contents, field sizes, and assignment rules are defined in 502 [AGGR]. 504 2.5.8 Local-Use IPv6 Unicast Addresses 506 There are two types of local-use unicast addresses defined. These 507 are Link-Local and Site-Local. The Link-Local is for use on a single 508 link and the Site-Local is for use in a single site. Link-Local 509 addresses have the following format: 511 | 10 | 512 | bits | 54 bits | 64 bits | 513 +----------+-------------------------+----------------------------+ 514 |1111111010| 0 | interface ID | 515 +----------+-------------------------+----------------------------+ 517 Link-Local addresses are designed to be used for addressing on a 518 single link for purposes such as auto-address configuration, neighbor 519 discovery, or when no routers are present. 521 Routers must not forward any packets with link-local source or 522 destination addresses to other links. 524 Site-Local addresses have the following format: 526 | 10 | 527 | bits | 38 bits | 16 bits | 64 bits | 528 +----------+-------------+-----------+----------------------------+ 529 |1111111011| 0 | subnet ID | interface ID | 530 +----------+-------------+-----------+----------------------------+ 532 Site-Local addresses are designed to be used for addressing inside of 533 a site without the need for a global prefix. 535 Routers must not forward any packets with site-local source or 536 destination addresses outside of the site. 538 2.6 Anycast Addresses 540 An IPv6 anycast address is an address that is assigned to more than 541 one interface (typically belonging to different nodes), with the 542 property that a packet sent to an anycast address is routed to the 543 "nearest" interface having that address, according to the routing 544 protocols' measure of distance. 546 Anycast addresses are allocated from the unicast address space, using 547 any of the defined unicast address formats. Thus, anycast addresses 548 are syntactically indistinguishable from unicast addresses. When a 549 unicast address is assigned to more than one interface, thus turning 550 it into an anycast address, the nodes to which the address is 551 assigned must be explicitly configured to know that it is an anycast 552 address. 554 For any assigned anycast address, there is a longest address prefix P 555 that identifies the topological region in which all interfaces 556 belonging to that anycast address reside. Within the region 557 identified by P, each member of the anycast set must be advertised as 558 a separate entry in the routing system (commonly referred to as a 559 "host route"); outside the region identified by P, the anycast 560 address may be aggregated into the routing advertisement for prefix 561 P. 563 Note that in, the worst case, the prefix P of an anycast set may be 564 the null prefix, i.e., the members of the set may have no topological 565 locality. In that case, the anycast address must be advertised as a 566 separate routing entry throughout the entire internet, which presents 567 a severe scaling limit on how many such "global" anycast sets may be 568 supported. Therefore, it is expected that support for global anycast 569 sets may be unavailable or very restricted. 571 One expected use of anycast addresses is to identify the set of 572 routers belonging to an organization providing internet service. 573 Such addresses could be used as intermediate addresses in an IPv6 574 Routing header, to cause a packet to be delivered via a particular 575 aggregation or sequence of aggregations. Some other possible uses 576 are to identify the set of routers attached to a particular subnet, 577 or the set of routers providing entry into a particular routing 578 domain. 580 There is little experience with widespread, arbitrary use of internet 581 anycast addresses, and some known complications and hazards when 582 using them in their full generality [ANYCST]. Until more experience 583 has been gained and solutions agreed upon for those problems, the 584 following restrictions are imposed on IPv6 anycast addresses: 586 o An anycast address must not be used as the source address of an 587 IPv6 packet. 589 o An anycast address must not be assigned to an IPv6 host, that 590 is, it may be assigned to an IPv6 router only. 592 2.6.1 Required Anycast Address 594 The Subnet-Router anycast address is predefined. Its format is as 595 follows: 597 | n bits | 128-n bits | 598 +------------------------------------------------+----------------+ 599 | subnet prefix | 00000000000000 | 600 +------------------------------------------------+----------------+ 602 The "subnet prefix" in an anycast address is the prefix which 603 identifies a specific link. This anycast address is syntactically 604 the same as a unicast address for an interface on the link with the 605 interface identifier set to zero. 607 Packets sent to the Subnet-Router anycast address will be delivered 608 to one router on the subnet. All routers are required to support the 609 Subnet-Router anycast addresses for the subnets which they have 610 interfaces. 612 The subnet-router anycast address is intended to be used for 613 applications where a node needs to communicate with one of a set of 614 routers on a remote subnet. For example when a mobile host needs to 615 communicate with one of the mobile agents on its "home" subnet. 617 2.7 Multicast Addresses 619 An IPv6 multicast address is an identifier for a group of nodes. A 620 node may belong to any number of multicast groups. Multicast 621 addresses have the following format: 623 | 8 | 4 | 4 | 112 bits | 624 +------ -+----+----+---------------------------------------------+ 625 |11111111|flgs|scop| group ID | 626 +--------+----+----+---------------------------------------------+ 628 11111111 at the start of the address identifies the address as 629 being a multicast address. 631 +-+-+-+-+ 632 flgs is a set of 4 flags: |0|0|0|T| 633 +-+-+-+-+ 635 The high-order 3 flags are reserved, and must be 636 initialized to 0. 638 T = 0 indicates a permanently-assigned ("well-known") 639 multicast address, assigned by the global internet 640 numbering authority. 642 T = 1 indicates a non-permanently-assigned ("transient") 643 multicast address. 645 scop is a 4-bit multicast scope value used to limit the scope of 646 the multicast group. The values are: 648 0 reserved 649 1 node-local scope 650 2 link-local scope 651 3 (unassigned) 652 4 (unassigned) 653 5 site-local scope 654 6 (unassigned) 655 7 (unassigned) 656 8 organization-local scope 657 9 (unassigned) 658 A (unassigned) 659 B (unassigned) 660 C (unassigned) 661 D (unassigned) 662 E global scope 663 F reserved 665 group ID identifies the multicast group, either permanent or 666 transient, within the given scope. 668 The "meaning" of a permanently-assigned multicast address is 669 independent of the scope value. For example, if the "NTP servers 670 group" is assigned a permanent multicast address with a group ID of 671 101 (hex), then: 673 FF01:0:0:0:0:0:0:101 means all NTP servers on the same node as 674 the sender. 676 FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as 677 the sender. 679 FF05:0:0:0:0:0:0:101 means all NTP servers at the same site as 680 the sender. 682 FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet. 684 Non-permanently-assigned multicast addresses are meaningful only 685 within a given scope. For example, a group identified by the non- 686 permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one 687 site bears no relationship to a group using the same address at a 688 different site, nor to a non-permanent group using the same group ID 689 with different scope, nor to a permanent group with the same group 690 ID. 692 Multicast addresses must not be used as source addresses in IPv6 693 packets or appear in any routing header. 695 2.7.1 Pre-Defined Multicast Addresses 697 The following well-known multicast addresses are pre-defined: 699 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 700 FF01:0:0:0:0:0:0:0 701 FF02:0:0:0:0:0:0:0 702 FF03:0:0:0:0:0:0:0 703 FF04:0:0:0:0:0:0:0 704 FF05:0:0:0:0:0:0:0 705 FF06:0:0:0:0:0:0:0 706 FF07:0:0:0:0:0:0:0 707 FF08:0:0:0:0:0:0:0 708 FF09:0:0:0:0:0:0:0 709 FF0A:0:0:0:0:0:0:0 710 FF0B:0:0:0:0:0:0:0 711 FF0C:0:0:0:0:0:0:0 712 FF0D:0:0:0:0:0:0:0 713 FF0E:0:0:0:0:0:0:0 714 FF0F:0:0:0:0:0:0:0 716 The above multicast addresses are reserved and shall never be 717 assigned to any multicast group. 719 All Nodes Addresses: FF01:0:0:0:0:0:0:1 720 FF02:0:0:0:0:0:0:1 722 The above multicast addresses identify the group of all IPv6 nodes, 723 within scope 1 (node-local) or 2 (link-local). 725 All Routers Addresses: FF01:0:0:0:0:0:0:2 726 FF02:0:0:0:0:0:0:2 727 FF05:0:0:0:0:0:0:2 729 The above multicast addresses identify the group of all IPv6 routers, 730 within scope 1 (node-local), 2 (link-local), or 5 (site-local). 732 Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX 734 The above multicast address is computed as a function of a node's 735 unicast and anycast addresses. The solicited-node multicast address 736 is formed by taking the low-order 24 bits of the address (unicast or 737 anycast) and appending those bits to the prefix 738 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 739 range 741 FF02:0:0:0:0:1:FF00:0000 743 to 745 FF02:0:0:0:0:1:FFFF:FFFF 747 For example, the solicited node multicast address corresponding to 748 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 749 addresses that differ only in the high-order bits, e.g. due to 750 multiple high-order prefixes associated with different aggregations, 751 will map to the same solicited-node address thereby reducing the 752 number of multicast addresses a node must join. 754 A node is required to compute and join the associated Solicited-Node 755 multicast addresses for every unicast and anycast address it is 756 assigned. 758 2.7.2 Assignment of New IPv6 Multicast Addresses 760 The current approach [ETHER] to map IPv6 multicast addresses into 761 IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 762 multicast address and uses it to create a MAC address. Note that 763 Token Ring networks are handled differently. This is defined in 764 [TOKEN]. Group ID's less than or equal to 32 bits will generate 765 unique MAC addresses. Due to this new IPv6 multicast addresses 766 should be assigned so that the group identifier is always in the low 767 order 32 bits as shown in the following: 769 | 8 | 4 | 4 | 80 bits | 32 bits | 770 +------ -+----+----+---------------------------+-----------------+ 771 |11111111|flgs|scop| reserved must be zero | group ID | 772 +--------+----+----+---------------------------+-----------------+ 774 While this limits the number of permanent IPv6 multicast groups to 775 2^32 this is unlikely to be a limitation in the future. If it 776 becomes necessary to exceed this limit in the future multicast will 777 still work but the processing will be sightly slower. 779 Additional IPv6 multicast addresses are defined and registered by the 780 IANA [MASGN]. 782 2.8 A Node's Required Addresses 784 A host is required to recognize the following addresses as 785 identifying itself: 787 o Its Link-Local Address for each interface 788 o Assigned Unicast Addresses 789 o Loopback Address 790 o All-Nodes Multicast Addresses 791 o Solicited-Node Multicast Address for each of its assigned 792 unicast and anycast addresses 793 o Multicast Addresses of all other groups to which the host 794 belongs. 796 A router is required to recognize all addresses that a host is 797 required to recognize, plus the following addresses as identifying 798 itself: 800 o The Subnet-Router anycast addresses for the interfaces it is 801 configured to act as a router on. 802 o All other Anycast addresses with which the router has been 803 configured. 804 o All-Routers Multicast 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 3. Security Considerations 823 IPv6 addressing documents do not have any direct impact on Internet 824 infrastructure security. Authentication of IPv6 packets is defined 825 in [AUTH]. 827 APPENDIX A : Creating EUI-64 based Interface Identifiers 828 -------------------------------------------------------- 830 Depending on the characteristics of a specific link or node there are 831 a number of approaches for creating EUI-64 based interface 832 identifiers. This appendix describes some of these approaches. 834 Links or Nodes with EUI-64 Identifiers 836 The only change needed to transform an EUI-64 identifier to an 837 interface identifier is to invert the "u" (universal/local) bit. For 838 example, a globally unique EUI-64 identifier of the form: 840 |0 1|1 3|3 4|4 6| 841 |0 5|6 1|2 7|8 3| 842 +----------------+----------------+----------------+----------------+ 843 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 844 +----------------+----------------+----------------+----------------+ 846 where "c" are the bits of the assigned company_id, "0" is the value 847 of the universal/local bit to indicate global scope, "g" is 848 individual/group bit, and "m" are the bits of the manufacturer- 849 selected extension identifier. The IPv6 interface identifier would 850 be of the form: 852 |0 1|1 3|3 4|4 6| 853 |0 5|6 1|2 7|8 3| 854 +----------------+----------------+----------------+----------------+ 855 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 856 +----------------+----------------+----------------+----------------+ 858 The only change is inverting the value of the universal/local bit. 860 Links or Nodes with IEEE 802 48 bit MAC's 862 [EUI64] defines a method to create a EUI-64 identifier from an IEEE 863 48bit MAC identifier. This is to insert two octets, with hexadecimal 864 values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the 865 company_id and vendor supplied id). For example the 48 bit MAC with 866 global scope: 868 |0 1|1 3|3 4| 869 |0 5|6 1|2 7| 870 +----------------+----------------+----------------+ 871 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 872 +----------------+----------------+----------------+ 874 where "c" are the bits of the assigned company_id, "0" is the value 875 of the universal/local bit to indicate global scope, "g" is 876 individual/group bit, and "m" are the bits of the manufacturer- 877 selected extension identifier. The interface identifier would be of 878 the form: 880 |0 1|1 3|3 4|4 6| 881 |0 5|6 1|2 7|8 3| 882 +----------------+----------------+----------------+----------------+ 883 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 884 +----------------+----------------+----------------+----------------+ 886 When IEEE 802 48bit MAC addresses are available (on an interface or a 887 node), an implementation should use them to create interface 888 identifiers due to their availability and uniqueness properties. 890 Links with Non-Global Identifiers 892 There are a number of types of links that, while multi-access, do not 893 have globally unique link identifiers. Examples include LocalTalk 894 and Arcnet. The method to create an EUI-64 formatted identifier is 895 to take the link identifier (e.g., the LocalTalk 8 bit node 896 identifier) and zero fill it to the left. For example a LocalTalk 8 897 bit node identifier of hexadecimal value 0x4F results in the 898 following interface identifier: 900 |0 1|1 3|3 4|4 6| 901 |0 5|6 1|2 7|8 3| 902 +----------------+----------------+----------------+----------------+ 903 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 904 +----------------+----------------+----------------+----------------+ 906 Note that this results in the universal/local bit set to "0" to 907 indicate local scope. 909 Links without Identifiers 911 There are a number of links that do not have any type of built-in 912 identifier. The most common of these are serial links and configured 913 tunnels. Interface identifiers must be chosen that are unique for 914 the link. 916 When no built-in identifier is available on a link the preferred 917 approach is to use a global interface identifier from another 918 interface or one which is assigned to the node itself. To use this 919 approach no other interface connecting the same node to the same link 920 may use the same identifier. 922 If there is no global interface identifier available for use on the 923 link the implementation needs to create a local scope interface 924 identifier. The only requirement is that it be unique on the link. 925 There are many possible approaches to select a link-unique interface 926 identifier. They include: 928 Manual Configuration 929 Generated Random Number 930 Node Serial Number (or other node-specific token) 932 The link-unique interface identifier should be generated in a manner 933 that it does not change after a reboot of a node or if interfaces are 934 added or deleted from the node. 936 The selection of the appropriate algorithm is link and implementation 937 dependent. The details on forming interface identifiers are defined 938 in the appropriate "IPv6 over " specification. It is strongly 939 recommended that a collision detection algorithm be implemented as 940 part of any automatic algorithm. 942 APPENDIX B: ABNF Description of Text Representations 943 ---------------------------------------------------- 945 This appendix defines the text representation of IPv6 addresses and 946 prefixes in Augmented BNF [ABNF] for reference purposes. 948 IPv6address = hexpart [ ":" IPv4address ] 949 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 951 IPv6prefix = hexpart "/" 1*2DIGIT 953 hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] 954 hexseq = hex4 *( ":" hex4) 955 hex4 = 1*4HEXDIG 957 APPENDIX C: CHANGES FROM RFC-1884 958 --------------------------------- 960 The following changes were made from RFC-1884 "IP Version 6 961 Addressing Architecture": 963 - Added an appendix providing a ABNF description of text 964 representations. 965 - Clarification that link unique identifiers not change after 966 reboot or other interface reconfigurations. 967 - Clarification of Address Model based on comments. 968 - Changed aggregation format terminology to be consistent with 969 aggregation draft. 970 - Added text to allow interface identifier to be used on more than 971 one interface on same node. 972 - Added rules for defining new multicast addresses. 973 - Added appendix describing procedures for creating EUI-64 based 974 interface ID's. 975 - Added notation for defining IPv6 prefixes. 976 - Changed solicited node multicast definition to use a longer 977 prefix. 978 - Added site scope all routers multicast address. 979 - Defined Aggregatable Global Unicast Addresses to use "001" Format 980 Prefix. 981 - Changed "010" (Provider-Based Unicast) and "100" (Reserved for 982 Geographic) Format Prefixes to Unassigned. 983 - Added section on Interface ID definition for unicast addresses. 984 Requires use of EUI-64 in range of format prefixes and rules for 985 setting global/local scope bit in EUI-64. 986 - Updated NSAP text to reflect working in RFC1888. 987 - Removed protocol specific IPv6 multicast addresses (e.g., DHCP) 988 and referenced the IANA definitions. 989 - Removed section "Unicast Address Example". Had become OBE. 990 - Added new and updated references. 991 - Minor text clarifications and improvements. 993 REFERENCES 995 [ABNF] Crocker, D., P. Overell, "Augmented BNF for Syntax 996 Specifications: ABNF", Internet Draft, , October 1997. 999 [AGGR] Hinden, R., S. Deering, M. O'Dell, "An Aggregatable Global 1000 Unicast Address Format", internet draft, , May 1997. 1003 [AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August 1004 1995. 1006 [ANYCST] Partridge, C., T. Mendez, and W. Milliken, "Host Anycasting 1007 Service", RFC1546, November 1993. 1009 [CIDR] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless Inter- 1010 Domain Routing (CIDR): An Address Assignment and 1011 Aggregation Strategy", RFC1519, September 1993. 1013 [ETHER] Crawford, M., "Transmission of IPv6 Pacekts over Ethernet 1014 Networks", Internet Draft, , March 1997. 1017 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 1018 Registration Authority", 1019 http://standards.ieee.org/db/oui/tutorials/EUI64.html, 1020 March 1997. 1022 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 1023 Networks", Internet Draft, , March 1997. 1026 [IPV6] Deering, S., R. Hinden, Editors, "Internet Protocol, 1027 Version 6 (IPv6) Specification", RFC1883, December 1995. 1029 [MASGN] Hinden, R., "IPv6 Multicast Address Assignments", Internet 1030 Draft, , May 1031 1997. 1033 [NSAP] Bound, J., B. Carpenter, D. Harrington, J. Houldsworth, A. 1034 Lloyd, "OSI NSAPs and IPv6", RFC1888, August 1996. 1036 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1037 Requirement Levels", RFC2119, BCP14, March 1997. 1039 [TOKEN] Thomas, S., "Transmission of IPv6 Packets over Token Ring 1040 Networks", Internet Draft, June 1997. 1042 [TRAN] Gilligan, R., E. Nordmark, "Transition Mechanisms for IPv6 1043 Hosts and Routers", RFC1993, April 1996. 1045 AUTHOR'S ADDRESSES 1047 Robert M. Hinden Stephen E. Deering 1048 Ipsilon Networks, Inc. Cisco Systems, Inc. 1049 232 Java Drive 170 West Tasman Drive 1050 Sunnyvale, CA 94089 San Jose, CA 95134-1706 1051 USA USA 1053 phone: +1 408 990-2004 phone: +1 408 527-8213 1054 fax: +1 408 743-5677 fax: +1 408 527-8254 1055 email: hinden@ipsilon.com email: deering@cisco.com