idnits 2.17.1 draft-ietf-ipngwg-addr-arch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 Abstract section. ** The document seems to lack a Security Considerations section. ** 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 14 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 478: '... anycast address MUST NOT be used as t...' RFC 2119 keyword, line 481: '... anycast address MUST NOT be assigned ...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 474, but not defined == Unused Reference: 'MULT' is defined on line 681, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDRF' -- Possible downref: Non-RFC (?) normative reference: ref. 'ALLOC' ** Obsolete normative reference: RFC 1338 (ref. 'CIDR') (Obsoleted by RFC 1519) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPV6' -- Possible downref: Non-RFC (?) normative reference: ref. 'NSAP' Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Ipsilon Networks 2 May 10, 1995 S. Deering, Xerox PARC 3 Editors 5 IP Version 6 Addressing Architecture 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 23 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 This Internet Draft expires November 1, 1995. 29 1.0 INTRODUCTION 31 This specification defines the addressing architecture of the IP Version 32 6 protocol. It includes a detailed description of the address formats 33 for IPv6 [IPV6]. 35 The editors would like to acknowledge the contributions of Paul Francis, 36 Jim Bound, Brian Carpenter, Deborah Estrin, Peter Ford, Bob Gilligan, 37 Christian Huitema, Tony Li, Greg Minshall, Erik Nordmark, Yakov Rekhtor, 38 Bill Simpson, and Sue Thomson. 40 2.0 IPv6 ADDRESSING 42 IPv6 addresses are 128-bit identifiers for interfaces and sets of 43 interfaces. There are three types of addresses: 45 Unicast: An identifier for a single interface. A packet sent to a 46 unicast address is delivered to the interface identified 47 by that address. 49 Anycast: An identifier for a set of interfaces (typically 50 belonging to different nodes). A packet sent to an 51 anycast address is delivered to one of the interfaces 52 identified by that address (the "nearest" one, according 53 to the routing protocols' measure of distance). 55 Multicast: An identifier for a set of interfaces (typically 56 belonging to different nodes). A packet sent to a 57 multicast address is delivered to all interfaces 58 identified by that address. 60 There are no broadcast addresses in IPv6, their function being 61 superseded by multicast addresses. 63 In this document, fields in addresses are given a specific name, for 64 example "subscriber". When this name is used with the term "ID" for 65 identifier after the name (e.g., "subscriber ID"), it refers to the 66 contents of the named field. When it is used with the term "prefix" 67 (e.g. "subscriber prefix") it refers to all of the address up to and 68 including this field. 70 In IPv6, all zeros and all ones are legal values for any field, unless 71 specifically excluded. Specifically, prefixes may contain zero-valued 72 fields or end in zeros. 74 2.1 Addressing Model 76 IPv6 Addresses of all types are assigned to interfaces, not nodes. 77 Since each interface belongs to a single node, any of that node's 78 interfaces' unicast addresses may be used as an identifier for the node. 80 An IPv6 unicast address refers to a single interface. A single 81 interface may be assigned multiple IPv6 addresses of any type (unicast, 82 anycast, and multicast). There are two exceptions to this model. These 83 are: 85 1) A single address may be assigned to multiple physical interfaces if 86 the implementation treats the multiple physical interfaces as one 87 interface when presenting it to the internet layer. This is useful 88 for load-sharing over multiple physical interfaces. 90 2) Routers may have unnumbered interfaces (i.e., no IPv6 address 91 assigned to the interface) on point-to-point links to eliminate the 92 necessity to manually configure and advertise the addresses. 93 Addresses are not needed for point-to-point interfaces on routers 94 if those interfaces are not to be used as the origins or 95 destinations of any IPv6 datagrams. 97 IPv6 continues the IPv4 model that a subnet is associated with one link. 98 Multiple subnets may be assigned to the same link. 100 2.2 Text Representation of Addresses 102 There are three conventional forms for representing IPv6 addresses as 103 text strings: 105 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the 106 hexadecimal values of the eight 16-bit pieces of the address. 107 Examples: 109 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 111 1080:0:0:0:8:800:200C:417A 113 Note that it is not necessary to write the leading zeros in an 114 individual field, but there must be at least one numeral in every 115 field (except for the case described in 2.). 117 2. Due to the method of allocating certain styles of IPv6 addresses, 118 it will be common for addresses to contain long strings of zero 119 bits. In order to make writing addresses containing zero bits 120 easier a special syntax is available to compress the zeros. The 121 use of two "::" indicate multiple groups of 16-bits of zeros. For 122 example the multicast address: 124 FF01:0:0:0:0:0:0:43 126 may be represented as: 128 FF01::43 130 The "::" can only appear once in an address. The "::" can also be 131 used to compress the leading or trailing zeros in an address. 133 3. An alternative form that is sometimes more convenient when dealing 134 with a mixed environment of IPv4 and IPv6 nodes is 135 x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of 136 the six high-order 16-bit pieces of the address, and the 'd's are 137 the decimal values of the four low-order 8-bit pieces of the 138 address (standard IPv4 representation). Examples: 140 0:0:0:0:0:0:13.1.68.3 142 0:0:0:0:0:FFFF:129.144.52.38 144 or in compressed form: 146 ::13.1.68.3 148 ::FFFF:129.144.52.38 150 2.3 Address Type Representation 152 The specific type of an IPv6 address is indicated by the leading bits in 153 the address. The variable-length field comprising these leading bits is 154 called the Format Prefix (FP). The initial allocation of these prefixes 155 is as follows: 157 Allocation Prefix Fraction of 158 (binary) Address Space 159 ------------------------------- -------- ------------- 160 Reserved 0000 0000 1/256 161 Unassigned 0000 0001 1/256 163 Reserved for NSAP Allocation 0000 001 1/128 164 Reserved for IPX Allocation 0000 010 1/128 166 Unassigned 0000 011 1/128 167 Unassigned 0000 1 1/32 168 Unassigned 0001 1/16 169 Unassigned 001 1/8 171 Provider-Based Unicast Address 010 1/8 173 Unassigned 011 1/8 175 Reserved for Neutral-Interconnect- 176 Based Unicast Addresses 100 1/8 178 Unassigned 101 1/8 179 Unassigned 110 1/8 180 Unassigned 1110 1/16 181 Unassigned 1111 0 1/32 182 Unassigned 1111 10 1/64 183 Unassigned 1111 110 1/128 185 Unassigned 1111 1110 0 1/512 187 Link Local Use Addresses 1111 1110 10 1/1024 188 Site Local Use Addresses 1111 1110 11 1/1024 190 Multicast Addresses 1111 1111 1/256 192 Note: The "unspecified address" (see section 2.4.2), the loopback 193 address (see section 2.4.3), and the IPv6 Addresses with Embedded 194 IPv4 Addresses (see section 2.4.4), are assigned out of the 0000 195 0000 format prefix space. 197 This allocation supports the direct allocation of provider addresses, 198 local use addresses, and multicast addresses. Space is reserved for 199 NSAP addresses, IPX addresses, and neutral-interconnect addresses. The 200 remainder of the address space is unassigned for future use. This can 201 be used for expansion of existing use (e.g., additional provider 202 addresses, etc.) or new uses (e.g., separate locators and identifiers). 203 Fifteen percent of the address space is initially allocated. The 204 remaining 85% is reserved for future use. 206 Unicast addresses are distinguished from multicast addresses by the 207 value of the high-order octet of the addresses: a value of FF (11111111) 208 identifies an address as a multicast address; any other value identifies 209 an address as a unicast address. Anycast addresses are taken from the 210 unicast address space, and are not syntactically distinguishable from 211 unicast addresses. 213 2.4 Unicast Addresses 215 The IPv6 unicast address is contiguous bit-wise maskable, similar to 216 IPv4 addresses under Class-less Interdomain Routing [CIDR]. 218 There are several forms of unicast address assignment in IPv6, including 219 the global provider based unicast address, the neutral-interconnect 220 unicast address, the NSAP address, the IPX hierarchical address, the 221 site-local-use address, the link-local-use address, and the IPv4-capable 222 host address. Additional address types can be defined in the future. 224 IPv6 nodes may have considerable or little knowledge of the internal 225 structure of the IPv6 address, depending on the role the node plays (for 226 instance, host versus router). At a minimum, a node may consider that 227 unicast addresses (including its own) have no internal structure: 229 | 128 bits | 230 +-----------------------------------------------------------------+ 231 | node address | 232 +-----------------------------------------------------------------+ 234 A slightly sophisticated host (but still rather simple) may additionally 235 be aware of subnet prefix(es) for the link(s) it is attached to, where 236 different addresses may have different values for n: 238 | n bits | 128-n bits | 239 +------------------------------------------------+----------------+ 240 | subnet prefix | interface ID | 241 +------------------------------------------------+----------------+ 243 Still more sophisticated hosts may be aware of other hierarchical 244 boundaries in the unicast address. Though a very simple router may have 245 no knowledge of the internal structure of IPv6 unicast addresses, 246 routers will more generally have knowledge of one or more of the 247 hierarchical boundaries for the operation of routing protocols. The 248 known boundaries will differ from router to router, depending on what 249 positions the router holds in the routing hierarchy. 251 2.4.1 Unicast Address Examples 253 An example of a Unicast address format which will likely be common on 254 LANs and other environments where IEEE 802 MAC addresses are available 255 is: 257 | n bits | 80-n bits | 48 bits | 258 +--------------------------------+-----------+--------------------+ 259 | subscriber prefix | subnet ID | interface ID | 260 +--------------------------------+-----------+--------------------+ 262 Where the 48-bit Interface ID is an IEEE-802 MAC address. The use of 263 IEEE 802 MAC addresses as a interface ID is expected to be very common 264 in environments where nodes have an IEEE 802 MAC address. In other 265 environments, where IEEE 802 MAC addresses are not available, other 266 types of link layer addresses can be used, such as E.164 addresses, for 267 the interface ID. 269 The inclusion of a unique global interface identifier, such as an IEEE 270 MAC address, makes possible a very simple form of auto-configuration of 271 addresses. A node may discover a subnet ID by listening to Router 272 Advertisement messages sent by a router on its attached link(s), and 273 then fabricating an IPv6 address for itself by using its IEEE MAC 274 address as the interface ID on that subnet. 276 Another unicast address format example is where a site or organization 277 requires additional layers of internal hierarchy. In this example the 278 subnet ID is divided into an area ID and a subnet ID. Its format is: 280 | s bits | n bits | m bits | 128-s-n-m bits | 281 +----------------------+---------+--------------+-----------------+ 282 | subscriber prefix | area ID | subnet ID | interface ID | 283 +----------------------+---------+--------------+-----------------+ 285 This technique can be continued to allow a site or organization to add 286 additional layers of internal hierarchy. It may be desirable to use an 287 interface ID smaller than a 48-bit IEEE 802 MAC address to allow more 288 space for the additional layers of internal hierarchy. These could be 289 interface IDs which are administratively created by the site or 290 organization. 292 2.4.2 The Unspecified Address 294 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It must 295 never be assigned to any node. It indicates the absence of an address. 296 One example of its use is in the Source Address field of any IPv6 297 datagrams sent by an initializing host before it has learned its own 298 address. 300 The unspecified address must not be used as the destination address of 301 IPv6 datagrams or in IPv6 Routing Headers. 303 2.4.3 The Loopback Address 305 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It 306 may be used by a node to send an IPv6 datagram to itself. It may never 307 be assigned to any interface. 309 The loopback address must not be used as the source address in IPv6 310 datagrams that are sent outside of a single node. An IPv6 datagram with 311 a destination address of loopback must never be sent outside of a single 312 node. 314 2.4.4 IPv6 Addresses with Embedded IPv4 Addresses 316 The IPv6 transition mechanisms include a technique for hosts and routers 317 to dynamically tunnel IPv6 packets over IPv4 routing infrastructure. 318 IPv6 nodes that utilize this technique are assigned special IPv6 unicast 319 addresses that carry an IPv4 address in the low-order 32-bits. This 320 type of address is termed an "IPv4-compatible IPv6 address" and has the 321 format: 323 | 80 bits | 16 | 32 bits | 324 +--------------------------------------+--------------------------+ 325 |0000..............................0000|0000| IPv4 address | 326 +--------------------------------------+----+---------------------+ 328 A second type of IPv6 address which holds an embedded IPv4 address is 329 also defined. This address is used to represent the addresses of IPv4- 330 only nodes (those that *do not* support IPv6) as IPv6 addresses. This 331 type of address is termed an "IPv4-mapped IPv6 address" and has the 332 format: 334 | 80 bits | 16 | 32 bits | 335 +--------------------------------------+--------------------------+ 336 |0000..............................0000|FFFF| IPv4 address | 337 +--------------------------------------+----+---------------------+ 339 2.4.5 NSAP Addresses 341 This mapping of NSAP address into IPv6 addresses is as follows: 343 | 7 | 121 bits | 344 +-------+---------------------------------------------------------+ 345 |0000001| to be defined | 346 +-------+---------------------------------------------------------+ 348 The draft definition, motivation, and usage are under study [NSAP]. 350 2.4.6 IPX Addresses 352 This mapping of IPX address into IPv6 addresses is as follows: 354 | 7 | 121 bits | 355 +-------+---------------------------------------------------------+ 356 |0000010| to be defined | 357 +-------+---------------------------------------------------------+ 359 The draft definition, motivation, and usage are under study. 361 2.4.7 Provider-Based Global Unicast Addresses 363 The global provider-based unicast address is assigned as described in 364 [ALLOC] and [ADDRF]. This assignment strategy is similar to assignment 365 of IPv4 addresses under the CIDR scheme [CIDR]. The IPv6 global 366 provider-based unicast address format is as follows: 368 | 125-m-n- | 369 | 3 | n bits | m bits | o bits | p bits | o-p bits | 370 +---+-----------+-----------+-------------+---------+----------+ 371 |010|registry ID|provider ID|subscriber ID|subnet ID| intf. ID | 372 +---+-----------+-----------+-------------+---------+----------+ 374 The high-order part of the address is assigned to registries, who then 375 assign portions of the address space to providers, who then assign 376 portions of the address space to subscribers, etc. 378 The registry ID identifies the registry which assigns the provider 379 portion of the address. The term "registry prefix" refers to the high- 380 order part of the address up to and including the registry ID. 382 The provider ID identifies a specific provider which assigns the 383 subscriber portion of the address. The term "provider prefix" refers to 384 the high-order part of the address up to and including the provider ID. 386 The subscriber ID distinguishes among multiple subscribers attached to 387 the provider identified by the provider ID. The term "subscriber 388 prefix" refers to the high-order part of the address up to and including 389 the subscriber ID. 391 The subnet ID identifies a specific physical link. There can be 392 multiple subnets on the same physical link. A specific subnet can not 393 span multiple physical links. The term "subnet prefix" refers to the 394 high-order part of the address up to and including the subnet ID. The 395 group of nodes identified by the subnet ID must be attached to the same 396 link. 398 The interface ID identifies a single interface among the group of 399 interfaces identified by the subnet prefix. 401 2.4.8 Local-use IPv6 Unicast Addresses 403 There are two types of local-use unicast addresses defined. These are 404 Link-Local and Site-Local. The Link-Local is for use on a single link 405 and the Site-Local is for use in a single site. Link-Local addresses 406 have the following format: 408 | 10 | 409 | bits | n bits | 118-n bits | 410 +----------+-------------------------+----------------------------+ 411 |1111111010| 0 | interface ID | 412 +----------+-------------------------+----------------------------+ 414 Link-Local addresses are designed to be used for addressing on a single 415 link for purposes such as auto-address configuration or when no routers 416 are present. 418 Site-Local addresses have the following format: 420 | 10 | 421 | bits | n bits | m bits | 118-n-m bits | 422 +----------+---------+---------------+----------------------------+ 423 |1111111011| 0 | subnet ID | interface ID | 424 +----------+---------+---------------+----------------------------+ 426 Site-Local addresses may be used for sites or organizations that are not 427 (yet) connected to the global Internet. They do not need to request or 428 "steal" an address prefix from the global Internet address space. IPv6 429 site-local addresses can be used instead. When the organization 430 connects to the global Internet, it can then form global addresses by 431 replacing the site-local prefix with a subscriber prefix. 433 2.5 Anycast Addresses 435 An IPv6 anycast address is an address that is assigned to more than one 436 interface (typically belonging to different nodes), with the property 437 that a packet sent to an anycast address is routed to the "nearest" 438 interface having that address, according to the routing protocols' 439 measure of distance. 441 Anycast addresses are allocated from the unicast address space, using 442 any of the defined unicast address formats. Thus, anycast addresses are 443 syntactically indistinguishable from unicast addresses. When a unicast 444 address is assigned to more than one interface, thus turning it into an 445 anycast address, the nodes to which the address is assigned must be 446 explicitly configured to know that it is an anycast address. 448 For any assigned anycast address, there is a longest address prefix P 449 that identifies the topological region in which all interfaces belonging 450 to that anycast address reside. Within the region identified by P, each 451 member of the anycast set must be advertised as a separate entry in the 452 routing system (commonly referred to as a "host route"); outside the 453 region identified by P, the anycast address may be aggregated into the 454 routing advertisement for prefix P. 456 Note that in, the worst case, the prefix P of an anycast set may be the 457 null prefix, i.e., the members of the set may have no topological 458 locality. In that case, the anycast address must be advertised as a 459 separate routing entry throughout the entire internet, which presents a 460 severe scaling limit on how many such "global" anycast sets may be 461 supported. Therefore, it is expected that support for global anycast 462 sets may be unavailable or very restricted. 464 One expected use of anycast addresses is to identify the set of routers 465 belonging to an internet service provider. Such addresses could be used 466 as intermediate addresses in an IPv6 Routing header, to cause a packet 467 to be delivered via a particular provider or sequence of providers. 468 Some other possible uses are to identify the set of routers attached to 469 a particular subnet, or the set of routers providing entry into a 470 particular routing domain. 472 There is little experience with widespread, arbitrary use of internet 473 anycast addresses, and some known complications and hazards when using 474 them in their full generality [ANYCST]. Until more experience has been 475 gained and solutions agreed upon for those problems, the following 476 restrictions are imposed on IPv6 anycast addresses: 478 o An anycast address MUST NOT be used as the source address of an 479 IPv6 packet. 481 o An anycast address MUST NOT be assigned to an IPv6 host, that is, 482 it may be assigned to an IPv6 router only. 484 2.5.1 Required Anycast Address 486 The Subnet-Router anycast address is predefined. It's format is as 487 follows: 489 | n bits | 128-n bits | 490 +------------------------------------------------+----------------+ 491 | subnet prefix | 00000000000000 | 492 +------------------------------------------------+----------------+ 494 The "subnet prefix" in an anycast address is the prefix which identifies 495 a specific link. This anycast address is syntactically the same as a 496 unicast address for an interface on the link with the interface 497 identifier set to zero. 499 Packets sent to the Subnet-Router anycast address will be delivered to 500 one router on the subnet. All routers are required to support the 501 Subnet-Router anycast addresses for the subnets which they have 502 interfaces. 504 The subnet-router anycast address is intended to be used for 505 applications where a node needs to communicate with one of a set of 506 routers on a remote subnet. For example when a mobile host needs to 507 communicate with one of the mobile agents on it's "home" subnet. 509 2.6 Multicast Addresses 511 An IPv6 multicast address is an identifier for a group of nodes. A node 512 may belong to any number of multicast groups. Multicast addresses have 513 the following format: 515 | 8 | 4 | 4 | 112 bits | 516 +------ -+----+----+---------------------------------------------+ 517 |11111111|flgs|scop| group ID | 518 +--------+----+----+---------------------------------------------+ 520 11111111 at the start of the address identifies the address as 521 being a multicast address. 523 +-+-+-+-+ 524 flgs is a set of 4 flags: |0|0|0|T| 525 +-+-+-+-+ 527 The high-order 3 flags are reserved, and must be initialized 528 to 0. 530 T = 0 indicates a permanently-assigned ("well-known") 531 multicast address, assigned by the global internet numbering 532 authority. 534 T = 1 indicates a non-permanently-assigned ("transient") 535 multicast address. 537 scop is a 4-bit multicast scope value used to limit the scope of 538 the multicast group. The values are: 540 0 reserved 541 1 node-local scope 542 2 link-local scope 543 3 (unassigned) 544 4 (unassigned) 545 5 site-local scope 546 6 (unassigned) 547 7 (unassigned) 548 8 organization-local scope 549 9 (unassigned) 550 A (unassigned) 551 B (unassigned) 552 C (unassigned) 553 D (unassigned) 554 E global scope 555 F reserved 557 group ID identifies the multicast group, either permanent or 558 transient, within the given scope. 560 The "meaning" of a permanently-assigned multicast address is independent 561 of the scope value. For example, if the "NTP servers group" is assigned 562 a permanent multicast address with a group ID of 43 (hex), then: 564 FF01:0:0:0:0:0:0:43 means all NTP servers on the same node as the 565 sender. 567 FF02:0:0:0:0:0:0:43 means all NTP servers on the same link as the 568 sender. 570 FF05:0:0:0:0:0:0:43 means all NTP servers at the same site as the 571 sender. 573 FF0E:0:0:0:0:0:0:43 means all NTP servers in the internet. 575 Non-permanently-assigned multicast addresses are meaningful only within 576 a given scope. For example, a group identified by the non-permanent, 577 site-local multicast address FF15:0:0:0:0:0:0:43 at one site bears no 578 relationship to a group using the same address at a different site, nor 579 to a non-permanent group using the same group ID with different scope, 580 nor to a permanent group with the same group ID. 582 Multicast addresses must not be used as source addresses in IPv6 583 datagrams or appear in any routing header. 585 2.6.1 Pre-Defined Multicast Addresses 587 The following well-known multicast addresses are pre-defined: 589 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 590 FF01:0:0:0:0:0:0:0 591 FF02:0:0:0:0:0:0:0 592 FF03:0:0:0:0:0:0:0 593 FF04:0:0:0:0:0:0:0 594 FF05:0:0:0:0:0:0:0 595 FF06:0:0:0:0:0:0:0 596 FF07:0:0:0:0:0:0:0 597 FF08:0:0:0:0:0:0:0 598 FF09:0:0:0:0:0:0:0 599 FF0A:0:0:0:0:0:0:0 600 FF0B:0:0:0:0:0:0:0 601 FF0C:0:0:0:0:0:0:0 602 FF0D:0:0:0:0:0:0:0 603 FF0E:0:0:0:0:0:0:0 604 FF0F:0:0:0:0:0:0:0 606 The above multicast addresses are reserved and shall never be assigned 607 to any multicast group. 609 All Nodes Addresses: FF01:0:0:0:0:0:0:1 610 FF02:0:0:0:0:0:0:1 612 The above multicast addresses identify the group of all IPv6 nodes, 613 within scope 1 (node-local) or 2 (link-local). 615 All Routers Addresses: FF01:0:0:0:0:0:0:2 616 FF02:0:0:0:0:0:0:2 618 The above multicast addresses identify the group of all IPv6 routers, 619 within scope 1 (node-local) or 2 (link-local). 621 All Hosts Addresses: FF01:0:0:0:0:0:0:3 622 FF02:0:0:0:0:0:0:3 624 The above multicast addresses identify the group of all IPv6 hosts, 625 within scope 1 (node-local) or 2 (link-local). 627 2.7 A Node's Required Addresses 629 A host is required to recognize the following addresses as identifying 630 itself: 632 o Assigned Unicast Addresses 633 o Loopback Address 634 o All Nodes Multicast Address 635 o All Hosts Multicast Address 636 o All other Multicast Addresses to which the host belongs. 638 A router is required to recognize the following addresses as identifying 639 itself: 641 o Assigned Unicast Addresses 642 o Loopback Address 643 o The Subnet-Router anycast addresses for the links it has 644 interfaces. 645 o All other Anycast addresses with which the router has been 646 configured. 647 o All Nodes Multicast Address 648 o All Router Multicast Address 649 o All other Multicast Addresses to which the router belongs. 651 The only address-prefixes which should be predefined in an 652 implementation are the: 654 o Unspecified Address 655 o Loopback Address 656 o Multicast Prefix (FF) 657 o Local Use Prefixes (Link-Local and Site-Local) 658 o Pre-Defined Multicast Addresses 659 o IPv4 Compatible Prefixes 661 Implementations should assume all other addresses are unicast unless 662 specifically configured (e.g., anycast addresses). 664 REFERENCES 666 [ADDRF] Rekhter, Y., Lothberg, P., "An IPv6 Global Unicast Address 667 Format", Internet Draft. 669 [ALLOC] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast Address 670 Allocation", Internet Draft. 672 [ANYCST]C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting 673 Service", RFC-1546, November 1993. 675 [CIDR] V. Fuller, T. Li, K. Varadhan, J. Yu, "Supernetting: an 676 Address Assignment and Aggregation Strategy", RFC 1338. 678 [IPV6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 679 (IPv6) Specification", Internet Draft. 681 [MULT] S. Deering, "Host Extensions for IP multicasting", RFC 1112. 683 [NSAP] B.Carpenter, Editor, "Mechanisms for OSI NSAPs, CLNP and TP 684 over IPv6", Internet Draft. 686 DOCUMENT EDITOR'S ADDRESS 688 Robert M. Hinden Stephen E. Deering 689 Ipsilon Networks, Inc. Xerox Palo Alto Research Center 690 2465 Latham Street, Suite 100 3333 Coyote Hill Road 691 Mt. View, CA 94040 Palo Alto, CA 94304 692 USA USA 694 phone: +1 415 528 4604 phone: +1 415 812 4839 695 fax: +1 415 528 4653 fax: +1 415 812 4471 696 email: hinden@ipsilon.com email: deering@parc.xerox.com 698 APPENDIX 700 This version of the "IPv6 Addressing Architecture" includes several 701 changes from the previous version: 703 705 dated March 27, 1995. These changes are: 707 o Added definition of Subnet-Router anycast address for use by 708 neighbor discovery and auto-addressing. 710 o Removed Community scop from multicast scop definitions. 712 o Added Local Use Prefixes (Link-Local and Site-Local) to list 713 of predefined prefixes that an implementation is required to 714 know. 716 o Minor clarifications, corrections, and typos fixed. 718 o New typos likely added.