idnits 2.17.00 (12 Aug 2021) /tmp/idnits57494/draft-ietf-ipngwg-addr-arch-v3-07.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 (2022-05-21) 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) 2022 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 211 has weird spacing: '...address is ...' == Line 214 has weird spacing: '...-length is a...' == Line 950 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 790, but not defined ** Obsolete undefined reference: RFC 1888 (Obsoleted by RFC 4048) == Missing Reference: 'RFC2374' is mentioned on line 794, but not defined ** Obsolete undefined reference: RFC 2374 (Obsoleted by RFC 3587) == Unused Reference: 'MASGN' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: 'TOKEN' is defined on line 1041, 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 November 20, 2001 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 May 20, 2002. 29 Abstract 31 This specification defines the addressing architecture of the IP 32 Version 6 protocol [IPV6]. The document includes the IPv6 addressing 33 model, text representations of IPv6 addresses, definition of IPv6 34 unicast addresses, anycast addresses, and multicast addresses, and an 35 IPv6 node's required addresses. 37 Table of Contents 39 1. Introduction.................................................3 41 2. IPv6 Addressing..............................................3 42 2.1 Addressing Model.........................................4 43 2.2 Text Representation of Addresses.........................4 44 2.3 Text Representation of Address Prefixes..................5 45 2.4 Address Type Representation..............................7 46 2.5 Unicast Addresses........................................7 47 2.5.1 Interface Identifiers................................8 48 2.5.2 The Unspecified Address..............................9 49 2.5.3 The Loopback Address................................10 50 2.5.4 Global Unicast Addresses............................10 51 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.........11 52 2.5.6 Local-use IPv6 Unicast Addresses....................11 53 2.6 Anycast Addresses.......................................12 54 2.6.1 Required Anycast Address............................13 55 2.7 Multicast Addresses.....................................14 56 2.7.1 Pre-Defined Multicast Addresses.....................16 57 2.8 A Node's Required Addresses.............................18 59 3. Security Considerations.....................................18 61 4. IANA Considerations.........................................19 63 APPENDIX A: Creating Modified EUI-64 format Interface IDs......21 65 APPENDIX B: Changes from RFC-2373..............................24 67 REFERENCES.....................................................26 69 AUTHOR'S ADDRESSES.............................................27 71 1.0 INTRODUCTION 73 This specification defines the addressing architecture of the IP 74 Version 6 protocol. It includes the basic formats for the various 75 types of IPv6 addresses (unicast, anycast, and multicast). 77 The authors would like to acknowledge the contributions of Paul 78 Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, 79 Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, 80 Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg 81 Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, 82 Sue Thomson, Roger Fajman, Markku Savela, and Larry Masinter. 84 2.0 IPv6 ADDRESSING 86 IPv6 addresses are 128-bit identifiers for interfaces and sets of 87 interfaces (where "interface" is as defined in section 2 of [IPV6]). 88 There are three types of addresses: 90 Unicast: An identifier for a single interface. A packet sent to a 91 unicast address is delivered to the interface identified 92 by that address. 94 Anycast: An identifier for a set of interfaces (typically 95 belonging to different nodes). A packet sent to an 96 anycast address is delivered to one of the interfaces 97 identified by that address (the "nearest" one, according 98 to the routing protocols' measure of distance). 100 Multicast: An identifier for a set of interfaces (typically 101 belonging to different nodes). A packet sent to a 102 multicast address is delivered to all interfaces 103 identified by that address. 105 There are no broadcast addresses in IPv6, their function being 106 superseded by multicast addresses. 108 In this document, fields in addresses are given a specific name, for 109 example "subnet". When this name is used with the term "ID" for 110 identifier after the name (e.g., "subnet ID"), it refers to the 111 contents of the named field. When it is used with the term "prefix" 112 (e.g., "subnet prefix") it refers to all of the address from the left 113 up to and including this field. 115 In IPv6, all zeros and all ones are legal values for any field, 116 unless specifically excluded. Specifically, prefixes may contain, or 117 end with, zero-valued fields. 119 2.1 Addressing Model 121 IPv6 addresses of all types are assigned to interfaces, not nodes. 122 An IPv6 unicast address refers to a single interface. Since each 123 interface belongs to a single node, any of that node's interfaces' 124 unicast addresses may be used as an identifier for the node. 126 All interfaces are required to have at least one link-local unicast 127 address (see section 2.8 for additional required addresses). A 128 single interface may also have multiple IPv6 addresses of any type 129 (unicast, anycast, and multicast) or scope. Unicast addresses with 130 scope greater than link-scope are not needed for interfaces that are 131 not used as the origin or destination of any IPv6 packets to or from 132 non-neighbors. This is sometimes convenient for point-to-point 133 interfaces. There is one exception to this addressing model: 135 A unicast address or a set of unicast addresses may be assigned to 136 multiple physical interfaces if the implementation treats the 137 multiple physical interfaces as one interface when presenting it 138 to the internet layer. This is useful for load-sharing over 139 multiple physical interfaces. 141 Currently IPv6 continues the IPv4 model that a subnet prefix is 142 associated with one link. Multiple subnet prefixes may be assigned 143 to the same link. 145 2.2 Text Representation of Addresses 147 There are three conventional forms for representing IPv6 addresses as 148 text strings: 150 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the 151 hexadecimal values of the eight 16-bit pieces of the address. 152 Examples: 154 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 156 1080:0:0:0:8:800:200C:417A 158 Note that it is not necessary to write the leading zeros in an 159 individual field, but there must be at least one numeral in every 160 field (except for the case described in 2.). 162 2. Due to some methods of allocating certain styles of IPv6 163 addresses, it will be common for addresses to contain long strings 164 of zero bits. In order to make writing addresses containing zero 165 bits easier a special syntax is available to compress the zeros. 166 The use of "::" indicates multiple groups of 16 bits of zeros. 167 The "::" can only appear once in an address. The "::" can also be 168 used to compress the leading and/or trailing zeros in an address. 170 For example the following addresses: 172 1080:0:0:0:8:800:200C:417A a unicast address 173 FF01:0:0:0:0:0:0:101 a multicast address 174 0:0:0:0:0:0:0:1 the loopback address 175 0:0:0:0:0:0:0:0 the unspecified addresses 177 may be represented as: 179 1080::8:800:200C:417A a unicast address 180 FF01::101 a multicast address 181 ::1 the loopback address 182 :: the unspecified addresses 184 3. An alternative form that is sometimes more convenient when dealing 185 with a mixed environment of IPv4 and IPv6 nodes is 186 x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of 187 the six high-order 16-bit pieces of the address, and the 'd's are 188 the decimal values of the four low-order 8-bit pieces of the 189 address (standard IPv4 representation). Examples: 191 0:0:0:0:0:0:13.1.68.3 193 0:0:0:0:0:FFFF:129.144.52.38 195 or in compressed form: 197 ::13.1.68.3 199 ::FFFF:129.144.52.38 201 2.3 Text Representation of Address Prefixes 203 The text representation of IPv6 address prefixes is similar to the 204 way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An 205 IPv6 address prefix is represented by the notation: 207 ipv6-address/prefix-length 209 where 211 ipv6-address is an IPv6 address in any of the notations listed 212 in section 2.2. 214 prefix-length is a decimal value specifying how many of the 215 leftmost contiguous bits of the address comprise 216 the prefix. 218 For example, the following are legal representations of the 60-bit 219 prefix 12AB00000000CD3 (hexadecimal): 221 12AB:0000:0000:CD30:0000:0000:0000:0000/60 222 12AB::CD30:0:0:0:0/60 223 12AB:0:0:CD30::/60 225 The following are NOT legal representations of the above prefix: 227 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, 228 within any 16-bit chunk of the address 230 12AB::CD30/60 address to left of "/" expands to 231 12AB:0000:0000:0000:0000:000:0000:CD30 233 12AB::CD3/60 address to left of "/" expands to 234 12AB:0000:0000:0000:0000:000:0000:0CD3 236 When writing both a node address and a prefix of that node address 237 (e.g., the node's subnet prefix), the two can combined as follows: 239 the node address 12AB:0:0:CD30:123:4567:89AB:CDEF 240 and its subnet number 12AB:0:0:CD30::/60 242 can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 244 2.4 Address Type Representation 246 The type of an IPv6 address is identified by the high-order bits of 247 the address, as follows: 249 Address type Binary prefix IPv6 notation Section 250 ------------ ------------- ------------- ------- 251 Unspecified 00...0 (128 bits) ::/128 2.5.2 252 Loopback 00...1 (128 bits) ::1/128 2.5.3 253 Multicast 11111111 FF00::/8 2.7 254 Link-local unicast 1111111010 FE80::/10 2.5.6 255 Site-local unicast 1111111011 FEC0::/10 2.5.6 256 Global unicast (everything else) 258 Anycast addresses are taken from the unicast address spaces (of any 259 scope) and are not syntactically distinguishable from unicast 260 addresses. 262 The general format of global unicast addresses is described in 263 section 2.5.4. Some special-purpose subtypes of global unicast 264 addresses which contain embedded IPv4 addresses (for the purposes of 265 IPv4-IPv6 interoperation) are described in section 2.5.5. 267 Future specifications may redefine one or more sub-ranges of the 268 global unicast space for other purposes, but unless and until that 269 happens, implementations must treat all addresses that do not start 270 with any of the above-listed prefixes as global unicast addresses. 272 2.5 Unicast Addresses 274 IPv6 unicast addresses are aggregatable with prefixes of arbitrary 275 bit-length similar to IPv4 addresses under Classless Interdomain 276 Routing. 278 There are several types of unicast addresses in IPv6, in particular 279 global unicast, site-local unicast, and link-local unicast. There 280 are also some special-purpose subtypes of global unicast, such as 281 IPv6 addresses with embedded IPv4 addresses or encoded NSAP 282 addresses. Additional address types or subtypes can be defined in 283 the future. 285 IPv6 nodes may have considerable or little knowledge of the internal 286 structure of the IPv6 address, depending on the role the node plays 287 (for instance, host versus router). At a minimum, a node may 288 consider that unicast addresses (including its own) have no internal 289 structure: 291 | 128 bits | 292 +-----------------------------------------------------------------+ 293 | node address | 294 +-----------------------------------------------------------------+ 296 A slightly sophisticated host (but still rather simple) may 297 additionally be aware of subnet prefix(es) for the link(s) it is 298 attached to, where different addresses may have different values for 299 n: 301 | n bits | 128-n bits | 302 +------------------------------------------------+----------------+ 303 | subnet prefix | interface ID | 304 +------------------------------------------------+----------------+ 306 Though a very simple router may have no knowledge of the internal 307 structure of IPv6 unicast addresses, routers will more generally have 308 knowledge of one or more of the hierarchical boundaries for the 309 operation of routing protocols. The known boundaries will differ 310 from router to router, depending on what positions the router holds 311 in the routing hierarchy. 313 2.5.1 Interface Identifiers 315 Interface identifiers in IPv6 unicast addresses are used to identify 316 interfaces on a link. They are required to be unique on that link. 317 They may also be unique over a broader scope. In some cases an 318 interface's identifier will be derived directly from that interface's 319 link-layer address. The same interface identifier may be used on 320 multiple interfaces on a single node, as long as they are attached to 321 different links. 323 Note that the uniqueness of interface identifiers is independent of 324 the uniqueness of IPv6 addresses. For example a global unicast 325 address may be created with a non-global scope interface identifier 326 and a site-local address may be created with a global scope interface 327 identifier. 329 For all unicast addresses, except those that start with binary value 330 000, Interface IDs are required to be 64 bits long and to be 331 constructed in Modified EUI-64 format. Modified EUI-64 format based 332 Interface identifiers may have global scope when a global token is 333 available (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers) or 334 may have local scope where a global token is not available (e.g., 335 serial links, tunnel end-points, etc.) or where global tokens are 336 undesirable (e.g., temporary tokens for privacy [PRIV]). 338 Modified EUI-64 format interface identifiers are formed by inverting 339 the "u" bit (universal/local bit in IEEE EUI-64 terminology) when 340 forming the interface identifier from IEEE EUI-64 identifiers. In 341 the resulting Modified EUI-64 format the "u" bit is set to one (1) to 342 indicate global scope, and it is set to zero (0) to indicate local 343 scope. The first three octets in binary of an IEEE EUI-64 identifier 344 are as follows: 346 0 0 0 1 1 2 347 |0 7 8 5 6 3| 348 +----+----+----+----+----+----+ 349 |cccc|ccug|cccc|cccc|cccc|cccc| 350 +----+----+----+----+----+----+ 352 written in Internet standard bit-order , where "u" is the 353 universal/local bit, "g" is the individual/group bit, and "c" are the 354 bits of the company_id. Appendix A: "Creating Modified EUI-64 format 355 Interface Identifiers" provides examples on the creation of Modified 356 EUI-64 format based interface identifiers. 358 The motivation for inverting the "u" bit when forming an interface 359 identifier is to make it easy for system administrators to hand 360 configure non-global identifiers when hardware tokens are not 361 available. This is expected to be case for serial links, tunnel end- 362 points, etc. The alternative would have been for these to be of the 363 form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2, 364 etc. 366 The use of the universal/local bit in the Modified EUI-64 format 367 identifier is to allow development of future technology that can take 368 advantage of interface identifiers with global scope. 370 The details of forming interface identifiers are defined in the 371 appropriate "IPv6 over " specification such as "IPv6 over 372 Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. 374 2.5.2 The Unspecified Address 376 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It 377 must never be assigned to any node. It indicates the absence of an 378 address. One example of its use is in the Source Address field of 379 any IPv6 packets sent by an initializing host before it has learned 380 its own address. 382 The unspecified address must not be used as the destination address 383 of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a 384 source address of unspecified must never be forwarded by an IPv6 385 router. 387 2.5.3 The Loopback Address 389 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. 390 It may be used by a node to send an IPv6 packet to itself. It may 391 never be assigned to any physical interface. It may be thought of as 392 a link-local unicast address assigned to a virtual interface 393 (typically called "the loopback interface") that goes nowhere. 395 The loopback address must not be used as the source address in IPv6 396 packets that are sent outside of a single node. An IPv6 packet with 397 a destination address of loopback must never be sent outside of a 398 single node and must never be forwarded by an IPv6 router. A packet 399 received on an interface with destination address of loopback must be 400 dropped. 402 2.5.4 Global Unicast Addresses 404 The general format for IPv6 global unicast addresses is as follows: 406 | n bits | m bits | 128-n-m bits | 407 +------------------------+-----------+----------------------------+ 408 | global routing prefix | subnet ID | interface ID | 409 +------------------------+-----------+----------------------------+ 411 where the global routing prefix is a (typically hierarchically- 412 structured) value assigned to a site (a cluster of subnets/links), 413 the subnet ID is an identifier of a link within the site, and the 414 interface ID is as defined in section 2.5.1. 416 All global unicast addresses other than those that start with binary 417 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as 418 described in section 2.5.1. Global unicast addresses that start with 419 binary 000 have no such constraint on the size or structure of the 420 interface ID field. 422 Examples of global unicast addresses that start with binary 000 are 423 the IPv6 address with embedded IPv4 addresses described in section 424 2.5.5 and the IPv6 address containing encoded NSAP addresses 425 specified in [NSAP]. An example of global addresses starting with a 426 binary value other than 000 (and therefore having a 64-bit interface 427 ID field) can be found in [AGGR]. 429 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses 431 The IPv6 transition mechanisms [TRAN] include a technique for hosts 432 and routers to dynamically tunnel IPv6 packets over IPv4 routing 433 infrastructure. IPv6 nodes that use this technique are assigned 434 special IPv6 unicast addresses that carry a global IPv4 address in 435 the low-order 32 bits. This type of address is termed an 436 "IPv4-compatible IPv6 address" and has the format: 438 | 80 bits | 16 | 32 bits | 439 +--------------------------------------+--------------------------+ 440 |0000..............................0000|0000| IPv4 address | 441 +--------------------------------------+----+---------------------+ 443 Note: The IPv4 address used in the "IPv4-compatible IPv6 address" 444 must be a globally-unique IPv4 unicast address. 446 A second type of IPv6 address which holds an embedded IPv4 address is 447 also defined. This address type is used to represent the addresses 448 of IPv4 nodes as IPv6 addresses. This type of address is termed an 449 "IPv4-mapped IPv6 address" and has the format: 451 | 80 bits | 16 | 32 bits | 452 +--------------------------------------+--------------------------+ 453 |0000..............................0000|FFFF| IPv4 address | 454 +--------------------------------------+----+---------------------+ 456 2.5.6 Local-Use IPv6 Unicast Addresses 458 There are two types of local-use unicast addresses defined. These 459 are Link-Local and Site-Local. The Link-Local is for use on a single 460 link and the Site-Local is for use in a single site. Link-Local 461 addresses have the following format: 463 | 10 | 464 | bits | 54 bits | 64 bits | 465 +----------+-------------------------+----------------------------+ 466 |1111111010| 0 | interface ID | 467 +----------+-------------------------+----------------------------+ 469 Link-Local addresses are designed to be used for addressing on a 470 single link for purposes such as automatic address configuration, 471 neighbor discovery, or when no routers are present. 473 Routers must not forward any packets with link-local source or 474 destination addresses to other links. 476 Site-Local addresses have the following format: 478 | 10 | 479 | bits | 38 bits | 16 bits | 64 bits | 480 +----------+-------------+-----------+----------------------------+ 481 |1111111011| 0 | subnet ID | interface ID | 482 +----------+-------------+-----------+----------------------------+ 484 Site-Local addresses are designed to be used for addressing inside of 485 a site without the need for a global prefix. 487 Routers must not forward any packets with site-local source or 488 destination addresses outside of the site. 490 2.6 Anycast Addresses 492 An IPv6 anycast address is an address that is assigned to more than 493 one interface (typically belonging to different nodes), with the 494 property that a packet sent to an anycast address is routed to the 495 "nearest" interface having that address, according to the routing 496 protocols' measure of distance. 498 Anycast addresses are allocated from the unicast address space, using 499 any of the defined unicast address formats. Thus, anycast addresses 500 are syntactically indistinguishable from unicast addresses. When a 501 unicast address is assigned to more than one interface, thus turning 502 it into an anycast address, the nodes to which the address is 503 assigned must be explicitly configured to know that it is an anycast 504 address. 506 For any assigned anycast address, there is a longest prefix P of that 507 address that identifies the topological region in which all 508 interfaces belonging to that anycast address reside. Within the 509 region identified by P, the anycast address must be maintained as a 510 separate entry in the routing system (commonly referred to as a "host 511 route"); outside the region identified by P, the anycast address may 512 be aggregated into the routing entry for prefix P. 514 Note that in the worst case, the prefix P of an anycast set may be 515 the null prefix, i.e., the members of the set may have no topological 516 locality. In that case, the anycast address must be maintained as a 517 separate routing entry throughout the entire internet, which presents 518 a severe scaling limit on how many such "global" anycast sets may be 519 supported. Therefore, it is expected that support for global anycast 520 sets may be unavailable or very restricted. 522 One expected use of anycast addresses is to identify the set of 523 routers belonging to an organization providing internet service. 524 Such addresses could be used as intermediate addresses in an IPv6 525 Routing header, to cause a packet to be delivered via a particular 526 service provider or sequence of service providers. 528 Some other possible uses are to identify the set of routers attached 529 to a particular subnet, or the set of routers providing entry into a 530 particular routing domain. 532 There is little experience with widespread, arbitrary use of internet 533 anycast addresses, and some known complications and hazards when 534 using them in their full generality [ANYCST]. Until more experience 535 has been gained and solutions are specified, the following 536 restrictions are imposed on IPv6 anycast addresses: 538 o An anycast address must not be used as the source address of an 539 IPv6 packet. 541 o An anycast address must not be assigned to an IPv6 host, that 542 is, it may be assigned to an IPv6 router only. 544 2.6.1 Required Anycast Address 546 The Subnet-Router anycast address is predefined. Its format is as 547 follows: 549 | n bits | 128-n bits | 550 +------------------------------------------------+----------------+ 551 | subnet prefix | 00000000000000 | 552 +------------------------------------------------+----------------+ 553 The "subnet prefix" in an anycast address is the prefix which 554 identifies a specific link. This anycast address is syntactically 555 the same as a unicast address for an interface on the link with the 556 interface identifier set to zero. 558 Packets sent to the Subnet-Router anycast address will be delivered 559 to one router on the subnet. All routers are required to support the 560 Subnet-Router anycast addresses for the subnets to which they have 561 interfaces. 563 The subnet-router anycast address is intended to be used for 564 applications where a node needs to communicate with any one of the 565 set of routers. 567 2.7 Multicast Addresses 569 An IPv6 multicast address is an identifier for a group of interfaces 570 (typically on different nodes). An interface may belong to any 571 number of multicast groups. Multicast addresses have the following 572 format: 574 | 8 | 4 | 4 | 112 bits | 575 +------ -+----+----+---------------------------------------------+ 576 |11111111|flgs|scop| group ID | 577 +--------+----+----+---------------------------------------------+ 579 binary 11111111 at the start of the address identifies the 580 address as being a multicast address. 582 +-+-+-+-+ 583 flgs is a set of 4 flags: |0|0|0|T| 584 +-+-+-+-+ 586 The high-order 3 flags are reserved, and must be 587 initialized to 0. 589 T = 0 indicates a permanently-assigned ("well-known") 590 multicast address, assigned by the Internet Assigned Number 591 Authority (IANA). 593 T = 1 indicates a non-permanently-assigned ("transient") 594 multicast address. 596 scop is a 4-bit multicast scope value used to limit the scope of 597 the multicast group. The values are: 599 0 reserved 600 1 interface-local scope 601 2 link-local scope 602 3 subnet-local scope 603 4 admin-local scope 604 5 site-local scope 605 6 (unassigned) 606 7 (unassigned) 607 8 organization-local scope 608 9 (unassigned) 609 A (unassigned) 610 B (unassigned) 611 C (unassigned) 612 D (unassigned) 613 E global scope 614 F reserved 616 interface-local scope spans only a single interface on a 617 node, and is useful only for loopback transmission of 618 multicast. 620 link-local and site-local multicast scopes span the same 621 topological regions as the corresponding unicast scopes. 623 subnet-local scope is given a different and larger value 624 than link-local to enable possible support for subnets 625 that span multiple links. 627 admin-local scope is the smallest scope that must be 628 administratively configured, i.e., not automatically 629 derived from physical connectivity or other, non- 630 multicast-related configuration. 632 organization-local scope is intended to span multiple 633 sites belonging to a single organization. 635 scopes labelled "(unassigned)" are available for 636 administrators to define additional multicast regions. 638 group ID identifies the multicast group, either permanent or 639 transient, within the given scope. 641 The "meaning" of a permanently-assigned multicast address is 642 independent of the scope value. For example, if the "NTP servers 643 group" is assigned a permanent multicast address with a group ID of 644 101 (hex), then: 646 FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface 647 (i.e., the same node) as the sender. 649 FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as 650 the sender. 652 FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as 653 the sender. 655 FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet. 657 Non-permanently-assigned multicast addresses are meaningful only 658 within a given scope. For example, a group identified by the non- 659 permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one 660 site bears no relationship to a group using the same address at a 661 different site, nor to a non-permanent group using the same group ID 662 with different scope, nor to a permanent group with the same group 663 ID. 665 Multicast addresses must not be used as source addresses in IPv6 666 packets or appear in any Routing header. 668 Routers must not forward any multicast packets beyond of the scope 669 indicated by the scop field in the destination multicast address. 671 2.7.1 Pre-Defined Multicast Addresses 673 The following well-known multicast addresses are pre-defined. The 674 group ID's defined in this section are defined for explicit scope 675 values. 677 Use of these group IDs for any other scope values, with the T flag 678 equal to 0, is not allowed. 680 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 681 FF01:0:0:0:0:0:0:0 682 FF02:0:0:0:0:0:0:0 683 FF03:0:0:0:0:0:0:0 684 FF04:0:0:0:0:0:0:0 685 FF05:0:0:0:0:0:0:0 686 FF06:0:0:0:0:0:0:0 687 FF07:0:0:0:0:0:0:0 688 FF08:0:0:0:0:0:0:0 689 FF09:0:0:0:0:0:0:0 690 FF0A:0:0:0:0:0:0:0 691 FF0B:0:0:0:0:0:0:0 692 FF0C:0:0:0:0:0:0:0 693 FF0D:0:0:0:0:0:0:0 694 FF0E:0:0:0:0:0:0:0 695 FF0F:0:0:0:0:0:0:0 697 The above multicast addresses are reserved and shall never be 698 assigned to any multicast group. 700 All Nodes Addresses: FF01:0:0:0:0:0:0:1 701 FF02:0:0:0:0:0:0:1 703 The above multicast addresses identify the group of all IPv6 nodes, 704 within scope 1 (interface-local) or 2 (link-local). 706 All Routers Addresses: FF01:0:0:0:0:0:0:2 707 FF02:0:0:0:0:0:0:2 708 FF05:0:0:0:0:0:0:2 710 The above multicast addresses identify the group of all IPv6 routers, 711 within scope 1 (interface-local), 2 (link-local), or 5 (site-local). 713 Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX 715 Solicited-node multicast address are computed as a function of a 716 node's unicast and anycast addresses. A solicited-node multicast 717 address is formed by taking the low-order 24 bits of an address 718 (unicast or anycast) and appending those bits to the prefix 719 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the 720 range 722 FF02:0:0:0:0:1:FF00:0000 724 to 726 FF02:0:0:0:0:1:FFFF:FFFF 728 For example, the solicited node multicast address corresponding to 729 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 730 addresses that differ only in the high-order bits, e.g. due to 731 multiple high-order prefixes associated with different aggregations, 732 will map to the same solicited-node address thereby, reducing the 733 number of multicast addresses a node must join. 735 A node is required to compute and join the associated Solicited-Node 736 multicast addresses for every unicast and anycast address it is 737 assigned. 739 2.8 A Node's Required Addresses 741 A host is required to recognize the following addresses as 742 identifying itself: 744 o Its required Link-Local Address for each interface. 745 o Any additional Unicast and Anycast Addresses that have been 746 configured for the node's interfaces (manually or 747 automatically). 748 o The loopback address. 749 o The All-Nodes Multicast Addresses defined in section 2.7.1. 750 o The Solicited-Node Multicast Address for each of its unicast and 751 anycast addresses. 752 o Multicast Addresses of all other groups to which the node 753 belongs. 755 A router is required to recognize all addresses that a host is 756 required to recognize, plus the following addresses as identifying. 757 itself: 759 o The Subnet-Router Anycast Addresses for all interfaces for which 760 it is configured to act as a router. 761 o All other Anycast Addresses with which the router has been 762 configured. 763 o The All-Routers Multicast Addresses defined in section 2.7.1. 765 3. Security Considerations 767 IPv6 addressing documents do not have any direct impact on Internet 768 infrastructure security. Authentication of IPv6 packets is defined 769 in [AUTH]. 771 4. IANA Considerations 773 [Note to RFC editor: "RFCxxxx" below should be the RFC assigned to 774 this document] 776 The table and notes at http://www.isi.edu/in- 777 notes/iana/assignments/ipv6-address-space.txt should be replaced with 778 the following: 780 INTERNET PROTOCOL VERSION 6 ADDRESS SPACE 782 As defined in RFCxxxx the type of an IPv6 address is identified by 783 the high-order bits of the address, as follows: 785 Allocation Prefix Fraction of 786 (binary) Address Space 787 ----------------------------------- -------- ------------- 788 Unassigned (see Note 1 below) 0000 0000 1/256 789 Unassigned 0000 0001 1/256 790 Reserved for NSAP Allocation 0000 001 1/128 [RFC1888] 791 Unassigned 0000 01 1/64 792 Unassigned 0000 1 1/32 793 Unassigned 0001 1/16 794 Global Unicast 001 1/8 [RFC2374] 795 Unassigned 010 1/8 796 Unassigned 011 1/8 797 Unassigned 100 1/8 798 Unassigned 101 1/8 799 Unassigned 110 1/8 800 Unassigned 1110 1/16 801 Unassigned 1111 0 1/32 802 Unassigned 1111 10 1/64 803 Unassigned 1111 110 1/128 804 Unassigned 1111 1110 0 1/512 805 Link-Local Unicast Addresses 1111 1110 10 1/1024 806 Site-Local Unicast Addresses 1111 1110 11 1/1024 807 Multicast Addresses 1111 1111 1/256 809 Notes: 811 1) The "unspecified address", the "loopback address", and the IPv6 812 Addresses with Embedded IPv4 Addresses are assigned out of the 813 0000 0000 binary prefix space. 815 2) For now, IANA should limit its allocation of IPv6 unicast 816 address space to the range of addresses that start with binary 817 value 001. The rest of the global unicast address space 818 (approximately 85% of the IPv6 address space) is reserved for 819 future definition and use, and is not to be assigned by IANA at 820 this time. 822 APPENDIX A: Creating Modified EUI-64 format Interface Identifiers 823 ------------------------------------------------------------------ 825 Depending on the characteristics of a specific link or node there 826 are a number of approaches for creating Modified EUI-64 format 827 interface identifiers. This appendix describes some of these 828 approaches. 830 Links or Nodes with IEEE EUI-64 Identifiers 832 The only change needed to transform an IEEE EUI-64 identifier to 833 an interface identifier is to invert the "u" (universal/local) 834 bit. For example, a globally unique IEEE EUI-64 identifier of the 835 form: 837 |0 1|1 3|3 4|4 6| 838 |0 5|6 1|2 7|8 3| 839 +----------------+----------------+----------------+----------------+ 840 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 841 +----------------+----------------+----------------+----------------+ 843 where "c" are the bits of the assigned company_id, "0" is the 844 value of the universal/local bit to indicate global scope, "g" is 845 individual/group bit, and "m" are the bits of the manufacturer- 846 selected extension identifier. The IPv6 interface identifier 847 would be of the form: 849 |0 1|1 3|3 4|4 6| 850 |0 5|6 1|2 7|8 3| 851 +----------------+----------------+----------------+----------------+ 852 |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| 853 +----------------+----------------+----------------+----------------+ 855 The only change is inverting the value of the universal/local bit. 857 Links or Nodes with IEEE 802 48 bit MAC's 859 [EUI64] defines a method to create a IEEE EUI-64 identifier from 860 an IEEE 48bit MAC identifier. This is to insert two octets, with 861 hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit 862 MAC (between the company_id and vendor supplied id). For example 863 the 48 bit IEEE MAC with global scope: 865 |0 1|1 3|3 4| 866 |0 5|6 1|2 7| 867 +----------------+----------------+----------------+ 868 |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| 869 +----------------+----------------+----------------+ 871 where "c" are the bits of the assigned company_id, "0" is the 872 value of the universal/local bit to indicate global scope, "g" is 873 individual/group bit, and "m" are the bits of the manufacturer- 874 selected extension identifier. The interface identifier would be 875 of the form: 877 |0 1|1 3|3 4|4 6| 878 |0 5|6 1|2 7|8 3| 879 +----------------+----------------+----------------+----------------+ 880 |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| 881 +----------------+----------------+----------------+----------------+ 883 When IEEE 802 48bit MAC addresses are available (on an interface 884 or a node), an implementation may use them to create interface 885 identifiers due to their availability and uniqueness properties. 887 Links with Non-Global Identifiers 889 There are a number of types of links that, while multi-access, do 890 not have globally unique link identifiers. Examples include 891 LocalTalk and Arcnet. The method to create an Modified EUI-64 892 format identifier is to take the link identifier (e.g., the 893 LocalTalk 8 bit node identifier) and zero fill it to the left. 894 For example a LocalTalk 8 bit node identifier of hexadecimal value 895 0x4F results in the following interface identifier: 897 |0 1|1 3|3 4|4 6| 898 |0 5|6 1|2 7|8 3| 899 +----------------+----------------+----------------+----------------+ 900 |0000000000000000|0000000000000000|0000000000000000|0000000001001111| 901 +----------------+----------------+----------------+----------------+ 903 Note that this results in the universal/local bit set to "0" to 904 indicate local scope. 906 Links without Identifiers 908 There are a number of links that do not have any type of built-in 909 identifier. The most common of these are serial links and 910 configured tunnels. Interface identifiers must be chosen that are 911 unique for the link. 913 When no built-in identifier is available on a link the preferred 914 approach is to use a global interface identifier from another 915 interface or one which is assigned to the node itself. When using 916 this approach no other interface connecting the same node to the 917 same link may use the same identifier. 919 If there is no global interface identifier available for use on 920 the link the implementation needs to create a local-scope 921 interface identifier. The only requirement is that it be unique 922 on the link. There are many possible approaches to select a link- 923 unique interface identifier. These include: 925 Manual Configuration 926 Node Serial Number 927 Other node-specific token 929 The link-unique interface identifier should be generated in a 930 manner that it does not change after a reboot of a node or if 931 interfaces are added or deleted from the node. 933 The selection of the appropriate algorithm is link and 934 implementation dependent. The details on forming interface 935 identifiers are defined in the appropriate "IPv6 over " 936 specification. It is strongly recommended that a collision 937 detection algorithm be implemented as part of any automatic 938 algorithm. 940 APPENDIX B: Changes from RFC-2373 941 --------------------------------- 943 The following changes were made from RFC-2373 "IP Version 6 944 Addressing Architecture": 946 - Added description of multicast scop values. 947 - Many small changes to clarify and make the text more 948 consistent. 949 - Revised sections 2.4 and 2.5.6 to simplify and clarify how 950 different address types are identified. This was done to 951 insure that implementations do build in any knowledge about 952 global unicast format prefixes. Changes include: 953 o Removed Format Prefix (FP) terminology 954 o Revised list of address types only includes exceptions to 955 global unicast and a singe entry that identifies everything 956 else as Global Unicast. 957 o Removed list of defined prefix exceptions from section 958 2.5.6 as it is now the main part of section 2.4. 959 - Clarified text relating to EUI-64 identifiers to distinguish 960 between IPv6's "Modified EUI-64 format" identifiers and IEEE 961 EUI-64 identifiers. 962 - Combined the sections on the Global Unicast Addresses and NSAP 963 Addresses into a single section on Global Unicast Addresses, 964 generalized the Global Unicast format, and cited [AGGR] and 965 [NSAP] as examples. 966 - Reordered sections 2.5.4 and 2.5.5. 967 - Removed section 2.7.2 Assignment of New IPv6 Multicast 968 Addresses because this is being redefined elsewhere. 969 - Added an IANA considerations section that updates the IANA IPv6 970 address allocations and documents the NSAP and AGGR 971 allocations. 972 - Added clarification that the "IPv4-compatible IPv6 address" 973 must use global IPv4 unicast addresses. 974 - Divided references in to normative and non-normative sections. 975 - Added reference to [PRIV] in section 2.5.1 976 - Revised section 2.4 Address Type Representation to 977 - Added clarification that routers must not forward multicast 978 packets outside of the scope indicated in the multicast 979 address. 980 - Added clarification that routers must not forward packets with 981 source address of the unspecified address. 982 - Added clarification that routers must drop packets received on 983 an interface with destination address of loopback. 984 - Clarified the definition of IPv4-mapped addresses. 985 - Removed the ABNF Description of Text Representations Appendix. 987 - Removed the address block reserved for IPX addresses. 988 - Multicast scope changes: 989 o Changed name of scope value 1 from "node-local" to 990 "interface-local" 991 o Defined scope value 3 for "subnet-local" for multi-link 992 subnets 993 o Defined scope value 4 as "admin-local" 994 - Corrected reference to RFC1933 and updated references. 996 REFERENCES 998 Normative References 1000 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 1001 (IPv6) Specification", RFC2460, December 1998. 1003 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1004 3", RFC2026, BCP00009, October 1996. 1006 Non-Normative References 1008 [ANYCST] Partridge, C., T. Mendez, and W. Milliken, "Host Anycasting 1009 Service", RFC1546, November 1993. 1011 [AUTH] Kent, S., R. Atkinson, "IP Authentication Header", RFC2402, 1012 November 1998. 1014 [AGGR] Hinden, R., S. Deering, M. O'Dell, "An Aggregatable Global 1015 Unicast Address Format", RFC2374, July 1998. 1017 [CIDR] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless Inter- 1018 Domain Routing (CIDR): An Address Assignment and 1019 Aggregation Strategy", RFC1519, September 1993. 1021 [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1022 Networks", RFC2464, December 1998. 1024 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 1025 Registration Authority", 1026 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 1027 , March 1997. 1029 [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI 1030 Networks", RFC2467, December 1998. 1032 [MASGN] Hinden, R., "IPv6 Multicast Address Assignments", RFC2375, 1033 July 1998. 1035 [NSAP] Bound, J., B. Carpenter, D. Harrington, J. Houldsworth, A. 1036 Lloyd, "OSI NSAPs and IPv6", RFC1888, August 1996. 1038 [PRIV] Narten, T., R. Draves, "Privacy Extensions for Stateless 1039 Address Autoconfiguration in IPv6", RFC3041, January 2001. 1041 [TOKEN] Crawford, M., T. Narten, S. Thomas, "Transmission of IPv6 1042 Packets over Token Ring Networks", RFC2470, December 1998. 1044 [TRAN] Gilligan, R., E. Nordmark, "Transition Mechanisms for IPv6 1045 Hosts and Routers", RFC2893, August 2000. 1047 AUTHOR'S ADDRESSES 1049 Robert M. Hinden 1050 Nokia 1051 313 Fairchild Drive 1052 Mountain View, CA 94043 1053 USA 1055 phone: +1 650 625-2004 1056 email: hinden@iprg.nokia.com 1058 Stephen E. Deering 1059 Cisco Systems, Inc. 1060 170 West Tasman Drive 1061 San Jose, CA 95134-1706 1062 USA 1064 phone: +1 408 527-8213 1065 email: deering@cisco.com