idnits 2.17.1 draft-ietf-ipngwg-addr-arch-01.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-24) 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 476: '... anycast address MUST NOT be used as t...' RFC 2119 keyword, line 479: '... 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 472, but not defined == Unused Reference: 'MULT' is defined on line 650, 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 March 27, 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 October 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 need for point-to-point interfaces on routers if 94 those interfaces are not to be used as the origins or destinations 95 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 address containing zero bits easier 120 a special syntax is available to compress the zeros. The use of 121 two "::" indicate multiple groups of 16-bits of zeros. For example 122 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 addresses 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 | m 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 General 272 Advertisement messages send by a router on its attached link(s), and 273 then fabricating a IPv6 address for itself by using its IEEE MAC address 274 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 a 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. 312 2.4.4 IPv6 Addresses with Embedded IPv4 Addresses 314 The IPv6 transition mechanisms include a technique for hosts and routers 315 to dynamically tunnel IPv6 packets over IPv4 routing infrastructure. 316 IPv6 nodes that utilize this technique are assigned special IPv6 unicast 317 addresses that carry an IPv4 address in the low-order 32-bits. This 318 type of address is termed an "IPv4-compatible IPv6 address" and has the 319 format: 321 | 80 bits | 16 | 32 bits | 322 +--------------------------------------+--------------------------+ 323 |0000..............................0000|0000| IPv4 address | 324 +--------------------------------------+----+---------------------+ 326 A second type of IPv6 address which holds an embedded IPv4 address is 327 also defined. This address is used to represent the addresses of IPv4- 328 only nodes (those that *do not* support IPv6) as IPv6 addresses. This 329 type of address is termed an "IPv4-mapped IPv6 address" and has the 330 format: 332 | 80 bits | 16 | 32 bits | 333 +--------------------------------------+--------------------------+ 334 |0000..............................0000|FFFF| IPv4 address | 335 +--------------------------------------+----+---------------------+ 337 2.4.5 NSAP Addresses 339 This mapping of NSAP address into IPv6 addresses is as follows: 341 | 7 | 121 bits | 342 +-------+---------------------------------------------------------+ 343 |0000001| to be defined | 344 +-------+---------------------------------------------------------+ 346 The draft definition, motivation, and usage are under study [NSAP]. 348 2.4.6 IPX Addresses 350 This mapping of IPX address into IPv6 addresses is as follows: 352 | 7 | 121 bits | 353 +-------+---------------------------------------------------------+ 354 |0000010| to be defined | 355 +-------+---------------------------------------------------------+ 357 The draft definition, motivation, and usage are under study. 359 2.4.7 Provider-Based Global Unicast Addresses 361 The global provider-based unicast address is assigned as described in 362 [ALLOC] and [ADDRF]. This assignment strategy is similar to assignment 363 of IPv4 addresses under the CIDR scheme [CIDR]. The IPv6 global 364 provider-based unicast address format is as follows: 366 | 125-m-n- | 367 | 3 | n bits | m bits | o bits | p bits | o-p bits | 368 +---+-----------+-----------+-------------+---------+----------+ 369 |010|registry ID|provider ID|subscriber ID|subnet ID| intf. ID | 370 +---+-----------+-----------+-------------+---------+----------+ 372 The high-order part of the address is assigned to registries, who then 373 assign portions of the address space to providers, who then assign 374 portions of the address space to subscribers, etc. 376 The registry ID identifies the registry which assigns the provider 377 portion of the address. The term "registry prefix" refers to the high- 378 order part of the address up to and including the registry ID. 380 The provider ID identifies a specific provider which assigns the 381 subscriber portion of the address. The term "provider prefix" refers to 382 the high-order part of the address up to and including the provider ID. 384 The subscriber ID distinguishes among multiple subscribers attached to 385 the provider identified by the provider ID. The term "subscriber 386 prefix" refers to the high-order part of the address up to and including 387 the subscriber ID. 389 The subnet ID identifies a specific physical link. There can be 390 multiple subnets on the same physical link. A specific subnet can not 391 span multiple physical links. The term "subnet prefix" refers to the 392 high-order part of the address up to and including the subnet ID. The 393 group of nodes identified by the subnet ID must be attached to the same 394 link. 396 The interface ID identifies a single interface among the group of 397 interfaces identified by the subnet prefix. 399 2.4.8 Local-use IPv6 Unicast Addresses 401 There are two types of local-use unicast addresses defined. These are 402 Link-Local and Site-Local. The Link-Local is for use on a single link 403 and the Site-Local is for use in a single site. Link-Local addresses 404 have the following format: 406 | 10 | 407 | bits | n bits | 118-n bits | 408 +----------+-------------------------+----------------------------+ 409 |1111111010| 0 | interface ID | 410 +----------+-------------------------+----------------------------+ 412 Link-Local addresses are designed to be used for addressing on a single 413 link for purposes such as auto-address configuration or when no routers 414 are present. 416 Site-Local addresses have the following format: 418 | 10 | 419 | bits | n bits | m bits | 118-n-m bits | 420 +----------+---------+---------------+----------------------------+ 421 |1111111011| 0 | subnet ID | interface ID | 422 +----------+---------+---------------+----------------------------+ 424 Site-Local addresses may be used for sites or organizations that are not 425 (yet) connected to the global Internet. They do not need to request or 426 "steal" an address prefix from the global Internet address space. IPv6 427 site-local addresses can be used instead. When the organization 428 connects to the global Internet, it can then form global addresses by 429 replacing the site-local prefix with a subscriber prefix. 431 2.5 Anycast Addresses 433 An IPv6 anycast address is an address that is assigned to more than one 434 interface (typically belonging to different nodes), with the property 435 that a packet sent to an anycast address is routed to the nearest 436 interface having that address, according to the routing protocols' 437 measure of distance. 439 Anycast addresses are allocated from the unicast address space, using 440 any of the defined unicast address formats. Thus, anycast addresses are 441 syntactically indistinguishable from unicast addresses. When a unicast 442 address is assigned to more than one interface, thus turning it into an 443 anycast address, the nodes to which the address is assigned must be 444 explicitly configured to know that it is an anycast address. 446 For any assigned anycast address, there is a longest address prefix P 447 that identifies the topological region in which all interfaces belonging 448 to that anycast address reside. Within the region identified by P, each 449 member of the anycast set must be advertised as a separate entry in the 450 routing system (commonly referred to as a "host route"); outside the 451 region identified by P, the anycast address may be aggregated into the 452 routing advertisement for prefix P. 454 Note that in, the worst case, the prefix P of an anycast set may be the 455 null prefix, i.e., the members of the set may have no topological 456 locality. In that case, the anycast address must be advertised as a 457 separate routing entry throughout the entire internet, which presents a 458 severe scaling limit on how many such "global" anycast sets may be 459 supported. Therefore, it is expected that support for global anycast 460 sets may be unavailable or very restricted. 462 One expected use of anycast addresses is to identify the set of routers 463 belonging to an internet service provider. Such addresses could be used 464 as intermediate addresses in an IPv6 Routing header, to cause a packet 465 to be delivered via a particular provider or sequence of providers. 466 Some other possible uses are to identify the set of routers attached to 467 a particular subnet, or the set of routers providing entry into a 468 particular routing domain. 470 There is little experience with widespread, arbitrary use of internet 471 anycast addresses, and some known complications and hazards when using 472 them in their full generality [ANYCST]. Until more experience has been 473 gained and solutions agreed upon for those problems, the following 474 restrictions are imposed on IPv6 anycast addresses: 476 o An anycast address MUST NOT be used as the source address of an 477 IPv6 packet. 479 o An anycast address MUST NOT be assigned to an IPv6 host, that is, 480 it may be assigned to an IPv6 router only. 482 2.6 Multicast Addresses 484 A IPv6 multicast address is an identifier for a group of nodes. A node 485 may belong to any number of multicast groups. Multicast addresses have 486 the following format: 488 | 8 | 4 | 4 | 112 bits | 489 +------ -+----+----+---------------------------------------------+ 490 |11111111|flgs|scop| group ID | 491 +--------+----+----+---------------------------------------------+ 493 11111111 at the start of the address identifies the address as 494 being a multicast address. 496 +-+-+-+-+ 497 flgs is a set of 4 flags: |0|0|0|T| 498 +-+-+-+-+ 500 The high-order 3 flags are reserved, and must be initialized 501 to 0. 503 T = 0 indicates a permanently-assigned ("well-known") 504 multicast address, assigned by the global internet numbering 505 authority. 507 T = 1 indicates a non-permanently-assigned ("transient") 508 multicast address. 510 scop is a 4-bit multicast scope value used to limit the scope of 511 the multicast group. The values are: 513 0 reserved 514 1 node-local scope 515 2 link-local scope 516 3 (unassigned) 517 4 (unassigned) 518 5 site-local scope 519 6 (unassigned) 520 7 (unassigned) 521 8 organization-local scope 522 9 (unassigned) 523 A (unassigned) 524 B community-local scope 525 C (unassigned) 526 D (unassigned) 527 E global scope 528 F reserved 530 group ID identifies the multicast group, either permanent or 531 transient, within the given scope. 533 The "meaning" of a permanently-assigned multicast address is independent 534 of the scope value. For example, if the "NTP servers group" is assigned 535 a permanent multicast address with a group ID of 43 (hex), then: 537 FF01:0:0:0:0:0:0:43 means all NTP servers on the same node as the 538 sender. 540 FF02:0:0:0:0:0:0:43 means all NTP servers on the same link as the 541 sender. 543 FF05:0:0:0:0:0:0:43 means all NTP servers at the same site as the 544 sender. 546 FF0E:0:0:0:0:0:0:43 means all NTP servers in the internet. 548 Non-permanently-assigned multicast addresses are meaningful only within 549 a given scope. For example, a group identified by the non-permanent, 550 site-local multicast address FF15:0:0:0:0:0:0:43 at one site bears no 551 relationship to a group using the same address at a different site, nor 552 to a non-permanent group using the same group ID with different scope, 553 nor to a permanent group with the same group ID. 555 Multicast addresses must not be used as source addresses in IPv6 556 datagrams or appear in any routing header. 558 2.6.1 Pre-Defined Multicast Addresses 560 The following well-known multicast addresses are pre-defined: 562 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 563 FF01:0:0:0:0:0:0:0 564 FF02:0:0:0:0:0:0:0 565 FF03:0:0:0:0:0:0:0 566 FF04:0:0:0:0:0:0:0 567 FF05:0:0:0:0:0:0:0 568 FF06:0:0:0:0:0:0:0 569 FF07:0:0:0:0:0:0:0 570 FF08:0:0:0:0:0:0:0 571 FF09:0:0:0:0:0:0:0 572 FF0A:0:0:0:0:0:0:0 573 FF0B:0:0:0:0:0:0:0 574 FF0C:0:0:0:0:0:0:0 575 FF0D:0:0:0:0:0:0:0 576 FF0E:0:0:0:0:0:0:0 577 FF0F:0:0:0:0:0:0:0 579 The above multicast addresses are reserved and shall never be assigned 580 to any multicast group. 582 All Nodes Addresses: FF01:0:0:0:0:0:0:1 583 FF02:0:0:0:0:0:0:1 585 The above multicast addresses identify the group of all IPv6 nodes, 586 within scope 1 (node-local) or 2 (link-local). 588 All Routers Addresses: FF01:0:0:0:0:0:0:2 589 FF02:0:0:0:0:0:0:2 591 The above multicast addresses identify the group of all IPv6 routers, 592 within scope 1 (node-local) or 2 (link-local). 594 All Hosts Addresses: FF01:0:0:0:0:0:0:3 595 FF02:0:0:0:0:0:0:3 597 The above multicast addresses identify the group of all IPv6 hosts, 598 within scope 1 (node-local) or 2 (link-local). 600 2.7 A Node's Required Addresses 602 A host is required to recognize the following addresses as identifying 603 itself: 605 o Assigned Unicast Addresses 606 o Loopback Address 607 o All Nodes Multicast Address 608 o All Hosts Multicast Address 609 o All other Multicast Addresses to which the host belongs. 611 A router is required to recognize the following addresses as identifying 612 itself: 614 o Assigned Unicast Addresses 615 o Loopback Address 616 o All anycast addresses with which the router has been configured. 617 o All Nodes Multicast Address 618 o All Router Multicast Address 619 o All other Multicast Addresses to which the router belongs. 621 The only address-prefixes which should be predefined in an 622 implementation are the: 624 o Unspecified Address 625 o Loopback Address 626 o Multicast prefix (FF) 627 o Pre-Defined Multicast Addresses 628 o IPv4 Compatible Prefixes 630 Implementations should assume all other addresses are unicast unless 631 specifically configured (e.g., anycast addresses). 633 REFERENCES 635 [ADDRF] Rekhter, Y., Lothberg, P., "An IPv6 Global Unicast Address 636 Format", Internet Draft 638 [ALLOC] Rekhter, Y., Li, T., "An Architecture for IPv6 Unicast Address 639 Allocation", Internet Draft 641 [ANYCST]C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting 642 Service", RFC-1546, November 1993. 644 [CIDR] V. Fuller, T. Li, K. Varadhan, J. Yu, "Supernetting: an 645 Address Assignment and Aggregation Strategy", RFC 1338. 647 [IPV6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 648 (IPv6) Specification", Internet Draft. 650 [MULT] S. Deering, "Host Extensions for IP multicasting", RFC 1112. 652 [NSAP] B.Carpenter, Editor, "Mechanisms for OSI NSAPs, CLNP and TP 653 over IPv6", Internet Draft. 655 DOCUMENT EDITOR'S ADDRESS 657 Robert M. Hinden Stephen E. Deering 658 Ipsilon Networks, Inc. Xerox Palo Alto Research Center 659 2465 Latham Street, Suite 100 3333 Coyote Hill Road 660 Mt. View, CA 94040 Palo Alto, CA 94304 661 USA USA 663 phone: +1 415 528 4604 phone: +1 415 812 4839 664 fax: +1 415 528 4653 fax: +1 415 812 4471 665 email: hinden@ipsilon.com email: deering@parc.xerox.com 667 APPENDIX 669 Changes from Previous Version 671 This version of the "IPv6 Addressing Architecture" includes the 672 following changes made since the previous version: 674 o Region addresses replace by Anycast addresses. 676 o Reduced references to other documents. 678 o Reordered the unicast sections of the document. 680 o Changed Multicast All Routers and All Hosts to be consistent 681 with IPv4 multicast assignment. 683 o Minor clarification's, corrections, and typos fixed. 685 o New typos likely added.