idnits 2.17.1 draft-ietf-ipngwg-addr-arch-v3-10.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-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([IPV6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 21 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 214 has weird spacing: '...address is ...' == Line 217 has weird spacing: '...-length is a...' == Line 973 has weird spacing: '...s types are i...' -- 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: 'RFC1888' is mentioned on line 804, but not defined ** Obsolete undefined reference: RFC 1888 (Obsoleted by RFC 4048) == Missing Reference: 'RFC2374' is mentioned on line 808, but not defined ** Obsolete undefined reference: RFC 2374 (Obsoleted by RFC 3587) == Unused Reference: 'MASGN' is defined on line 1056, but no explicit reference was found in the text == Unused Reference: 'TOKEN' is defined on line 1065, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'AUTH') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2374 (ref. 'AGGR') (Obsoleted by RFC 3587) -- Obsolete informational reference (is this intentional?): RFC 1519 (ref. 'CIDR') (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 1888 (ref. 'NSAP') (Obsoleted by RFC 4048) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. 'PRIV') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 2893 (ref. 'TRAN') (Obsoleted by RFC 4213) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Hinden, Nokia 3 September 11, 2002 S. Deering, Cisco Systems 5 IP Version 6 Addressing Architecture 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of [RFC2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the list Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 This Internet Draft expires March 12, 2003. 29 Abstract 31 This specification defines the addressing architecture of the IP 32 Version 6 protocol [IPV6]. The document includes the IPv6 addressing 33 model, text representations of IPv6 addresses, definition of IPv6 34 unicast addresses, anycast addresses, and multicast addresses, and an 35 IPv6 node's required addresses. 37 This document obsoletes RFC-2373 "IP Version 6 Addressing 38 Architecture". 40 Table of Contents 42 1. Introduction.................................................3 44 2. IPv6 Addressing..............................................3 45 2.1 Addressing Model.........................................4 46 2.2 Text Representation of Addresses.........................4 47 2.3 Text Representation of Address Prefixes..................5 48 2.4 Address Type Identification..............................7 49 2.5 Unicast Addresses........................................7 50 2.5.1 Interface Identifiers................................8 51 2.5.2 The Unspecified Address.............................10 52 2.5.3 The Loopback Address................................10 53 2.5.4 Global Unicast Addresses............................10 54 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.........11 55 2.5.6 Local-use IPv6 Unicast Addresses....................11 56 2.6 Anycast Addresses.......................................12 57 2.6.1 Required Anycast Address............................13 58 2.7 Multicast Addresses.....................................14 59 2.7.1 Pre-Defined Multicast Addresses.....................16 60 2.8 A Node's Required Addresses.............................18 62 3. Security Considerations.....................................18 64 4. IANA Considerations.........................................19 66 APPENDIX A: Creating Modified EUI-64 format Interface IDs......20 68 APPENDIX B: Changes from RFC-2373..............................23 70 REFERENCES.....................................................25 72 AUTHOR'S ADDRESSES.............................................26 74 1.0 INTRODUCTION 76 This specification defines the addressing architecture of the IP 77 Version 6 protocol. It includes the basic formats for the various 78 types of IPv6 addresses (unicast, anycast, and multicast). 80 The authors would like to acknowledge the contributions of Paul 81 Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, 82 Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, 83 Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg 84 Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, 85 Sue Thomson, Markku Savela, and Larry Masinter. 87 2.0 IPv6 ADDRESSING 89 IPv6 addresses are 128-bit identifiers for interfaces and sets of 90 interfaces (where "interface" is as defined in section 2 of [IPV6]). 91 There are three types of addresses: 93 Unicast: An identifier for a single interface. A packet sent to a 94 unicast address is delivered to the interface identified 95 by that address. 97 Anycast: An identifier for a set of interfaces (typically 98 belonging to different nodes). A packet sent to an 99 anycast address is delivered to one of the interfaces 100 identified by that address (the "nearest" one, according 101 to the routing protocols' measure of distance). 103 Multicast: An identifier for a set of interfaces (typically 104 belonging to different nodes). A packet sent to a 105 multicast address is delivered to all interfaces 106 identified by that address. 108 There are no broadcast addresses in IPv6, their function being 109 superseded by multicast addresses. 111 In this document, fields in addresses are given a specific name, for 112 example "subnet". When this name is used with the term "ID" for 113 identifier after the name (e.g., "subnet ID"), it refers to the 114 contents of the named field. When it is used with the term "prefix" 115 (e.g., "subnet prefix") it refers to all of the address from the left 116 up to and including this field. 118 In IPv6, all zeros and all ones are legal values for any field, 119 unless specifically excluded. Specifically, prefixes may contain, or 120 end with, zero-valued fields. 122 2.1 Addressing Model 124 IPv6 addresses of all types are assigned to interfaces, not nodes. 125 An IPv6 unicast address refers to a single interface. Since each 126 interface belongs to a single node, any of that node's interfaces' 127 unicast addresses may be used as an identifier for the node. 129 All interfaces are required to have at least one link-local unicast 130 address (see section 2.8 for additional required addresses). A 131 single interface may also have multiple IPv6 addresses of any type 132 (unicast, anycast, and multicast) or scope. Unicast addresses with 133 scope greater than link-scope are not needed for interfaces that are 134 not used as the origin or destination of any IPv6 packets to or from 135 non-neighbors. This is sometimes convenient for point-to-point 136 interfaces. There is one exception to this addressing model: 138 A unicast address or a set of unicast addresses may be assigned to 139 multiple physical interfaces if the implementation treats the 140 multiple physical interfaces as one interface when presenting it 141 to the internet layer. This is useful for load-sharing over 142 multiple physical interfaces. 144 Currently IPv6 continues the IPv4 model that a subnet prefix is 145 associated with one link. Multiple subnet prefixes may be assigned 146 to the same link. 148 2.2 Text Representation of Addresses 150 There are three conventional forms for representing IPv6 addresses as 151 text strings: 153 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the 154 hexadecimal values of the eight 16-bit pieces of the address. 155 Examples: 157 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 159 1080:0:0:0:8:800:200C:417A 161 Note that it is not necessary to write the leading zeros in an 162 individual field, but there must be at least one numeral in every 163 field (except for the case described in 2.). 165 2. Due to some methods of allocating certain styles of IPv6 166 addresses, it will be common for addresses to contain long strings 167 of zero bits. In order to make writing addresses containing zero 168 bits easier a special syntax is available to compress the zeros. 169 The use of "::" indicates one or more groups of 16 bits of zeros. 170 The "::" can only appear once in an address. The "::" can also be 171 used to compress the leading and/or trailing zeros in an address. 173 For example the following addresses: 175 1080:0:0:0:8:800:200C:417A a unicast address 176 FF01:0:0:0:0:0:0:101 a multicast address 177 0:0:0:0:0:0:0:1 the loopback address 178 0:0:0:0:0:0:0:0 the unspecified addresses 180 may be represented as: 182 1080::8:800:200C:417A a unicast address 183 FF01::101 a multicast address 184 ::1 the loopback address 185 :: the unspecified addresses 187 3. An alternative form that is sometimes more convenient when dealing 188 with a mixed environment of IPv4 and IPv6 nodes is 189 x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of 190 the six high-order 16-bit pieces of the address, and the 'd's are 191 the decimal values of the four low-order 8-bit pieces of the 192 address (standard IPv4 representation). Examples: 194 0:0:0:0:0:0:13.1.68.3 196 0:0:0:0:0:FFFF:129.144.52.38 198 or in compressed form: 200 ::13.1.68.3 202 ::FFFF:129.144.52.38 204 2.3 Text Representation of Address Prefixes 206 The text representation of IPv6 address prefixes is similar to the 207 way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An 208 IPv6 address prefix is represented by the notation: 210 ipv6-address/prefix-length 212 where 214 ipv6-address is an IPv6 address in any of the notations listed 215 in section 2.2. 217 prefix-length is a decimal value specifying how many of the 218 leftmost contiguous bits of the address comprise 219 the prefix. 221 For example, the following are legal representations of the 60-bit 222 prefix 12AB00000000CD3 (hexadecimal): 224 12AB:0000:0000:CD30:0000:0000:0000:0000/60 225 12AB::CD30:0:0:0:0/60 226 12AB:0:0:CD30::/60 228 The following are NOT legal representations of the above prefix: 230 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, 231 within any 16-bit chunk of the address 233 12AB::CD30/60 address to left of "/" expands to 234 12AB:0000:0000:0000:0000:000:0000:CD30 236 12AB::CD3/60 address to left of "/" expands to 237 12AB:0000:0000:0000:0000:000:0000:0CD3 239 When writing both a node address and a prefix of that node address 240 (e.g., the node's subnet prefix), the two can combined as follows: 242 the node address 12AB:0:0:CD30:123:4567:89AB:CDEF 243 and its subnet number 12AB:0:0:CD30::/60 245 can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 247 2.4 Address Type Identification 249 The type of an IPv6 address is identified by the high-order bits of 250 the address, as follows: 252 Address type Binary prefix IPv6 notation Section 253 ------------ ------------- ------------- ------- 254 Unspecified 00...0 (128 bits) ::/128 2.5.2 255 Loopback 00...1 (128 bits) ::1/128 2.5.3 256 Multicast 11111111 FF00::/8 2.7 257 Link-local unicast 1111111010 FE80::/10 2.5.6 258 Site-local unicast 1111111011 FEC0::/10 2.5.6 259 Global unicast (everything else) 261 Anycast addresses are taken from the unicast address spaces (of any 262 scope) and are not syntactically distinguishable from unicast 263 addresses. 265 The general format of global unicast addresses is described in 266 section 2.5.4. Some special-purpose subtypes of global unicast 267 addresses which contain embedded IPv4 addresses (for the purposes of 268 IPv4-IPv6 interoperation) are described in section 2.5.5. 270 Future specifications may redefine one or more sub-ranges of the 271 global unicast space for other purposes, but unless and until that 272 happens, implementations must treat all addresses that do not start 273 with any of the above-listed prefixes as global unicast addresses. 275 2.5 Unicast Addresses 277 IPv6 unicast addresses are aggregatable with prefixes of arbitrary 278 bit-length similar to IPv4 addresses under Classless Interdomain 279 Routing. 281 There are several types of unicast addresses in IPv6, in particular 282 global unicast, site-local unicast, and link-local unicast. There 283 are also some special-purpose subtypes of global unicast, such as 284 IPv6 addresses with embedded IPv4 addresses or encoded NSAP 285 addresses. Additional address types or subtypes can be defined in 286 the future. 288 IPv6 nodes may have considerable or little knowledge of the internal 289 structure of the IPv6 address, depending on the role the node plays 290 (for instance, host versus router). At a minimum, a node may 291 consider that unicast addresses (including its own) have no internal 292 structure: 294 | 128 bits | 295 +-----------------------------------------------------------------+ 296 | node address | 297 +-----------------------------------------------------------------+ 299 A slightly sophisticated host (but still rather simple) may 300 additionally be aware of subnet prefix(es) for the link(s) it is 301 attached to, where different addresses may have different values for 302 n: 304 | n bits | 128-n bits | 305 +------------------------------------------------+----------------+ 306 | subnet prefix | interface ID | 307 +------------------------------------------------+----------------+ 309 Though a very simple router may have no knowledge of the internal 310 structure of IPv6 unicast addresses, routers will more generally have 311 knowledge of one or more of the hierarchical boundaries for the 312 operation of routing protocols. The known boundaries will differ 313 from router to router, depending on what positions the router holds 314 in the routing hierarchy. 316 2.5.1 Interface Identifiers 318 Interface identifiers in IPv6 unicast addresses are used to identify 319 interfaces on a link. They are required to be unique within a subnet 320 prefix. It is recommended that the same interface identifier not be 321 assigned to different nodes on a link. They may also be unique over 322 a broader scope. In some cases an interface's identifier will be 323 derived directly from that interface's link-layer address. The same 324 interface identifier may be used on multiple interfaces on a single 325 node, as long as they are attached to different subnets. 327 Note that the uniqueness of interface identifiers is independent of 328 the uniqueness of IPv6 addresses. For example a global unicast 329 address may be created with a non-global scope interface identifier 330 and a site-local address may be created with a global scope interface 331 identifier. 333 For all unicast addresses, except those that start with binary value 334 000, Interface IDs are required to be 64 bits long and to be 335 constructed in Modified EUI-64 format. 337 Modified EUI-64 format based Interface identifiers may have global 338 scope when derived from a global token (e.g., IEEE 802 48-bit MAC or 339 IEEE EUI-64 identifiers [EUI64]) or may have local scope where a 340 global token is not available (e.g., serial links, tunnel end-points, 341 etc.) or where global tokens are undesirable (e.g., temporary tokens 342 for privacy [PRIV]). 344 Modified EUI-64 format interface identifiers are formed by inverting 345 the "u" bit (universal/local bit in IEEE EUI-64 terminology) when 346 forming the interface identifier from IEEE EUI-64 identifiers. In 347 the resulting Modified EUI-64 format the "u" bit is set to one (1) to 348 indicate global scope, and it is set to zero (0) to indicate local 349 scope. The first three octets in binary of an IEEE EUI-64 identifier 350 are as follows: 352 0 0 0 1 1 2 353 |0 7 8 5 6 3| 354 +----+----+----+----+----+----+ 355 |cccc|ccug|cccc|cccc|cccc|cccc| 356 +----+----+----+----+----+----+ 358 written in Internet standard bit-order , where "u" is the 359 universal/local bit, "g" is the individual/group bit, and "c" are the 360 bits of the company_id. Appendix A: "Creating Modified EUI-64 format 361 Interface Identifiers" provides examples on the creation of Modified 362 EUI-64 format based interface identifiers. 364 The motivation for inverting the "u" bit when forming an interface 365 identifier is to make it easy for system administrators to hand 366 configure non-global identifiers when hardware tokens are not 367 available. This is expected to be case for serial links, tunnel end- 368 points, etc. The alternative would have been for these to be of the 369 form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2, 370 etc. 372 The use of the universal/local bit in the Modified EUI-64 format 373 identifier is to allow development of future technology that can take 374 advantage of interface identifiers with global scope. 376 The details of forming interface identifiers are defined in the 377 appropriate "IPv6 over " specification such as "IPv6 over 378 Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. 380 2.5.2 The Unspecified Address 382 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It 383 must never be assigned to any node. It indicates the absence of an 384 address. One example of its use is in the Source Address field of 385 any IPv6 packets sent by an initializing host before it has learned 386 its own address. 388 The unspecified address must not be used as the destination address 389 of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a 390 source address of unspecified must never be forwarded by an IPv6 391 router. 393 2.5.3 The Loopback Address 395 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. 396 It may be used by a node to send an IPv6 packet to itself. It may 397 never be assigned to any physical interface. It is treated as 398 having link-local scope, and may be thought of as the link-local 399 unicast address of a virtual interface (typically called "the 400 loopback interface") to an imaginary link that goes nowhere. 402 The loopback address must not be used as the source address in IPv6 403 packets that are sent outside of a single node. An IPv6 packet with 404 a destination address of loopback must never be sent outside of a 405 single node and must never be forwarded by an IPv6 router. A packet 406 received on an interface with destination address of loopback must be 407 dropped. 409 2.5.4 Global Unicast Addresses 411 The general format for IPv6 global unicast addresses is as follows: 413 | n bits | m bits | 128-n-m bits | 414 +------------------------+-----------+----------------------------+ 415 | global routing prefix | subnet ID | interface ID | 416 +------------------------+-----------+----------------------------+ 418 where the global routing prefix is a (typically hierarchically- 419 structured) value assigned to a site (a cluster of subnets/links), 420 the subnet ID is an identifier of a link within the site, and the 421 interface ID is as defined in section 2.5.1. 423 All global unicast addresses other than those that start with binary 424 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as 425 described in section 2.5.1. Global unicast addresses that start with 426 binary 000 have no such constraint on the size or structure of the 427 interface ID field. 429 Examples of global unicast addresses that start with binary 000 are 430 the IPv6 address with embedded IPv4 addresses described in section 431 2.5.5 and the IPv6 address containing encoded NSAP addresses 432 specified in [NSAP]. An example of global addresses starting with a 433 binary value other than 000 (and therefore having a 64-bit interface 434 ID field) can be found in [AGGR]. 436 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses 438 The IPv6 transition mechanisms [TRAN] include a technique for hosts 439 and routers to dynamically tunnel IPv6 packets over IPv4 routing 440 infrastructure. IPv6 nodes that use this technique are assigned 441 special IPv6 unicast addresses that carry a global IPv4 address in 442 the low-order 32 bits. This type of address is termed an 443 "IPv4-compatible IPv6 address" and has the format: 445 | 80 bits | 16 | 32 bits | 446 +--------------------------------------+--------------------------+ 447 |0000..............................0000|0000| IPv4 address | 448 +--------------------------------------+----+---------------------+ 450 Note: The IPv4 address used in the "IPv4-compatible IPv6 address" 451 must be a globally-unique IPv4 unicast address. 453 A second type of IPv6 address which holds an embedded IPv4 address is 454 also defined. This address type is used to represent the addresses 455 of IPv4 nodes as IPv6 addresses. This type of address is termed an 456 "IPv4-mapped IPv6 address" and has the format: 458 | 80 bits | 16 | 32 bits | 459 +--------------------------------------+--------------------------+ 460 |0000..............................0000|FFFF| IPv4 address | 461 +--------------------------------------+----+---------------------+ 463 2.5.6 Local-Use IPv6 Unicast Addresses 465 There are two types of local-use unicast addresses defined. These 466 are Link-Local and Site-Local. The Link-Local is for use on a single 467 link and the Site-Local is for use in a single site. Link-Local 468 addresses have the following format: 470 | 10 | 471 | bits | 54 bits | 64 bits | 472 +----------+-------------------------+----------------------------+ 473 |1111111010| 0 | interface ID | 474 +----------+-------------------------+----------------------------+ 476 Link-Local addresses are designed to be used for addressing on a 477 single link for purposes such as automatic address configuration, 478 neighbor discovery, or when no routers are present. 480 Routers must not forward any packets with link-local source or 481 destination addresses to other links. 483 Site-Local addresses have the following format: 485 | 10 | 486 | bits | 54 bits | 64 bits | 487 +----------+-------------------------+----------------------------+ 488 |1111111011| subnet ID | interface ID | 489 +----------+-------------------------+----------------------------+ 491 Site-local addresses are designed to be used for addressing inside of 492 a site without the need for a global prefix. Although a subnet ID 493 may be up to 54-bits long, it is expected that globally-connected 494 sites will use the same subnet IDs for site-local and global 495 prefixes. 497 Routers must not forward any packets with site-local source or 498 destination addresses outside of the site. 500 2.6 Anycast Addresses 502 An IPv6 anycast address is an address that is assigned to more than 503 one interface (typically belonging to different nodes), with the 504 property that a packet sent to an anycast address is routed to the 505 "nearest" interface having that address, according to the routing 506 protocols' measure of distance. 508 Anycast addresses are allocated from the unicast address space, using 509 any of the defined unicast address formats. Thus, anycast addresses 510 are syntactically indistinguishable from unicast addresses. When a 511 unicast address is assigned to more than one interface, thus turning 512 it into an anycast address, the nodes to which the address is 513 assigned must be explicitly configured to know that it is an anycast 514 address. 516 For any assigned anycast address, there is a longest prefix P of that 517 address that identifies the topological region in which all 518 interfaces belonging to that anycast address reside. Within the 519 region identified by P, the anycast address must be maintained as a 520 separate entry in the routing system (commonly referred to as a "host 521 route"); outside the region identified by P, the anycast address may 522 be aggregated into the routing entry for prefix P. 524 Note that in the worst case, the prefix P of an anycast set may be 525 the null prefix, i.e., the members of the set may have no topological 526 locality. In that case, the anycast address must be maintained as a 527 separate routing entry throughout the entire internet, which presents 528 a severe scaling limit on how many such "global" anycast sets may be 529 supported. Therefore, it is expected that support for global anycast 530 sets may be unavailable or very restricted. 532 One expected use of anycast addresses is to identify the set of 533 routers belonging to an organization providing internet service. 534 Such addresses could be used as intermediate addresses in an IPv6 535 Routing header, to cause a packet to be delivered via a particular 536 service provider or sequence of service providers. 538 Some other possible uses are to identify the set of routers attached 539 to a particular subnet, or the set of routers providing entry into a 540 particular routing domain. 542 There is little experience with widespread, arbitrary use of internet 543 anycast addresses, and some known complications and hazards when 544 using them in their full generality [ANYCST]. Until more experience 545 has been gained and solutions are specified, the following 546 restrictions are imposed on IPv6 anycast addresses: 548 o An anycast address must not be used as the source address of an 549 IPv6 packet. 551 o An anycast address must not be assigned to an IPv6 host, that 552 is, it may be assigned to an IPv6 router only. 554 2.6.1 Required Anycast Address 556 The Subnet-Router anycast address is predefined. Its format is as 557 follows: 559 | n bits | 128-n bits | 560 +------------------------------------------------+----------------+ 561 | subnet prefix | 00000000000000 | 562 +------------------------------------------------+----------------+ 564 The "subnet prefix" in an anycast address is the prefix which 565 identifies a specific link. This anycast address is syntactically 566 the same as a unicast address for an interface on the link with the 567 interface identifier set to zero. 569 Packets sent to the Subnet-Router anycast address will be delivered 570 to one router on the subnet. All routers are required to support the 571 Subnet-Router anycast addresses for the subnets to which they have 572 interfaces. 574 The subnet-router anycast address is intended to be used for 575 applications where a node needs to communicate with any one of the 576 set of routers. 578 2.7 Multicast Addresses 580 An IPv6 multicast address is an identifier for a group of interfaces 581 (typically on different nodes). An interface may belong to any 582 number of multicast groups. Multicast addresses have the following 583 format: 585 | 8 | 4 | 4 | 112 bits | 586 +------ -+----+----+---------------------------------------------+ 587 |11111111|flgs|scop| group ID | 588 +--------+----+----+---------------------------------------------+ 590 binary 11111111 at the start of the address identifies the 591 address as being a multicast address. 593 +-+-+-+-+ 594 flgs is a set of 4 flags: |0|0|0|T| 595 +-+-+-+-+ 597 The high-order 3 flags are reserved, and must be 598 initialized to 0. 600 T = 0 indicates a permanently-assigned ("well-known") 601 multicast address, assigned by the Internet Assigned Number 602 Authority (IANA). 604 T = 1 indicates a non-permanently-assigned ("transient") 605 multicast address. 607 scop is a 4-bit multicast scope value used to limit the scope of 608 the multicast group. The values are: 610 0 reserved 611 1 interface-local scope 612 2 link-local scope 613 3 subnet-local scope 614 4 admin-local scope 615 5 site-local scope 616 6 (unassigned) 617 7 (unassigned) 618 8 organization-local scope 619 9 (unassigned) 620 A (unassigned) 621 B (unassigned) 622 C (unassigned) 623 D (unassigned) 624 E global scope 625 F reserved 627 interface-local scope spans only a single interface on a 628 node, and is useful only for loopback transmission of 629 multicast. 631 link-local and site-local multicast scopes span the same 632 topological regions as the corresponding unicast scopes. 634 subnet-local scope is given a different and larger value 635 than link-local to enable possible support for subnets 636 that span multiple links. 638 admin-local scope is the smallest scope that must be 639 administratively configured, i.e., not automatically 640 derived from physical connectivity or other, non- 641 multicast-related configuration. 643 organization-local scope is intended to span multiple 644 sites belonging to a single organization. 646 scopes labeled "(unassigned)" are available for 647 administrators to define additional multicast regions. 649 group ID identifies the multicast group, either permanent or 650 transient, within the given scope. 652 The "meaning" of a permanently-assigned multicast address is 653 independent of the scope value. For example, if the "NTP servers 654 group" is assigned a permanent multicast address with a group ID of 655 101 (hex), then: 657 FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface 658 (i.e., the same node) as the sender. 660 FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as 661 the sender. 663 FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as 664 the sender. 666 FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet. 668 Non-permanently-assigned multicast addresses are meaningful only 669 within a given scope. For example, a group identified by the non- 670 permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one 671 site bears no relationship to a group using the same address at a 672 different site, nor to a non-permanent group using the same group ID 673 with different scope, nor to a permanent group with the same group 674 ID. 676 Multicast addresses must not be used as source addresses in IPv6 677 packets or appear in any Routing header. 679 Routers must not forward any multicast packets beyond of the scope 680 indicated by the scop field in the destination multicast address. 682 Nodes must not originate a packet to a multicast address whose scop 683 field contains the reserved value 0; if such a packet is received, it 684 must be silently dropped. Nodes should not originate a packet to a 685 multicast address whose scop field contains the reserved value F; if 686 such a packet is sent or received, it must be treated the same as 687 packets destined to a global (scop E) multicast address. 689 2.7.1 Pre-Defined Multicast Addresses 691 The following well-known multicast addresses are pre-defined. The 692 group ID's defined in this section are defined for explicit scope 693 values. 695 Use of these group IDs for any other scope values, with the T flag 696 equal to 0, is not allowed. 698 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 699 FF01:0:0:0:0:0:0:0 700 FF02:0:0:0:0:0:0:0 701 FF03:0:0:0:0:0:0:0 702 FF04:0:0:0:0:0:0:0 703 FF05:0:0:0:0:0:0:0 704 FF06:0:0:0:0:0:0:0 705 FF07:0:0:0:0:0:0:0 706 FF08:0:0:0:0:0:0:0 707 FF09:0:0:0:0:0:0:0 708 FF0A:0:0:0:0:0:0:0 709 FF0B:0:0:0:0:0:0:0 710 FF0C:0:0:0:0:0:0:0 711 FF0D:0:0:0:0:0:0:0 712 FF0E:0:0:0:0:0:0:0 713 FF0F:0:0:0:0:0:0:0 715 The above multicast addresses are reserved and shall never be 716 assigned to any multicast group. 718 All Nodes Addresses: FF01:0:0:0:0:0:0:1 719 FF02:0:0:0:0:0:0:1 721 The above multicast addresses identify the group of all IPv6 nodes, 722 within scope 1 (interface-local) or 2 (link-local). 724 All Routers Addresses: FF01:0:0:0:0:0:0:2 725 FF02:0:0:0:0:0:0:2 726 FF05:0:0:0:0:0:0:2 728 The above multicast addresses identify the group of all IPv6 routers, 729 within scope 1 (interface-local), 2 (link-local), or 5 (site-local). 731 Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX 733 Solicited-node multicast address are computed as a function of a 734 node's unicast and anycast addresses. A solicited-node multicast 735 address is formed by taking the low-order 24 bits of an address 736 (unicast or anycast) and appending those bits to the prefix 737 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 738 range 740 FF02:0:0:0:0:1:FF00:0000 742 to 744 FF02:0:0:0:0:1:FFFF:FFFF 746 For example, the solicited node multicast address corresponding to 747 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 748 addresses that differ only in the high-order bits, e.g. due to 749 multiple high-order prefixes associated with different aggregations, 750 will map to the same solicited-node address thereby, reducing the 751 number of multicast addresses a node must join. 753 A node is required to compute and join (on the appropriate interface) 754 the associated Solicited-Node multicast addresses for every unicast 755 and anycast address it is assigned. 757 2.8 A Node's Required Addresses 759 A host is required to recognize the following addresses as 760 identifying itself: 762 o Its required Link-Local Address for each interface. 763 o Any additional Unicast and Anycast Addresses that have been 764 configured for the node's interfaces (manually or 765 automatically). 766 o The loopback address. 767 o The All-Nodes Multicast Addresses defined in section 2.7.1. 768 o The Solicited-Node Multicast Address for each of its unicast and 769 anycast addresses. 770 o Multicast Addresses of all other groups to which the node 771 belongs. 773 A router is required to recognize all addresses that a host is 774 required to recognize, plus the following addresses as identifying 775 itself: 777 o The Subnet-Router Anycast Addresses for all interfaces for which 778 it is configured to act as a router. 779 o All other Anycast Addresses with which the router has been 780 configured. 781 o The All-Routers Multicast Addresses defined in section 2.7.1. 783 3. Security Considerations 785 IPv6 addressing documents do not have any direct impact on Internet 786 infrastructure security. Authentication of IPv6 packets is defined 787 in [AUTH]. 789 4. IANA Considerations 791 The table and notes at http://www.isi.edu/in- 792 notes/iana/assignments/ipv6-address-space.txt should be replaced with 793 the following: 795 INTERNET PROTOCOL VERSION 6 ADDRESS SPACE 797 The initial assignment of IPv6 address space is as follows: 799 Allocation Prefix Fraction of 800 (binary) Address Space 801 ----------------------------------- -------- ------------- 802 Unassigned (see Note 1 below) 0000 0000 1/256 803 Unassigned 0000 0001 1/256 804 Reserved for NSAP Allocation 0000 001 1/128 [RFC1888] 805 Unassigned 0000 01 1/64 806 Unassigned 0000 1 1/32 807 Unassigned 0001 1/16 808 Global Unicast 001 1/8 [RFC2374] 809 Unassigned 010 1/8 810 Unassigned 011 1/8 811 Unassigned 100 1/8 812 Unassigned 101 1/8 813 Unassigned 110 1/8 814 Unassigned 1110 1/16 815 Unassigned 1111 0 1/32 816 Unassigned 1111 10 1/64 817 Unassigned 1111 110 1/128 818 Unassigned 1111 1110 0 1/512 819 Link-Local Unicast Addresses 1111 1110 10 1/1024 820 Site-Local Unicast Addresses 1111 1110 11 1/1024 821 Multicast Addresses 1111 1111 1/256 823 Notes: 825 1) The "unspecified address", the "loopback address", and the IPv6 826 Addresses with Embedded IPv4 Addresses are assigned out of the 827 0000 0000 binary prefix space. 829 2) For now, IANA should limit its allocation of IPv6 unicast 830 address space to the range of addresses that start with binary 831 value 001. The rest of the global unicast address space 832 (approximately 85% of the IPv6 address space) is reserved for 833 future definition and use, and is not to be assigned by IANA at 834 this time. 836 APPENDIX A: Creating Modified EUI-64 format Interface Identifiers 837 ------------------------------------------------------------------ 839 Depending on the characteristics of a specific link or node there 840 are a number of approaches for creating Modified EUI-64 format 841 interface identifiers. This appendix describes some of these 842 approaches. 844 Links or Nodes with IEEE EUI-64 Identifiers 846 The only change needed to transform an IEEE EUI-64 identifier to 847 an interface identifier is to invert the "u" (universal/local) 848 bit. For example, a globally unique IEEE EUI-64 identifier of the 849 form: 851 |0 1|1 3|3 4|4 6| 852 |0 5|6 1|2 7|8 3| 853 +----------------+----------------+----------------+----------------+ 854 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 855 +----------------+----------------+----------------+----------------+ 857 where "c" are the bits of the assigned company_id, "0" is the 858 value of the universal/local bit to indicate global scope, "g" is 859 individual/group bit, and "m" are the bits of the manufacturer- 860 selected extension identifier. The IPv6 interface identifier 861 would be of the form: 863 |0 1|1 3|3 4|4 6| 864 |0 5|6 1|2 7|8 3| 865 +----------------+----------------+----------------+----------------+ 866 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 867 +----------------+----------------+----------------+----------------+ 869 The only change is inverting the value of the universal/local bit. 871 Links or Nodes with IEEE 802 48 bit MAC's 873 [EUI64] defines a method to create a IEEE EUI-64 identifier from 874 an IEEE 48bit MAC identifier. This is to insert two octets, with 875 hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit 876 MAC (between the company_id and vendor supplied id). For example 877 the 48 bit IEEE MAC with global scope: 879 |0 1|1 3|3 4| 880 |0 5|6 1|2 7| 881 +----------------+----------------+----------------+ 882 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 883 +----------------+----------------+----------------+ 885 where "c" are the bits of the assigned company_id, "0" is the 886 value of the universal/local bit to indicate global scope, "g" is 887 individual/group bit, and "m" are the bits of the manufacturer- 888 selected extension identifier. The interface identifier would be 889 of the form: 891 |0 1|1 3|3 4|4 6| 892 |0 5|6 1|2 7|8 3| 893 +----------------+----------------+----------------+----------------+ 894 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 895 +----------------+----------------+----------------+----------------+ 897 When IEEE 802 48bit MAC addresses are available (on an interface 898 or a node), an implementation may use them to create interface 899 identifiers due to their availability and uniqueness properties. 901 Links with Other Kinds of Identifiers 903 There are a number of types of links that have link-layer 904 interface identifiers other than IEEE EIU-64 or IEEE 802 48-bit 905 MACs. Examples include LocalTalk and Arcnet. The method to 906 create an Modified EUI-64 format identifier is to take the link 907 identifier (e.g., the LocalTalk 8 bit node identifier) and zero 908 fill it to the left. For example a LocalTalk 8 bit node 909 identifier of hexadecimal value 0x4F results in the following 910 interface identifier: 912 |0 1|1 3|3 4|4 6| 913 |0 5|6 1|2 7|8 3| 914 +----------------+----------------+----------------+----------------+ 915 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 916 +----------------+----------------+----------------+----------------+ 918 Note that this results in the universal/local bit set to "0" to 919 indicate local scope. 921 Links without Identifiers 923 There are a number of links that do not have any type of built-in 924 identifier. The most common of these are serial links and 925 configured tunnels. Interface identifiers must be chosen that are 926 unique within a subnet-prefix. 928 When no built-in identifier is available on a link the preferred 929 approach is to use a global interface identifier from another 930 interface or one which is assigned to the node itself. When using 931 this approach no other interface connecting the same node to the 932 same subnet-prefix may use the same identifier. 934 If there is no global interface identifier available for use on 935 the link the implementation needs to create a local-scope 936 interface identifier. The only requirement is that it be unique 937 within a subnet prefix. There are many possible approaches to 938 select a subnet-prefix-unique interface identifier. These 939 include: 941 Manual Configuration 942 Node Serial Number 943 Other node-specific token 945 The subnet-prefix-unique interface identifier should be generated 946 in a manner that it does not change after a reboot of a node or if 947 interfaces are added or deleted from the node. 949 The selection of the appropriate algorithm is link and 950 implementation dependent. The details on forming interface 951 identifiers are defined in the appropriate "IPv6 over " 952 specification. It is strongly recommended that a collision 953 detection algorithm be implemented as part of any automatic 954 algorithm. 956 APPENDIX B: Changes from RFC-2373 957 --------------------------------- 959 The following changes were made from RFC-2373 "IP Version 6 960 Addressing Architecture": 962 - Clarified text in section 2.2 to allow "::" to represent one or 963 more groups of 16 bits of zeros. 964 - Changed uniqueness requirement of Interface Identifiers from 965 unique on a link to unique within a subnet prefix. Also added 966 a recommendation that the same interface identifier not be 967 assigned to different machines on a link. 968 - Change site-local format to make the subnet ID field 54-bit 969 long and remove the 38-bit zero's field. 970 - Added description of multicast scop values and rules to handle 971 the reserved scop value 0. 972 - Revised sections 2.4 and 2.5.6 to simplify and clarify how 973 different address types are identified. This was done to 974 insure that implementations do not build in any knowledge about 975 global unicast format prefixes. Changes include: 976 o Removed Format Prefix (FP) terminology 977 o Revised list of address types to only include exceptions to 978 global unicast and a singe entry that identifies everything 979 else as Global Unicast. 980 o Removed list of defined prefix exceptions from section 981 2.5.6 as it is now the main part of section 2.4. 982 - Clarified text relating to EUI-64 identifiers to distinguish 983 between IPv6's "Modified EUI-64 format" identifiers and IEEE 984 EUI-64 identifiers. 985 - Combined the sections on the Global Unicast Addresses and NSAP 986 Addresses into a single section on Global Unicast Addresses, 987 generalized the Global Unicast format, and cited [AGGR] and 988 [NSAP] as examples. 989 - Reordered sections 2.5.4 and 2.5.5. 990 - Removed section 2.7.2 Assignment of New IPv6 Multicast 991 Addresses because this is being redefined elsewhere. 992 - Added an IANA considerations section that updates the IANA IPv6 993 address allocations and documents the NSAP and AGGR 994 allocations. 995 - Added clarification that the "IPv4-compatible IPv6 address" 996 must use global IPv4 unicast addresses. 997 - Divided references in to normative and non-normative sections. 998 - Added reference to [PRIV] in section 2.5.1 999 - Added clarification that routers must not forward multicast 1000 packets outside of the scope indicated in the multicast 1001 address. 1002 - Added clarification that routers must not forward packets with 1003 source address of the unspecified address. 1005 - Added clarification that routers must drop packets received on 1006 an interface with destination address of loopback. 1007 - Clarified the definition of IPv4-mapped addresses. 1008 - Removed the ABNF Description of Text Representations Appendix. 1009 - Removed the address block reserved for IPX addresses. 1010 - Multicast scope changes: 1011 o Changed name of scope value 1 from "node-local" to 1012 "interface-local" 1013 o Defined scope value 3 for "subnet-local" for multi-link 1014 subnets 1015 o Defined scope value 4 as "admin-local" 1016 - Corrected reference to RFC1933 and updated references. 1017 - Many small changes to clarify and make the text more 1018 consistent. 1020 REFERENCES 1022 Normative References 1024 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 1025 (IPv6) Specification", RFC2460, December 1998. 1027 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1028 3", RFC2026, BCP00009, October 1996. 1030 Non-Normative References 1032 [ANYCST] Partridge, C., T. Mendez, and W. Milliken, "Host Anycasting 1033 Service", RFC1546, November 1993. 1035 [AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402, 1036 November 1998. 1038 [AGGR] Hinden, R., S. Deering, M. O'Dell, "An Aggregatable Global 1039 Unicast Address Format", RFC2374, July 1998. 1041 [CIDR] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless Inter- 1042 Domain Routing (CIDR): An Address Assignment and 1043 Aggregation Strategy", RFC1519, September 1993. 1045 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1046 Networks", RFC2464, December 1998. 1048 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 1049 Registration Authority", 1050 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 1051 , March 1997. 1053 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 1054 Networks", RFC2467, December 1998. 1056 [MASGN] Hinden, R., "IPv6 Multicast Address Assignments", RFC2375, 1057 July 1998. 1059 [NSAP] Bound, J., B. Carpenter, D. Harrington, J. Houldsworth, A. 1060 Lloyd, "OSI NSAPs and IPv6", RFC1888, August 1996. 1062 [PRIV] Narten, T., R. Draves, "Privacy Extensions for Stateless 1063 Address Autoconfiguration in IPv6", RFC3041, January 2001. 1065 [TOKEN] Crawford, M., T. Narten, S. Thomas, "Transmission of IPv6 1066 Packets over Token Ring Networks", RFC2470, December 1998. 1068 [TRAN] Gilligan, R., E. Nordmark, "Transition Mechanisms for IPv6 1069 Hosts and Routers", RFC2893, August 2000. 1071 AUTHOR'S ADDRESSES 1073 Robert M. Hinden 1074 Nokia 1075 313 Fairchild Drive 1076 Mountain View, CA 94043 1077 USA 1079 phone: +1 650 625-2004 1080 email: hinden@iprg.nokia.com 1082 Stephen E. Deering 1083 Cisco Systems, Inc. 1084 170 West Tasman Drive 1085 San Jose, CA 95134-1706 1086 USA 1088 phone: +1 408 527-8213 1089 email: deering@cisco.com