idnits 2.17.1 draft-ietf-ipngwg-addr-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-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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 are 15 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 457: '...Region addresses MUST NOT be used as a...' 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.) -- The document date (March 9, 1995) is 10640 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ICMP' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'MULT' is defined on line 678, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASSN' -- Possible downref: Non-RFC (?) normative reference: ref. 'AUTO' ** Obsolete normative reference: RFC 1338 (ref. 'CIDR') (Obsoleted by RFC 1519) -- Possible downref: Non-RFC (?) normative reference: ref. 'DISC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ICMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPV6' -- Possible downref: Non-RFC (?) normative reference: ref. 'NSAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF' -- Possible downref: Non-RFC (?) normative reference: ref. 'TMV6' Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 R. Hinden, Editor 2 Ipsilon Networks, Inc. 3 March 9, 1995 5 IP Version 6 Addressing Architecture 6 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 1, 1995. 28 1.0 INTRODUCTION 30 This specification defines the addressing architecture of the IP Version 31 6 protocol. It includes a detailed description of the address formats 32 for IPv6 [IPV6]. 34 The document editor would like to acknowledge the contributions of Paul 35 Francis, Steve Deering, Jim Bound, Brian Carpenter, Bob Gilligan, 36 Christian Huitema, Greg Minshall, Erik Nordmark, Bill Simpson, and Sue 37 Thomson. Special mention is also given to Yakov Rekhtor, Tony Li, 38 Deborah Estrin, and Peter Ford for the current definition of region 39 addresses. 41 2.0 IPv6 ADDRESSING 43 IPv6 addresses are 128-bit identifiers for interfaces and sets of 44 interfaces. There are three types of addresses: 46 Unicast: Identifier for a single interface. Packets sent to a 47 unicast address are delivered to the interface identified 48 by that address. 50 Region: Identifier for a set of interfaces on the border of a 51 region. Packets sent to a region address are delivered 52 to one interface in that region. 54 Multicast: Identifier for a set of interfaces (typically belonging 55 to different nodes). Packets sent to a multicast address 56 are delivered to all interfaces identified by that 57 multicast address. 59 There are no broadcast addresses in IPv6, their function being 60 superseded by multicast addresses. 62 In this document, fields in addresses are given a specific name, for 63 example "subscriber". When this name is used with the term "ID" for 64 identifier after the name (e.g., "subscriber ID"), it refers to the 65 contents of the named field. When it is used with the term "prefix" 66 (e.g. "subscriber prefix") it refers to all of the address up to and 67 including this field. 69 In IPv6, all zeros and all ones are legal values for any field, unless 70 specifically excluded. Specifically, prefixes may contain zero-valued 71 fields or end in zeros. 73 2.1 Addressing Model 75 IPv6 Addresses of all types are assigned to interfaces, not nodes. 76 Since each interface belongs to a single node, any of that node's 77 interfaces' unicast addresses may be used as an identifier for the node. 79 An IPv6 unicast address refers to a single interface. A single 80 interface may be assigned multiple IPv6 addresses of any type (unicast, 81 region, and multicast). There are two exceptions to this model. These 82 are: 84 1) A single address may be assigned to multiple physical interfaces if 85 the implementation treats the multiple physical interfaces as one 86 interface when presenting it to the internet layer. This is useful 87 for load-sharing over multiple physical interfaces. 89 2) Routers may have unnumbered interfaces (i.e., no IPv6 address 90 assigned to the interface) on point-to-point links to eliminate the 91 necessity to manually configure and advertise the addresses. 92 Addresses are not need for point-to-point interfaces on routers if 93 those interfaces are not to be used as the origins or destinations 94 of any IPv6 datagrams. 96 IPv6 continues the IPv4 model that a subnet is associated with one link. 97 Multiple subnets may be assigned to the same link. 99 2.2 Text Representation of Addresses 101 There are three conventional forms for representing IPv6 addresses as 102 text strings: 104 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the 105 hexadecimal values of the eight 16-bit pieces of the address. 106 Examples: 108 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 110 1080:0:0:8:800:200C:417A 112 Note that it is not necessary to write the leading zeros in an 113 individual field, but there must be at least one numeral in every 114 field (except for the case described in 2.). 116 2. Due to the method of allocating certain styles of IPv6 addresses, 117 it will be common for addresses to contain long strings of zero 118 bits. In order to make writing address containing zero bits easier 119 a special syntax is available to compress the zeros. The use of 120 two "::" indicate multiple groups of 16-bits of zeros. For example 121 the multicast address: 123 FF01:0:0:0:0:0:0:43 125 may be represented as: 127 FF01::43 129 The "::" can only appear once in an address. The "::" can also be 130 used to compress the leading or trailing zeros in an address. 132 3. An alternative form that is sometimes more convenient when dealing 133 with a mixed environment of IPv4 and IPv6 nodes is 134 x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of 135 the six high-order 16-bit pieces of the address, and the 'd's are 136 the decimal values of the four low-order 8-bit pieces of the 137 address (standard IPv4 representation). Examples: 139 0:0:0:0:0:0:0:13.1.68.3 141 0:0:0:0:0:0:FFFF:129.144.52.38 143 or in compressed form: 145 ::13.1.68.3 147 ::FFFF:129.144.52.38 149 2.3 Address Type Representation 151 The specific type of an IPv6 address is indicated by the leading bits in 152 the address. The variable-length field comprising these leading bits is 153 called the Format Prefix (FP). The initial allocation of these prefixes 154 is as follows: 156 Allocation Prefix Fraction of 157 (binary) Address Space 158 ------------------------------- -------- ------------- 159 Reserved 0000 0000 1/256 160 Reserved 0000 0001 1/256 162 NSAP Allocation 0000 001 1/128 163 IPX Allocation 0000 010 1/128 165 Reserved 0000 011 1/128 166 Reserved 0000 1 1/32 167 Reserved 0001 1/16 168 Reserved 001 1/8 170 Provider-Based Unicast Address 010 1/8 172 Reserved 011 1/8 174 Reserved for Neutral-Interconnect- 175 Based Unicast Addresses 100 1/8 177 Reserved 101 1/8 178 Reserved 110 1/8 179 Reserved 1110 1/16 180 Reserved 1111 0 1/32 181 Reserved 1111 10 1/64 182 Reserved 1111 110 1/128 184 Reserved 1111 1110 0 1/512 186 Link Local Use Addresses 1111 1110 10 1/1024 187 Site Local Use Addresses 1111 1110 11 1/1024 189 Multicast Addresses 1111 1111 1/256 191 Note: IPv6 Addresses with Embedded IPv4 Addresses (see section 192 2.4.7), the "unspecified address" (see section 2.4.5), and the 193 loopback address (see section 2.4.6), are assigned out of the 0000 194 0000 format prefix space. 196 This allocation supports the direct allocation of provider addresses, 197 NSAP addresses, IPX addresses, local use addresses, and multicast 198 addresses. Space is reserved for neutral-interconnect addresses. The 199 remainder of the address space is reserved for future use. This can be 200 used for expansion of existing use (e.g., additional provider addresses, 201 IPX addresses, etc.) or new uses (e.g., separate locators and 202 identifiers). Fifteen percent of the address space is initially 203 allocated. The remaining 85% is reserved for future use. 205 Unicast addresses are distinguished from multicast addresses by the 206 value of the high-order octet of the addresses: a value of FF (11111111) 207 identifies an address as a multicast address; any other value identifies 208 an address as a unicast address. Region addresses are taken from the 209 unicast address space, and are not syntactically distinguishable from 210 unicast addresses. 212 2.4 Unicast Addresses 214 The IPv6 unicast address is contiguous bit-wise maskable, similar to 215 IPv4 addresses under Class-less Interdomain Routing [CIDR]. 217 There are several forms of unicast address assignment in IPv6, including 218 the global provider based unicast address, the neutral-interconnect 219 unicast address, the NSAP address, the IPX hierarchical address, the 220 site-local-use address, the link-local-use address, and the IPv4-capable 221 host address. Additional addresses types can be defined in the future. 223 IPv6 nodes may have considerable or little knowledge of the internal 224 structure of the IPv6 address, depending on the role the node plays (for 225 instance, host versus router). At a minimum, a node may consider that 226 unicast addresses (including its own) have no internal structure: 228 | 128 bits | 229 +-----------------------------------------------------------------+ 230 | node address | 231 +-----------------------------------------------------------------+ 233 A slightly sophisticated host (but still rather simple) may additionally 234 be aware of subnet prefix(es) for the link(s) it is attached to, where 235 different addresses may have different values for n: 237 | n bits | 128-n bits | 238 +------------------------------------------------+----------------+ 239 | subnet prefix | interface ID | 240 +------------------------------------------------+----------------+ 242 Still more sophisticated hosts may be aware of other hierarchical 243 boundaries in the unicast address. Though a very simple router may have 244 no knowledge of the internal structure of IPv6 unicast addresses, 245 routers will more generally have knowledge of one or more of the 246 hierarchical boundaries for the operation of routing protocols. The 247 known boundaries will differ from router to router, depending on what 248 positions the router holds in the routing hierarchy. 250 2.4.1 Unicast Address Examples 252 An example of a Unicast address format which will likely to be common on 253 LANs and other environments where IEEE 802 MAC addresses are available 254 is: 256 | n bits | m bits | 48 bits | 257 +--------------------------------+-----------+--------------------+ 258 | subscriber prefix | subnet ID | interface ID | 259 +--------------------------------+-----------+--------------------+ 261 Where the 48-bit Interface ID is an IEEE-802 MAC address. The use of 262 IEEE 802 MAC addresses as a interface ID is expected to be very common 263 in environments where nodes have an IEEE 802 MAC address. In other 264 environments, where IEEE 802 MAC addresses are not available, other 265 types of link layer addresses can be used, such as E.164 addresses, for 266 the interface ID. 268 The inclusion of a unique global interface identifier, such as an IEEE 269 MAC address, makes possible a very simple form of auto-configuration of 270 addresses. A node may discover a subnet ID by listening to General 271 Advertisement messages send by a router on its attached link(s), and 272 then fabricating a IPv6 address for itself by using its IEEE MAC address 273 as the interface ID on that subnet. The details of host auto- 274 configuration are described in [AUTO] and [DISC]. 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 a 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 Provider-Based Global Unicast Addresses 294 The global provider-based unicast address is assigned as described in 295 [ASSN]. This assignment strategy is similar to assignment of IPv4 296 addresses under the CIDR scheme [CIDR]. The IPv6 global provider-based 297 unicast address format is as follows: 299 | 125-m-n- | 300 | 3 | n bits | m bits | o bits | p bits | o-p bits | 301 +---+-----------+-----------+-------------+---------+----------+ 302 |010|registry ID|provider ID|subscriber ID|subnet ID| intf. ID | 303 +---+-----------+-----------+-------------+---------+----------+ 305 The high-order part of the address is assigned to registries, who then 306 assign portions of the address space to providers, who then assign 307 portions of the address space to subscribers, etc. 309 The registry ID identifies the registry which assigns the provider 310 portion of the address. The term "registry prefix" refers to the high- 311 order part of the address up to and including the registry ID. 313 The provider ID identifies a specific provider which assigns the 314 subscriber portion of the address. The term "provider prefix" refers to 315 the high-order part of the address up to and including the provider ID. 317 The subscriber ID distinguishes among multiple subscribers attached to 318 the provider identified by the provider ID. The term "subscriber 319 prefix" refers to the high-order part of the address up to and including 320 the subscriber ID. 322 The subnet ID identifies a specific physical link. There can be 323 multiple subnets on the same physical link. A specific subnet can not 324 span multiple physical links. The term "subnet prefix" refers to the 325 high-order part of the address up to and including the subnet ID. The 326 group of nodes identified by the subnet ID must be attached to the same 327 link. 329 The interface ID identifies a single interface among the group of 330 interfaces identified by the subnet prefix. 332 2.4.3 NSAP Addresses 334 This mapping of NSAP address into IPv6 addresses is as follows: 336 | 7 |1| 4 | 12 | 32 bits | 16 bits| 48 bits | 337 +-------+-+-----+-------+------------+--------+-------------------+ 338 |0000001|G| AFC | IDI | Prefix | Area | ID | 339 +-------+-+-----+-------+------------+--------+-------------------+ 341 The complete definition, motivation, and usage can be found in [NSAP]. 343 2.4.4 Local-use IPv6 Unicast Addresses 345 There are two types of local-use unicast addresses defined. These are 346 Link-Local and Site-Local. The Link-Local is for use on a single link 347 and the Site-Local is for use in a single site. Link-Local addresses 348 have the following format: 350 | 10 | 351 | bits | n bits | 118-n bits | 352 +----------+-------------------------+----------------------------+ 353 |1111111010| 0 | interface ID | 354 +----------+-------------------------+----------------------------+ 356 Link-Local addresses are designed to be used for addressing on a single 357 link for purposes such as auto-address configuration or when no routers 358 are present. 360 Site-Local addresses have the following format: 362 | 10 | 363 | bits | n bits | m bits | 118-n-m bits | 364 +----------+---------+---------------+----------------------------+ 365 |1111111011| 0 | subnet ID | interface ID | 366 +----------+---------+---------------+----------------------------+ 368 Site-Local addresses may be used for sites or organizations that are not 369 (yet) connected to the global Internet. They do not need to request or 370 "steal" an address prefix from the global Internet address space. IPv6 371 site-local addresses can be used instead. When the organization 372 connects to the global Internet, it can then form global addresses by 373 replacing the site-local prefix with a subscriber prefix. 375 2.4.5 The Unspecified Address 377 The address 0:0:0:0:0:0:0:0 is called the unspecified address. It must 378 never be assigned to any node. It indicates the absence of an address. 380 One example of its use is in the Source Address field of any IPv6 381 datagrams sent by an initializing host before it has learned its own 382 address. 384 The unspecified address must not be used as the destination address of 385 IPv6 datagrams or in IPv6 Routing Headers. 387 2.4.6 The Loopback Address 389 The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. It 390 may be used by a node to send a IPv6 datagram to itself. It may never 391 be assigned to any interface. 393 The loopback address must not be used as the source address in IPv6 394 datagrams that are sent outside of a single node. 396 2.4.7 IPv6 Addresses with Embedded IPv4 Addresses 398 The IPv6 transition mechanisms [TMV6] include a technique for hosts and 399 routers to dynamically tunnel IPv6 packets over IPv4 routing 400 infrastructure. IPv6 nodes that utilize this technique are assigned 401 special IPv6 unicast addresses that carry an IPv4 address in the low- 402 order 32-bits. This type of address is termed an "IPv4-compatible IPv6 403 address" and has the format: 405 | 80 bits | 16 | 32 bits | 406 +--------------------------------------+--------------------------+ 407 |0000..............................0000|0000| IPv4 address | 408 +--------------------------------------+----+---------------------+ 410 A second type of IPv6 address which holds an embedded IPv4 address is 411 also defined. This address is used to represent the addresses of IPv4- 412 only nodes (those that *do not* support IPv6) as IPv6 addresses. This 413 type of address is termed an "IPv4-mapped IPv6 address" and has the 414 format: 416 | 80 bits | 16 | 32 bits | 417 +--------------------------------------+--------------------------+ 418 |0000..............................0000|FFFF| IPv4 address | 419 +--------------------------------------+----+---------------------+ 421 2.5 Region Addresses 423 Region Addresses provide information abstraction for the purpose of 424 network layer routing. A subgraph of an internet forms a "Region" with 425 an identifier called a "Region-ID" if all the following conditions are 426 satisfied. 428 1. Associated with each Region is a globally unique identifier called 429 a Region-ID. Syntactically, a Region-ID is a 128-bit IPv6 unicast 430 address. 432 2. There is an address administration (at least one, but maybe 433 several) that is responsible for unicast address allocation for all 434 the nodes within the subgraph. A Region-ID is assigned by one such 435 administration out of the unicast address block used by the 436 administration for unicast address allocation within the subgraph. 438 3. All the routers in the Region that connect the subgraph (or its 439 connected components) with the rest of the internet are called 440 "Border Routers". These Region Border Routers (or just Border 441 Routers) are preconfigured with the Region-ID. The configuration 442 procedures are outside the scope of the definition. 444 4. At least some of a Region's Border Routers advertise into the 445 Region's routing system a prefix that matches (in the sense of the 446 "longest match" algorithm) the Region's Region-ID. In addition, a 447 Region's Border Router may advertise into the routing system a 448 prefix equal to the Region-ID only (i.e., a host route). 450 5. If Region-IDs are used to specify transit policies (i.e., specify 451 that a packet should pass through at least one node in a Region 452 identified by a particular Region Identifier), in order to enforce 453 strict source routes, the Region Border Router must know the 454 Region-IDs of all other routers that share a common link with the 455 router 457 Region addresses MUST NOT be used as a source address in any IPv6 458 datagrams. 460 The Border Routers of the Region consider the Region-ID to be one of 461 their addresses, and will accept packets with a destination address 462 equal to the Region-ID. All the nodes within each connected component 463 that forms a Region, including Region Border Routers, are said to be 464 "members of the region". 466 Region-IDs can be used to represent Routing Domains, Routing Domain 467 Confederations, OSPF areas, Subnets, as well as generic anycast 468 addresses. This is described as follows: 470 1. A Routing Domain is a Region. The domain is identified by a 471 Routing Domain Identifier (RDI), which is simply the Region- 472 Identifier for the domain. Any Border Router of a domain is a 473 Region Border Router. 475 2. A Routing Domain Confederation is a Region. The confederation is 476 identified by a Routing Domain Confederation Identifier (RDCI), 477 which is the Region Identifier for the confederation. A Border 478 Router of a domain within a confederation that peers with a Border 479 Router in a domain that is not in the confederation is a Region 480 Border Router. In the case of confederations, note that all Border 481 Routers of domains nested within a confederation must be configured 482 with the Region-IDs of the confederation(s) in which they are 483 nested. 485 3. An OSPF area is a Region. The Region Identifier of such a Region 486 may be any unicast address that matches address prefixes within the 487 area. Note that OSPF area Border Routers do not need to be 488 configured with the Region-ID of their containing domain. 490 4. An IPv6 subnet is a Region. The Region includes all the nodes 491 attached to the subnet. Any router attached to the subnet is a 492 Region Border Router. The Region-ID is an address out of the 493 subnet. 495 5. A set of nodes that wish to share an anycast address can be 496 represented by a Region-ID where each element in the anycast group 497 is configured as a Border Router for that Region. Note that 498 unconstrained usage of anycast addresses can lead to scaling 499 problems. 501 2.6 Multicast Addresses 503 A IPv6 multicast address is an identifier for a group of nodes. A node 504 may belong to any number of multicast groups. Multicast addresses have 505 the following format: 507 | 8 | 4 | 4 | 112 bits | 508 +------ -+----+----+---------------------------------------------+ 509 |11111111|flgs|scop| group ID | 510 +--------+----+----+---------------------------------------------+ 512 11111111 at the start of the address identifies the address as 513 being a multicast address. 515 +-+-+-+-+ 516 flgs is a set of 4 flags: |0|0|0|T| 517 +-+-+-+-+ 519 The high-order 3 flags are reserved, and must be initialized 520 to 0. 522 T = 0 indicates a permanently-assigned ("well-known") 523 multicast address, assigned by the global internet numbering 524 authority. 526 T = 1 indicates a non-permanently-assigned ("transient") 527 multicast address. 529 scop is a 4-bit multicast scope value used to limit the scope of 530 the multicast group. The values are: 532 0 reserved 533 1 node-local scope 534 2 link-local scope 535 3 (unassigned) 536 4 (unassigned) 537 5 site-local scope 538 6 (unassigned) 539 7 (unassigned) 540 8 organization-local scope 541 9 (unassigned) 542 A (unassigned) 543 B community-local scope 544 C (unassigned) 545 D (unassigned) 546 E global scope 547 F reserved 549 group ID identifies the multicast group, either permanent or 550 transient, within the given scope. 552 The "meaning" of a permanently-assigned multicast address is independent 553 of the scope value. For example, if the "NTP servers group" is assigned 554 a permanent multicast address with a group ID of 43 (hex), then: 556 FF01:0:0:0:0:0:0:43 means all NTP servers on the same node as the 557 sender. 559 FF02:0:0:0:0:0:0:43 means all NTP servers on the same link as the 560 sender. 562 FF05:0:0:0:0:0:0:43 means all NTP servers at the same site as the 563 sender. 565 FF0E:0:0:0:0:0:0:43 means all NTP servers in the internet. 567 Non-permanently-assigned multicast addresses are meaningful only within 568 a given scope. For example, a group identified by the non-permanent, 569 site-local multicast address FF15:0:0:0:0:0:0:43 at one site bears no 570 relationship to a group using the same address at a different site, nor 571 to a non-permanent group using the same group ID with different scope, 572 nor to a permanent group with the same group ID. 574 Multicast addresses must not be used as source addresses in IPv6 575 datagrams or appear in any routing header. 577 2.6.1 Pre-Defined Multicast Addresses 579 The following well-known multicast addresses are pre-defined: 581 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 582 FF01:0:0:0:0:0:0:0 583 FF02:0:0:0:0:0:0:0 584 FF03:0:0:0:0:0:0:0 585 FF04:0:0:0:0:0:0:0 586 FF05:0:0:0:0:0:0:0 587 FF06:0:0:0:0:0:0:0 588 FF07:0:0:0:0:0:0:0 589 FF08:0:0:0:0:0:0:0 590 FF09:0:0:0:0:0:0:0 591 FF0A:0:0:0:0:0:0:0 592 FF0B:0:0:0:0:0:0:0 593 FF0C:0:0:0:0:0:0:0 594 FF0D:0:0:0:0:0:0:0 595 FF0E:0:0:0:0:0:0:0 596 FF0F:0:0:0:0:0:0:0 598 The above multicast addresses are reserved and shall never be assigned 599 to any multicast group. 601 All Nodes Addresses: FF01:0:0:0:0:0:0:1 602 FF02:0:0:0:0:0:0:1 604 The above multicast addresses identify the group of all IPv6 nodes, 605 within scope 1 (node-local) or 2 (link-local). 607 All Hosts Addresses: FF01:0:0:0:0:0:0:2 608 FF02:0:0:0:0:0:0:2 610 The above multicast addresses identify the group of all IPv6 hosts, 611 within scope 1 (node-local) or 2 (link-local). 613 All Routers Addresses: FF01:0:0:0:0:0:0:3 614 FF02:0:0:0:0:0:0:3 616 The above multicast addresses identify the group of all IPv6 routers, 617 within scope 1 (node-local) or 2 (link-local). 619 2.7 A Node's Required Addresses 621 A host is required to recognize the following addresses as identifying 622 itself: 624 o Assigned Unicast Addresses 625 o Loopback Address 626 o All Nodes Multicast Address 627 o All Hosts Multicast Address 628 o All other Multicast Addresses to which the host belongs. 630 A router is required to recognize the following addresses as identifying 631 itself: 633 o Assigned Unicast Addresses 634 o Region Addresses of all configured regions for which the router is 635 a boundary router 636 o Loopback Address 637 o All Nodes Multicast Address 638 o All Router Multicast Address 639 o All other Multicast Addresses to which the router belongs. 641 The only address-prefixes which should be predefined in an 642 implementation are the: 644 o Unspecified Address 645 o Loopback Address 646 o Multicast prefix (FF) 647 o Pre-Defined Multicast Addresses 648 o IPv4 Compatible Prefixes 650 Implementations should assume all other addresses are unicast unless 651 specifically configured (e.g., region addresses). 653 3.0 ROUTING ALGORITHMS 654 IPv6 routing algorithms are identical to those used with the CIDR 655 version of IP, except that the address used is 128 bits rather than 32 656 (for instance [OSPF], [RIP_]). 658 REFERENCES 660 [ASSN] Yakov Rekhter, "IPv6 Provider Unicast Address Assignment", 661 Internet Draft. 663 [AUTO] S. Thomson, "Automatic Host Address Assignment in IPv6", 664 Internet Draft. 666 [CIDR] V. Fuller, T. Li, K. Varadhan, J. Yu, "Supernetting: an 667 Address Assignment and Aggregation Strategy", RFC 1338. 669 [DISC] W. Simpson, "IPv6 Neighbor Discovery -- ICMP Message Formats", 670 Internet Draft. 672 [ICMP] S. Deering, A. Conta, "ICMP and IGMP for the Internet Protocol 673 Version 6 (IPv6)" Internet-Draft. 675 [IPV6] R. Hinden, Editor, "Internet Protocol, Version 6 (IPv6) 676 Specification", Internet Draft. 678 [MULT] S. Deering, "Host Extensions for IP multicasting", RFC 1112. 680 [NSAP] B. Carpenter, J. Bound, "Recommendations for OSI NSAP usage in 681 IPv6", Internet Draft. 683 [OSPF] "OSPF for IPv6", Internet Draft, In preparation. 685 [RIP_] "RIPv2 for IPv6, Internet Draft, In preparation. 687 [TMV6] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 688 Hosts and Routers," Internet-Draft. 690 DOCUMENT EDITOR'S ADDRESS 692 Robert M. Hinden 693 Ipsilon Network, Inc. 694 2465 Latham Street 695 Suite 100 696 Mt. View, CA 94040 697 USA 699 Phone: (415) 528-4604 700 FAX: (415) 854-4653 701 Email: hinden@ipsilon.com 703 APPENDIX 705 Changes from Previous Version 707 This version of the "IPv6 Addressing Architecture" includes the 708 following changes made since the previous version: 710 o Added "Addressing Model" section. 712 o Changed "Node ID" to "Interface ID" to reflect the current 713 Addressing Model. 715 o Cluster Address replaced by Region Address. 717 o Geographic Addresses changed to be Neutral-Interconnect 718 Addresses. 720 o Changed multicast scope names from inter-*** to ***-local 721 style. 723 o Added mention that address subfields can be assigned a zero or 724 ones value. 726 o Reduced the amount address space assigned to local use and 727 divided the local use address space into link-local and site- 728 local unicast. 730 o Swapped prefixes for IPv4-compatible and IPv4 mapped 731 addresses. 733 o Changed definition of loopback address. 735 o Added wording about wired in knowledge of address prefixes. 737 o Minor clarification's, corrections, and typos fixed. 739 o New typos likely added.