idnits 2.17.1 draft-ietf-ipngwg-ipv6-arch-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([IPV6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 21 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 511: '... Routers MUST not forward any packet...' RFC 2119 keyword, line 530: '... Routers MUST not forward any packet...' RFC 2119 keyword, line 580: '... anycast address MUST NOT be used as t...' RFC 2119 keyword, line 583: '... anycast address MUST NOT be assigned ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 204 has weird spacing: '...address is ...' == Line 209 has weird spacing: '...-length is a...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Routers MUST not forward any packets with link-local source addresses. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Routers MUST not forward any packets with site-local source addresses outside of the site. -- 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: 'ANYCST' is mentioned on line 576, but not defined == Unused Reference: 'MULT' is defined on line 811, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1887 (ref. 'ALLOC') ** Obsolete normative reference: RFC 1338 (ref. 'CIDR') (Obsoleted by RFC 1519) ** Obsolete normative reference: RFC 1883 (ref. 'IPV6') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1888 (ref. 'NSAP') (Obsoleted by RFC 4048) Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Ipsilon Networks 2 March 25, 1997 S. Deering, Cisco Systems 4 IP Version 6 Addressing Architecture 6 draft-ietf-ipngwg-ipv6-arch-00.txt 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 22 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 This Internet Draft expires October 1997. 28 Abstract 30 This specification defines the addressing architecture of the IP 31 Version 6 protocol [IPV6]. The document includes the IPv6 addressing 32 model, text representations of IPv6 addresses, definition of IPv6 33 unicast addresses, anycast addresses, and multicast addresses, and an 34 IPv6 nodes required addresses. 36 Table of Contents 38 1. Introduction.................................................3 40 2. IPv6 Addressing..............................................3 41 2.1 Addressing Model.........................................4 42 2.2 Text Representation of Addresses.........................4 43 2.3 Text Representation of Address Prefixes..................5 44 2.4 Address Type Representation..............................6 45 2.5 Unicast Addresses........................................8 46 2.5.1 Unicast Address Example..............................9 47 2.5.2 The Unspecified Address.............................10 48 2.5.3 The Loopback Address................................10 49 2.5.4 IPv6 Addresses with Embedded IPv4 Addresses.........10 50 2.5.5 NSAP Addresses......................................11 51 2.5.6 IPX Addresses.......................................11 52 2.5.7 Provider-Based Global Unicast Addresses.............11 53 2.5.8 Local-use IPv6 Unicast Addresses....................12 54 2.6 Anycast Addresses.......................................13 55 2.6.1 Required Anycast Address............................14 56 2.7 Multicast Addresses.....................................15 57 2.7.1 Pre-Defined Multicast Addresses.....................16 58 2.8 A Node's Required Addresses.............................18 60 REFERENCES.....................................................20 62 SECURITY CONSIDERATIONS........................................20 64 AUTHOR'S ADDRESSES.............................................20 66 1.0 INTRODUCTION 68 This specification defines the addressing architecture of the IP 69 Version 6 protocol. It includes a detailed description of the 70 currently defined address formats for IPv6 [IPV6]. 72 The authors would like to acknowledge the contributions of Paul 73 Francis, Jim Bound, Brian Carpenter, Deborah Estrin, Peter Ford, Bob 74 Gilligan, Christian Huitema, Tony Li, Greg Minshall, Erik Nordmark, 75 Yakov Rekhter, Bill Simpson, and Sue Thomson. 77 2.0 IPv6 ADDRESSING 79 IPv6 addresses are 128-bit identifiers for interfaces and sets of 80 interfaces. There are three types of addresses: 82 Unicast: An identifier for a single interface. A packet sent to a 83 unicast address is delivered to the interface identified 84 by that address. 86 Anycast: An identifier for a set of interfaces (typically 87 belonging to different nodes). A packet sent to an 88 anycast address is delivered to one of the interfaces 89 identified by that address (the "nearest" one, according 90 to the routing protocols' measure of distance). 92 Multicast: An identifier for a set of interfaces (typically 93 belonging to different nodes). A packet sent to a 94 multicast address is delivered to all interfaces 95 identified by that address. 97 There are no broadcast addresses in IPv6, their function being 98 superseded by multicast addresses. 100 In this document, fields in addresses are given a specific name, for 101 example "subscriber". When this name is used with the term "ID" for 102 identifier after the name (e.g., "subscriber ID"), it refers to the 103 contents of the named field. When it is used with the term "prefix" 104 (e.g. "subscriber prefix") it refers to all of the address up to and 105 including this field. 107 In IPv6, all zeros and all ones are legal values for any field, 108 unless specifically excluded. Specifically, prefixes may contain 109 zero-valued fields or end in zeros. 111 2.1 Addressing Model 113 IPv6 Addresses of all types are assigned to interfaces, not nodes. 114 Since each interface belongs to a single node, any of that node's 115 interfaces' unicast addresses may be used as an identifier for the 116 node. 118 An IPv6 unicast address refers to a single interface. A single 119 interface may be assigned multiple IPv6 addresses of any type 120 (unicast, anycast, and multicast). There are two exceptions to this 121 model. These are: 123 1) A single address may be assigned to multiple physical interfaces 124 if the implementation treats the multiple physical interfaces as 125 one interface when presenting it to the internet layer. This is 126 useful for load-sharing over multiple physical interfaces. 128 2) Routers may have unnumbered interfaces (i.e., no IPv6 address 129 assigned to the interface) on point-to-point links to eliminate 130 the necessity to manually configure and advertise the addresses. 131 Addresses are not needed for point-to-point interfaces on routers 132 if those interfaces are not to be used as the origins or 133 destinations of any IPv6 datagrams. 135 IPv6 continues the IPv4 model that a subnet is associated with one 136 link. Multiple subnets may be assigned to the same link. 138 2.2 Text Representation of Addresses 140 There are three conventional forms for representing IPv6 addresses as 141 text strings: 143 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the 144 hexadecimal values of the eight 16-bit pieces of the address. 145 Examples: 147 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 149 1080:0:0:0:8:800:200C:417A 151 Note that it is not necessary to write the leading zeros in an 152 individual field, but there must be at least one numeral in every 153 field (except for the case described in 2.). 155 2. Due to the method of allocating certain styles of IPv6 addresses, 156 it will be common for addresses to contain long strings of zero 157 bits. In order to make writing addresses containing zero bits 158 easier a special syntax is available to compress the zeros. The 159 use of "::" indicates multiple groups of 16-bits of zeros. The 160 "::" can only appear once in an address. The "::" can also be 161 used to compress the leading and/or trailing zeros in an address. 163 For example the following addresses: 165 1080:0:0:0:8:800:200C:417A a unicast address 166 FF01:0:0:0:0:0:0:43 a multicast address 167 0:0:0:0:0:0:0:1 the loopback address 168 0:0:0:0:0:0:0:0 the unspecified addresses 170 may be represented as: 172 1080::8:800:200C:417A a unicast address 173 FF01::43 a multicast address 174 ::1 the loopback address 175 :: the unspecified addresses 177 3. An alternative form that is sometimes more convenient when dealing 178 with a mixed environment of IPv4 and IPv6 nodes is 179 x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of 180 the six high-order 16-bit pieces of the address, and the 'd's are 181 the decimal values of the four low-order 8-bit pieces of the 182 address (standard IPv4 representation). Examples: 184 0:0:0:0:0:0:13.1.68.3 186 0:0:0:0:0:FFFF:129.144.52.38 188 or in compressed form: 190 ::13.1.68.3 192 ::FFFF:129.144.52.38 194 2.3 Text Representation of Address Prefixes 196 The text representation of IPv6 address prefixes is similar to the 197 way IPv4 addresses prefixes are written in CIDR notation. An IPv6 198 address prefix is represented by the notation: 200 ipv6-address/prefix-length 202 where 204 ipv6-address is an IPv6 address in any of the notations listed 205 in section 2.2, with the extra rule that, if the 206 written address ends in "::", the trailing "::" 207 may be omitted. 209 prefix-length is a decimal value specifying how many of the 210 leftmost contiguous bits of the address comprise 211 the prefix. 213 For example, the following are legal representations of the 60-bit 214 prefix 12AB00000000CD3 (hexadecimal): 216 12AB:0000:0000:CD30:0000:0000:0000:0000/60 217 12AB::CD30:0:0:0:0/60 218 12AB:0:0:CD30::/60 219 12AB:0:0:CD30/60 221 The following are NOT legal representations of the above prefix: 223 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, 224 within any 16-bit chunk of the address 226 12AB::CD30/60 address to left of "/" expands to 227 12AB:0000:0000:0000:0000:000:0000:CD30 229 12AB::CD3/60 address to left of "/" expands to 230 12AB:0000:0000:0000:0000:000:0000:0CD3 232 When writing both a node address and a prefix of that node address 233 (e.g., the node's subnet prefix), the two can combined as follows: 235 the node address 12AB:0:0:CD30:123:4567:89AB:CDEF 236 and its subnet number 12AB:0:0:CD30/60 238 can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 240 2.4 Address Type Representation 242 The specific type of an IPv6 address is indicated by the leading bits 243 in the address. The variable-length field comprising these leading 244 bits is called the Format Prefix (FP). The initial allocation of 245 these prefixes is as follows: 247 Allocation Prefix Fraction of 248 (binary) Address Space 249 ------------------------------- -------- ------------- 250 Reserved 0000 0000 1/256 251 Unassigned 0000 0001 1/256 253 Reserved for NSAP Allocation 0000 001 1/128 254 Reserved for IPX Allocation 0000 010 1/128 256 Unassigned 0000 011 1/128 257 Unassigned 0000 1 1/32 258 Unassigned 0001 1/16 259 Unassigned 001 1/8 261 Provider-Based Unicast Address 010 1/8 263 Unassigned 011 1/8 265 Reserved for Geographic- 266 Based Unicast Addresses 100 1/8 268 Unassigned 101 1/8 269 Unassigned 110 1/8 270 Unassigned 1110 1/16 271 Unassigned 1111 0 1/32 272 Unassigned 1111 10 1/64 273 Unassigned 1111 110 1/128 275 Unassigned 1111 1110 0 1/512 277 Link Local Use Addresses 1111 1110 10 1/1024 278 Site Local Use Addresses 1111 1110 11 1/1024 280 Multicast Addresses 1111 1111 1/256 282 Note: The "unspecified address" (see section 2.4.2), the loopback 283 address (see section 2.4.3), and the IPv6 Addresses with Embedded 284 IPv4 Addresses (see section 2.4.4), are assigned out of the 0000 285 0000 format prefix space. 287 This allocation supports the direct allocation of provider addresses, 288 local use addresses, and multicast addresses. Space is reserved for 289 NSAP addresses, IPX addresses, and geographic addresses. The 290 remainder of the address space is unassigned for future use. This 291 can be used for expansion of existing use (e.g., additional provider 292 addresses, etc.) or new uses (e.g., separate locators and 293 identifiers). Fifteen percent of the address space is initially 294 allocated. The remaining 85% is reserved for future use. 296 Unicast addresses are distinguished from multicast addresses by the 297 value of the high-order octet of the addresses: a value of FF 298 (11111111) identifies an address as a multicast address; any other 299 value identifies an address as a unicast address. Anycast addresses 300 are taken from the unicast address space, and are not syntactically 301 distinguishable from unicast addresses. 303 2.5 Unicast Addresses 305 The IPv6 unicast address is contiguous bit-wise maskable, similar to 306 IPv4 addresses under Class-less Interdomain Routing [CIDR]. 308 There are several forms of unicast address assignment in IPv6, 309 including the global provider based unicast address, the geographic 310 based unicast address, the NSAP address, the IPX hierarchical 311 address, the site-local-use address, the link-local-use address, and 312 the IPv4-capable host address. Additional address types can be 313 defined in the future. 315 IPv6 nodes may have considerable or little knowledge of the internal 316 structure of the IPv6 address, depending on the role the node plays 317 (for instance, host versus router). At a minimum, a node may 318 consider that unicast addresses (including its own) have no internal 319 structure: 321 | 128 bits | 322 +-----------------------------------------------------------------+ 323 | node address | 324 +-----------------------------------------------------------------+ 326 A slightly sophisticated host (but still rather simple) may 327 additionally be aware of subnet prefix(es) for the link(s) it is 328 attached to, where different addresses may have different values for 329 n: 331 | n bits | 128-n bits | 332 +------------------------------------------------+----------------+ 333 | subnet prefix | interface ID | 334 +------------------------------------------------+----------------+ 336 Still more sophisticated hosts may be aware of other hierarchical 337 boundaries in the unicast address. Though a very simple router may 338 have no knowledge of the internal structure of IPv6 unicast 339 addresses, routers will more generally have knowledge of one or more 340 of the hierarchical boundaries for the operation of routing 341 protocols. The known boundaries will differ from router to router, 342 depending on what positions the router holds in the routing 343 hierarchy. 345 2.5.1 Unicast Address Examples 347 An example of a Unicast address format which will likely be common on 348 LANs and other environments where IEEE 802 MAC addresses are 349 available is: 351 | n bits | 80-n bits | 48 bits | 352 +--------------------------------+-----------+--------------------+ 353 | subscriber prefix | subnet ID | interface ID | 354 +--------------------------------+-----------+--------------------+ 356 Where the 48-bit Interface ID is an IEEE-802 MAC address. The use of 357 IEEE 802 MAC addresses as a interface ID is expected to be very 358 common in environments where nodes have an IEEE 802 MAC address. In 359 other environments, where IEEE 802 MAC addresses are not available, 360 other types of link layer addresses can be used, such as E.164 361 addresses, for the interface ID. 363 The inclusion of a unique global interface identifier, such as an 364 IEEE MAC address, makes possible a very simple form of auto- 365 configuration of addresses. A node may discover a subnet ID by 366 listening to Router Advertisement messages sent by a router on its 367 attached link(s), and then fabricating an IPv6 address for itself by 368 using its IEEE MAC address as the interface ID on that subnet. 370 Another unicast address format example is where a site or 371 organization requires additional layers of internal hierarchy. In 372 this example the subnet ID is divided into an area ID and a subnet 373 ID. Its format is: 375 | s bits | n bits | m bits | 128-s-n-m bits | 376 +----------------------+---------+--------------+-----------------+ 377 | subscriber prefix | area ID | subnet ID | interface ID | 378 +----------------------+---------+--------------+-----------------+ 380 This technique can be continued to allow a site or organization to 381 add additional layers of internal hierarchy. It may be desirable to 382 use an interface ID smaller than a 48-bit IEEE 802 MAC address to 383 allow more space for the additional layers of internal hierarchy. 384 These could be interface IDs which are administratively created by 385 the site or organization. 387 2.5.2 The Unspecified Address 389 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It 390 must never be assigned to any node. It indicates the absence of an 391 address. One example of its use is in the Source Address field of 392 any IPv6 datagrams sent by an initializing host before it has learned 393 its own address. 395 The unspecified address must not be used as the destination address 396 of IPv6 datagrams or in IPv6 Routing Headers. 398 2.5.3 The Loopback Address 400 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. 401 It may be used by a node to send an IPv6 datagram to itself. It may 402 never be assigned to any interface. 404 The loopback address must not be used as the source address in IPv6 405 datagrams that are sent outside of a single node. An IPv6 datagram 406 with a destination address of loopback must never be sent outside of 407 a single node. 409 2.5.4 IPv6 Addresses with Embedded IPv4 Addresses 411 The IPv6 transition mechanisms include a technique for hosts and 412 routers to dynamically tunnel IPv6 packets over IPv4 routing 413 infrastructure. IPv6 nodes that utilize this technique are assigned 414 special IPv6 unicast addresses that carry an IPv4 address in the low- 415 order 32-bits. This type of address is termed an "IPv4-compatible 416 IPv6 address" and has the format: 418 | 80 bits | 16 | 32 bits | 419 +--------------------------------------+--------------------------+ 420 |0000..............................0000|0000| IPv4 address | 421 +--------------------------------------+----+---------------------+ 423 A second type of IPv6 address which holds an embedded IPv4 address is 424 also defined. This address is used to represent the addresses of 425 IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. 426 This type of address is termed an "IPv4-mapped IPv6 address" and has 427 the format: 429 | 80 bits | 16 | 32 bits | 430 +--------------------------------------+--------------------------+ 431 |0000..............................0000|FFFF| IPv4 address | 432 +--------------------------------------+----+---------------------+ 434 2.5.5 NSAP Addresses 436 This mapping of NSAP address into IPv6 addresses is as follows: 438 | 7 | 121 bits | 439 +-------+---------------------------------------------------------+ 440 |0000001| to be defined | 441 +-------+---------------------------------------------------------+ 443 The draft definition, motivation, and usage are under study [NSAP]. 445 2.5.6 IPX Addresses 447 This mapping of IPX address into IPv6 addresses is as follows: 449 | 7 | 121 bits | 450 +-------+---------------------------------------------------------+ 451 |0000010| to be defined | 452 +-------+---------------------------------------------------------+ 454 The draft definition, motivation, and usage are under study. 456 2.5.7 Provider-Based Global Unicast Addresses 458 The global provider-based unicast address is assigned as described in 459 [ALLOC]. This initial assignment plan for these unicast addresses is 460 similar to assignment of IPv4 addresses under the CIDR scheme [CIDR]. 461 The IPv6 global provider-based unicast address format is as follows: 463 | 3 | n bits | m bits | o bits | 125-n-m-o bits | 464 +---+-----------+-----------+-------------+--------------------+ 465 |010|registry ID|provider ID|subscriber ID| intra-subscriber | 466 +---+-----------+-----------+-------------+--------------------+ 468 The high-order part of the address is assigned to registries, who 469 then assign portions of the address space to providers, who then 470 assign portions of the address space to subscribers, etc. 472 The registry ID identifies the registry which assigns the provider 473 portion of the address. The term "registry prefix" refers to the 474 high-order part of the address up to and including the registry ID. 476 The provider ID identifies a specific provider which assigns the 477 subscriber portion of the address. The term "provider prefix" refers 478 to the high-order part of the address up to and including the 479 provider ID. 481 The subscriber ID distinguishes among multiple subscribers attached 482 to the provider identified by the provider ID. The term "subscriber 483 prefix" refers to the high-order part of the address up to and 484 including the subscriber ID. 486 The intra-subscriber portion of the address is defined by an 487 individual subscriber and is organized according to the subscribers 488 local internet topology. It is likely that many subscribers will 489 choose to divide the intra-subscriber portion of the address into a 490 subnet ID and an interface ID. In this case the subnet ID identifies 491 a specific physical link and the interface ID identifies a single 492 interface on that subnet. 494 2.5.8 Local-use IPv6 Unicast Addresses 496 There are two types of local-use unicast addresses defined. These 497 are Link-Local and Site-Local. The Link-Local is for use on a single 498 link and the Site-Local is for use in a single site. Link-Local 499 addresses have the following format: 501 | 10 | 502 | bits | n bits | 118-n bits | 503 +----------+-------------------------+----------------------------+ 504 |1111111010| 0 | interface ID | 505 +----------+-------------------------+----------------------------+ 507 Link-Local addresses are designed to be used for addressing on a 508 single link for purposes such as auto-address configuration, neighbor 509 discovery, or when no routers are present. 511 Routers MUST not forward any packets with link-local source 512 addresses. 514 Site-Local addresses have the following format: 516 | 10 | 517 | bits | n bits | m bits | 118-n-m bits | 518 +----------+---------+---------------+----------------------------+ 519 |1111111011| 0 | subnet ID | interface ID | 520 +----------+---------+---------------+----------------------------+ 522 Site-Local addresses may be used for sites or organizations that are 523 not (yet) connected to the global Internet. They do not need to 524 request or "steal" an address prefix from the global Internet address 525 space. IPv6 site-local addresses can be used instead. When the 526 organization connects to the global Internet, it can then form global 527 addresses by replacing the site-local prefix with a subscriber 528 prefix. 530 Routers MUST not forward any packets with site-local source addresses 531 outside of the site. 533 2.6 Anycast Addresses 535 An IPv6 anycast address is an address that is assigned to more than 536 one interface (typically belonging to different nodes), with the 537 property that a packet sent to an anycast address is routed to the 538 "nearest" interface having that address, according to the routing 539 protocols' measure of distance. 541 Anycast addresses are allocated from the unicast address space, using 542 any of the defined unicast address formats. Thus, anycast addresses 543 are syntactically indistinguishable from unicast addresses. When a 544 unicast address is assigned to more than one interface, thus turning 545 it into an anycast address, the nodes to which the address is 546 assigned must be explicitly configured to know that it is an anycast 547 address. 549 For any assigned anycast address, there is a longest address prefix P 550 that identifies the topological region in which all interfaces 551 belonging to that anycast address reside. Within the region 552 identified by P, each member of the anycast set must be advertised as 553 a separate entry in the routing system (commonly referred to as a 554 "host route"); outside the region identified by P, the anycast 555 address may be aggregated into the routing advertisement for prefix 556 P. 558 Note that in, the worst case, the prefix P of an anycast set may be 559 the null prefix, i.e., the members of the set may have no topological 560 locality. In that case, the anycast address must be advertised as a 561 separate routing entry throughout the entire internet, which presents 562 a severe scaling limit on how many such "global" anycast sets may be 563 supported. Therefore, it is expected that support for global anycast 564 sets may be unavailable or very restricted. 566 One expected use of anycast addresses is to identify the set of 567 routers belonging to an internet service provider. Such addresses 568 could be used as intermediate addresses in an IPv6 Routing header, to 569 cause a packet to be delivered via a particular provider or sequence 570 of providers. Some other possible uses are to identify the set of 571 routers attached to a particular subnet, or the set of routers 572 providing entry into a particular routing domain. 574 There is little experience with widespread, arbitrary use of internet 575 anycast addresses, and some known complications and hazards when 576 using them in their full generality [ANYCST]. Until more experience 577 has been gained and solutions agreed upon for those problems, the 578 following restrictions are imposed on IPv6 anycast addresses: 580 o An anycast address MUST NOT be used as the source address of an 581 IPv6 packet. 583 o An anycast address MUST NOT be assigned to an IPv6 host, that 584 is, it may be assigned to an IPv6 router only. 586 2.6.1 Required Anycast Address 588 The Subnet-Router anycast address is predefined. It's format is as 589 follows: 591 | n bits | 128-n bits | 592 +------------------------------------------------+----------------+ 593 | subnet prefix | 00000000000000 | 594 +------------------------------------------------+----------------+ 596 The "subnet prefix" in an anycast address is the prefix which 597 identifies a specific link. This anycast address is syntactically 598 the same as a unicast address for an interface on the link with the 599 interface identifier set to zero. 601 Packets sent to the Subnet-Router anycast address will be delivered 602 to one router on the subnet. All routers are required to support the 603 Subnet-Router anycast addresses for the subnets which they have 604 interfaces. 606 The subnet-router anycast address is intended to be used for 607 applications where a node needs to communicate with one of a set of 608 routers on a remote subnet. For example when a mobile host needs to 609 communicate with one of the mobile agents on it's "home" subnet. 611 2.7 Multicast Addresses 613 An IPv6 multicast address is an identifier for a group of nodes. A 614 node may belong to any number of multicast groups. Multicast 615 addresses have the following format: 617 | 8 | 4 | 4 | 112 bits | 618 +------ -+----+----+---------------------------------------------+ 619 |11111111|flgs|scop| group ID | 620 +--------+----+----+---------------------------------------------+ 622 11111111 at the start of the address identifies the address as 623 being a multicast address. 625 +-+-+-+-+ 626 flgs is a set of 4 flags: |0|0|0|T| 627 +-+-+-+-+ 629 The high-order 3 flags are reserved, and must be 630 initialized to 0. 632 T = 0 indicates a permanently-assigned ("well-known") 633 multicast address, assigned by the global internet 634 numbering authority. 636 T = 1 indicates a non-permanently-assigned ("transient") 637 multicast address. 639 scop is a 4-bit multicast scope value used to limit the scope of 640 the multicast group. The values are: 642 0 reserved 643 1 node-local scope 644 2 link-local scope 645 3 (unassigned) 646 4 (unassigned) 647 5 site-local scope 648 6 (unassigned) 649 7 (unassigned) 650 8 organization-local scope 651 9 (unassigned) 652 A (unassigned) 653 B (unassigned) 654 C (unassigned) 655 D (unassigned) 656 E global scope 657 F reserved 659 group ID identifies the multicast group, either permanent or 660 transient, within the given scope. 662 The "meaning" of a permanently-assigned multicast address is 663 independent of the scope value. For example, if the "NTP servers 664 group" is assigned a permanent multicast address with a group ID of 665 43 (hex), then: 667 FF01:0:0:0:0:0:0:43 means all NTP servers on the same node as 668 the sender. 670 FF02:0:0:0:0:0:0:43 means all NTP servers on the same link as 671 the sender. 673 FF05:0:0:0:0:0:0:43 means all NTP servers at the same site as 674 the sender. 676 FF0E:0:0:0:0:0:0:43 means all NTP servers in the internet. 678 Non-permanently-assigned multicast addresses are meaningful only 679 within a given scope. For example, a group identified by the non- 680 permanent, site-local multicast address FF15:0:0:0:0:0:0:43 at one 681 site bears no relationship to a group using the same address at a 682 different site, nor to a non-permanent group using the same group ID 683 with different scope, nor to a permanent group with the same group 684 ID. 686 Multicast addresses must not be used as source addresses in IPv6 687 datagrams or appear in any routing header. 689 2.7.1 Pre-Defined Multicast Addresses 691 The following well-known multicast addresses are pre-defined: 693 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 694 FF01:0:0:0:0:0:0:0 695 FF02:0:0:0:0:0:0:0 696 FF03:0:0:0:0:0:0:0 697 FF04:0:0:0:0:0:0:0 698 FF05:0:0:0:0:0:0:0 699 FF06:0:0:0:0:0:0:0 700 FF07:0:0:0:0:0:0:0 701 FF08:0:0:0:0:0:0:0 702 FF09:0:0:0:0:0:0:0 703 FF0A:0:0:0:0:0:0:0 704 FF0B:0:0:0:0:0:0:0 705 FF0C:0:0:0:0:0:0:0 706 FF0D:0:0:0:0:0:0:0 707 FF0E:0:0:0:0:0:0:0 708 FF0F:0:0:0:0:0:0:0 710 The above multicast addresses are reserved and shall never be 711 assigned to any multicast group. 713 All Nodes Addresses: FF01:0:0:0:0:0:0:1 714 FF02:0:0:0:0:0:0:1 716 The above multicast addresses identify the group of all IPv6 nodes, 717 within scope 1 (node-local) or 2 (link-local). 719 All Routers Addresses: FF01:0:0:0:0:0:0:2 720 FF02:0:0:0:0:0:0:2 722 The above multicast addresses identify the group of all IPv6 routers, 723 within scope 1 (node-local) or 2 (link-local). 725 DHCP Server/Relay-Agent: FF02:0:0:0:0:0:1:0 727 The above multicast addresses identify the group of all IPv6 DHCP 728 Servers and Relay Agents within scope 2 (link-local). 730 Solicited-Node Address: FF02:0:0:0:0:1:XXXX:XXXX 732 The above multicast address is computed as a function of a node's 733 unicast and anycast addresses. The solicited-node multicast address 734 is formed by taking the low-order 32 bits of the address (unicast or 735 anycast) and appending those bits to the 96-bit prefix FF02:0:0:0:0:1 736 resulting in a multicast address in the range 738 FF02:0:0:0:0:1:0000:0000 740 to 742 FF02:0:0:0:0:1:FFFF:FFFF 744 For example, the solicited node multicast address corresponding to 745 the IPv6 address 4037::01:800:200E:8C6C is FF02::1:200E:8C6C. IPv6 746 addresses that differ only in the high-order bits, e.g. due to 747 multiple high-order prefixes associated with different providers, 748 will map to the same solicited-node address thereby reducing the 749 number of multicast addresses a node must join. 751 A node is required to compute and support a Solicited-Node multicast 752 addresses for every unicast and anycast address it is assigned. 754 2.8 A Node's Required Addresses 756 A host is required to recognize the following addresses as 757 identifying itself: 759 o Its Link-Local Address for each interface 760 o Assigned Unicast Addresses 761 o Loopback Address 762 o All-Nodes Multicast Address 763 o Solicited-Node Multicast Address for each of its assigned 764 unicast and anycast addresses 765 o Multicast Addresses of all other groups which the host belongs. 767 A router is required to recognize the following addresses as 768 identifying itself: 770 o Its Link-Local Address for each interface 771 o Assigned Unicast Addresses 772 o Loopback Address 773 o The Subnet-Router anycast addresses for the links it has 774 interfaces. 775 o All other Anycast addresses with which the router has been 776 configured. 777 o All-Nodes Multicast Address 778 o All-Router Multicast Address 779 o Solicited-Node Multicast Address for each of its assigned 780 unicast and anycast addresses 781 o Multicast Addresses of all other groups which the router 782 belongs. 784 The only address prefixes which should be predefined in an 785 implementation are the: 787 o Unspecified Address 788 o Loopback Address 789 o Multicast Prefix (FF) 790 o Local-Use Prefixes (Link-Local and Site-Local) 791 o Pre-Defined Multicast Addresses 792 o IPv4-Compatible Prefixes 794 Implementations should assume all other addresses are unicast unless 795 specifically configured (e.g., anycast addresses). 797 REFERENCES 799 [ALLOC] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast 800 Address Allocation", RFC1887, December 1995. 802 [ANYCST]C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting 803 Service", RFC1546, November 1993. 805 [CIDR] V. Fuller, T. Li, K. Varadhan, J. Yu, "Supernetting: an 806 Address Assignment and Aggregation Strategy", RFC1338. 808 [IPV6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 809 6 (IPv6) Specification", RFC1883, December 1995. 811 [MULT] S. Deering, "Host Extensions for IP multicasting", RFC 812 1112. 814 [NSAP] J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. 815 Lloyd, "OSI NSAPs and IPv6", RFC1888, August 1996. 817 SECURITY CONSIDERATIONS 819 Security issues are not discussed in this document. 821 AUTHOR'S ADDRESSES 823 Robert M. Hinden Stephen E. Deering 824 Ipsilon Networks, Inc. Cisco Systems, Inc. 825 232 Java Drive 170 West Tasman Drive 826 Sunnyvale, CA 94089 San Jose, CA 95134-1706 827 USA USA 829 phone: +1 408 990-2004 phone: +1 408 527-8213 830 fax: +1 408 743-5677 fax: +1 408 527-8254 831 email: hinden@ipsilon.com email: deering@cisco.com