From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1884.txt | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1011 insertions(+) create mode 100644 doc/rfc/rfc1884.txt (limited to 'doc/rfc/rfc1884.txt') diff --git a/doc/rfc/rfc1884.txt b/doc/rfc/rfc1884.txt new file mode 100644 index 0000000..335a7ab --- /dev/null +++ b/doc/rfc/rfc1884.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group R. Hinden, Ipsilon Networks +Request for Comments: 1884 S. Deering, Xerox PARC +Category: Standards Track Editors + December 1995 + + + IP Version 6 Addressing Architecture + + + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + + +Abstract + + This specification defines the addressing architecture of the IP + Version 6 protocol [IPV6]. The document includes the IPv6 addressing + model, text representations of IPv6 addresses, definition of IPv6 + unicast addresses, anycast addresses, and multicast addresses, and an + IPv6 nodes required addresses. + + + + + + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 1] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + +Table of Contents + + 1. Introduction................................................3 + + 2. IPv6 Addressing.............................................3 + 2.1 Addressing Model........................................4 + 2.2 Text Representation of Addresses........................4 + 2.3 Address Type Representation.............................5 + 2.4 Unicast Addresses.......................................7 + 2.4.1 Unicast Address Example.............................8 + 2.4.2 The Unspecified Address.............................9 + 2.4.3 The Loopback Address................................9 + 2.4.4 IPv6 Addresses with Embedded IPv4 Addresses.........9 + 2.4.5 NSAP Addresses......................................10 + 2.4.6 IPX Addresses.......................................10 + 2.4.7 Provider-Based Global Unicast Addresses.............10 + 2.4.8 Local-use IPv6 Unicast Addresses....................11 + 2.5 Anycast Addresses.......................................12 + 2.5.1 Required Anycast Address............................13 + 2.6 Multicast Addresses.....................................14 + 2.6.1 Pre-Defined Multicast Addresses.....................15 + 2.7 A Node's Required Addresses.............................17 + + REFERENCES.....................................................18 + + SECURITY CONSIDERATIONS........................................18 + + DOCUMENT EDITOR'S ADDRESSES....................................18 + + + + + + + + + + + + + + + + + + + + + + + +Hinden & Deering Standards Track [Page 2] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + +1.0 INTRODUCTION + + This specification defines the addressing architecture of the IP + Version 6 protocol. It includes a detailed description of the + currently defined address formats for IPv6 [IPV6]. + + The editors would like to acknowledge the contributions of Paul + Francis, Jim Bound, Brian Carpenter, Deborah Estrin, Peter Ford, Bob + Gilligan, Christian Huitema, Tony Li, Greg Minshall, Erik Nordmark, + Yakov Rekhter, Bill Simpson, and Sue Thomson. + +2.0 IPv6 ADDRESSING + + IPv6 addresses are 128-bit identifiers for interfaces and sets of + interfaces. There are three types of addresses: + + + Unicast: An identifier for a single interface. A packet sent + to a unicast address is delivered to the interface + identified by that address. + + Anycast: An identifier for a set of interfaces (typically + belonging to different nodes). A packet sent to an + anycast address is delivered to one of the interfaces + identified by that address (the "nearest" one, + according to the routing protocols' measure of + distance). + + Multicast: An identifier for a set of interfaces (typically + belonging to different nodes). A packet sent to a + multicast address is delivered to all interfaces + identified by that address. + + There are no broadcast addresses in IPv6, their function being + superseded by multicast addresses. + + In this document, fields in addresses are given a specific name, for + example "subscriber". When this name is used with the term "ID" for + identifier after the name (e.g., "subscriber ID"), it refers to the + contents of the named field. When it is used with the term "prefix" + (e.g., "subscriber prefix") it refers to all of the address up to and + including this field. + + In IPv6, all zeros and all ones are legal values for any field, + unless specifically excluded. Specifically, prefixes may contain + zero-valued fields or end in zeros. + + + + + +Hinden & Deering Standards Track [Page 3] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + 2.1 Addressing Model + + IPv6 Addresses of all types are assigned to interfaces, not nodes. + Since each interface belongs to a single node, any of that node's + interfaces' unicast addresses may be used as an identifier for the + node. + + An IPv6 unicast address refers to a single interface. A single + interface may be assigned multiple IPv6 addresses of any type + (unicast, anycast, and multicast). There are two exceptions to this + model. These are: + + 1) A single address may be assigned to multiple physical interfaces + if the implementation treats the multiple physical interfaces as + one interface when presenting it to the internet layer. This is + useful for load-sharing over multiple physical interfaces. + + 2) Routers may have unnumbered interfaces (i.e., no IPv6 address + assigned to the interface) on point-to-point links to eliminate + the necessity to manually configure and advertise the addresses. + Addresses are not needed for point-to-point interfaces on + routers if those interfaces are not to be used as the origins or + destinations of any IPv6 datagrams. + + IPv6 continues the IPv4 model that a subnet is associated with one + link. Multiple subnets may be assigned to the same link. + + + 2.2 Text Representation of Addresses + + There are three conventional forms for representing IPv6 addresses as + text strings: + + 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the + hexadecimal values of the eight 16-bit pieces of the address. + Examples: + + FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 + + 1080:0:0:0:8:800:200C:417A + + Note that it is not necessary to write the leading zeros in an + individual field, but there must be at least one numeral in + every field (except for the case described in 2.). + + 2. Due to the method of allocating certain styles of IPv6 + addresses, it will be common for addresses to contain long + strings of zero bits. In order to make writing addresses + + + +Hinden & Deering Standards Track [Page 4] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + containing zero bits easier a special syntax is available to + compress the zeros. The use of "::" indicates multiple groups + of 16-bits of zeros. The "::" can only appear once in an + address. The "::" can also be used to compress the leading + and/or trailing zeros in an address. + + For example the following addresses: + + 1080:0:0:0:8:800:200C:417A a unicast address + FF01:0:0:0:0:0:0:43 a multicast address + 0:0:0:0:0:0:0:1 the loopback address + 0:0:0:0:0:0:0:0 the unspecified addresses + + may be represented as: + + 1080::8:800:200C:417A a unicast address + FF01::43 a multicast address + ::1 the loopback address + :: the unspecified addresses + + 3. An alternative form that is sometimes more convenient when + dealing with a mixed environment of IPv4 and IPv6 nodes is + x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values + of the six high-order 16-bit pieces of the address, and the 'd's + are the decimal values of the four low-order 8-bit pieces of the + address (standard IPv4 representation). Examples: + + 0:0:0:0:0:0:13.1.68.3 + + 0:0:0:0:0:FFFF:129.144.52.38 + + or in compressed form: + + ::13.1.68.3 + + ::FFFF:129.144.52.38 + + + 2.3 Address Type Representation + + The specific type of an IPv6 address is indicated by the leading bits + in the address. The variable-length field comprising these leading + bits is called the Format Prefix (FP). The initial allocation of + these prefixes is as follows: + + + + + + + +Hinden & Deering Standards Track [Page 5] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + Allocation Prefix Fraction of + (binary) Address Space + ------------------------------- -------- ------------- + Reserved 0000 0000 1/256 + Unassigned 0000 0001 1/256 + + Reserved for NSAP Allocation 0000 001 1/128 + Reserved for IPX Allocation 0000 010 1/128 + + Unassigned 0000 011 1/128 + Unassigned 0000 1 1/32 + Unassigned 0001 1/16 + Unassigned 001 1/8 + + Provider-Based Unicast Address 010 1/8 + + Unassigned 011 1/8 + + Reserved for Geographic- + Based Unicast Addresses 100 1/8 + + Unassigned 101 1/8 + Unassigned 110 1/8 + Unassigned 1110 1/16 + Unassigned 1111 0 1/32 + Unassigned 1111 10 1/64 + Unassigned 1111 110 1/128 + + Unassigned 1111 1110 0 1/512 + + Link Local Use Addresses 1111 1110 10 1/1024 + Site Local Use Addresses 1111 1110 11 1/1024 + + Multicast Addresses 1111 1111 1/256 + + Note: The "unspecified address" (see section 2.4.2), the + loopback address (see section 2.4.3), and the IPv6 Addresses + with Embedded IPv4 Addresses (see section 2.4.4), are assigned + out of the 0000 0000 format prefix space. + + + This allocation supports the direct allocation of provider addresses, + local use addresses, and multicast addresses. Space is reserved for + NSAP addresses, IPX addresses, and geographic addresses. The + remainder of the address space is unassigned for future use. This + can be used for expansion of existing use (e.g., additional provider + addresses, etc.) or new uses (e.g., separate locators and + identifiers). Fifteen percent of the address space is initially + + + +Hinden & Deering Standards Track [Page 6] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + allocated. The remaining 85% is reserved for future use. + + Unicast addresses are distinguished from multicast addresses by the + value of the high-order octet of the addresses: a value of FF + (11111111) identifies an address as a multicast address; any other + value identifies an address as a unicast address. Anycast addresses + are taken from the unicast address space, and are not syntactically + distinguishable from unicast addresses. + + + 2.4 Unicast Addresses + + The IPv6 unicast address is contiguous bit-wise maskable, similar to + IPv4 addresses under Class-less Interdomain Routing [CIDR]. + + There are several forms of unicast address assignment in IPv6, + including the global provider based unicast address, the geographic + based unicast address, the NSAP address, the IPX hierarchical + address, the site-local-use address, the link-local-use address, and + the IPv4-capable host address. Additional address types can be + defined in the future. + + IPv6 nodes may have considerable or little knowledge of the internal + structure of the IPv6 address, depending on the role the node plays + (for instance, host versus router). At a minimum, a node may + consider that unicast addresses (including its own) have no internal + structure: + + | 128 bits | + +-----------------------------------------------------------------+ + | node address | + +-----------------------------------------------------------------+ + + + A slightly sophisticated host (but still rather simple) may + additionally be aware of subnet prefix(es) for the link(s) it is + attached to, where different addresses may have different values for + n: + + | n bits | 128-n bits | + +------------------------------------------------+----------------+ + | subnet prefix | interface ID | + +------------------------------------------------+----------------+ + + + Still more sophisticated hosts may be aware of other hierarchical + boundaries in the unicast address. Though a very simple router may + have no knowledge of the internal structure of IPv6 unicast + + + +Hinden & Deering Standards Track [Page 7] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + addresses, routers will more generally have knowledge of one or more + of the hierarchical boundaries for the operation of routing + protocols. The known boundaries will differ from router to router, + depending on what positions the router holds in the routing + hierarchy. + + + 2.4.1 Unicast Address Examples + + An example of a Unicast address format which will likely be common on + LANs and other environments where IEEE 802 MAC addresses are + available is: + + + | n bits | 80-n bits | 48 bits | + +--------------------------------+-----------+--------------------+ + | subscriber prefix | subnet ID | interface ID | + +--------------------------------+-----------+--------------------+ + + Where the 48-bit Interface ID is an IEEE-802 MAC address. The use of + IEEE 802 MAC addresses as a interface ID is expected to be very + common in environments where nodes have an IEEE 802 MAC address. In + other environments, where IEEE 802 MAC addresses are not available, + other types of link layer addresses can be used, such as E.164 + addresses, for the interface ID. + + The inclusion of a unique global interface identifier, such as an + IEEE MAC address, makes possible a very simple form of auto- + configuration of addresses. A node may discover a subnet ID by + listening to Router Advertisement messages sent by a router on its + attached link(s), and then fabricating an IPv6 address for itself by + using its IEEE MAC address as the interface ID on that subnet. + + Another unicast address format example is where a site or + organization requires additional layers of internal hierarchy. In + this example the subnet ID is divided into an area ID and a subnet + ID. Its format is: + + | s bits | n bits | m bits | 128-s-n-m bits | + +----------------------+---------+--------------+-----------------+ + | subscriber prefix | area ID | subnet ID | interface ID | + +----------------------+---------+--------------+-----------------+ + + This technique can be continued to allow a site or organization to + add additional layers of internal hierarchy. It may be desirable to + use an interface ID smaller than a 48-bit IEEE 802 MAC address to + allow more space for the additional layers of internal hierarchy. + These could be interface IDs which are administratively created by + + + +Hinden & Deering Standards Track [Page 8] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + the site or organization. + + + 2.4.2 The Unspecified Address + + The address 0:0:0:0:0:0:0:0 is called the unspecified address. It + must never be assigned to any node. It indicates the absence of an + address. One example of its use is in the Source Address field of + any IPv6 datagrams sent by an initializing host before it has learned + its own address. + + The unspecified address must not be used as the destination address + of IPv6 datagrams or in IPv6 Routing Headers. + + + 2.4.3 The Loopback Address + + The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. + It may be used by a node to send an IPv6 datagram to itself. It may + never be assigned to any interface. + + The loopback address must not be used as the source address in IPv6 + datagrams that are sent outside of a single node. An IPv6 datagram + with a destination address of loopback must never be sent outside of + a single node. + + + 2.4.4 IPv6 Addresses with Embedded IPv4 Addresses + + The IPv6 transition mechanisms include a technique for hosts and + routers to dynamically tunnel IPv6 packets over IPv4 routing + infrastructure. IPv6 nodes that utilize this technique are assigned + special IPv6 unicast addresses that carry an IPv4 address in the + low-order 32-bits. This type of address is termed an "IPv4- + compatible IPv6 address" and has the format: + + + | 80 bits | 16 | 32 bits | + +--------------------------------------+--------------------------+ + |0000..............................0000|0000| IPv4 address | + +--------------------------------------+----+---------------------+ + + + A second type of IPv6 address which holds an embedded IPv4 address is + also defined. This address is used to represent the addresses of + IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. + This type of address is termed an "IPv4-mapped IPv6 address" and has + the format: + + + +Hinden & Deering Standards Track [Page 9] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + + | 80 bits | 16 | 32 bits | + +--------------------------------------+--------------------------+ + |0000..............................0000|FFFF| IPv4 address | + +--------------------------------------+----+---------------------+ + + + + 2.4.5 NSAP Addresses + + This mapping of NSAP address into IPv6 addresses is as follows: + + + | 7 | 121 bits | + +-------+---------------------------------------------------------+ + |0000001| to be defined | + +-------+---------------------------------------------------------+ + + The draft definition, motivation, and usage are under study [NSAP]. + + + 2.4.6 IPX Addresses + + This mapping of IPX address into IPv6 addresses is as follows: + + + | 7 | 121 bits | + +-------+---------------------------------------------------------+ + |0000010| to be defined | + +-------+---------------------------------------------------------+ + + The draft definition, motivation, and usage are under study. + + + 2.4.7 Provider-Based Global Unicast Addresses + + The global provider-based unicast address is assigned as described in + [ALLOC]. This initial assignment plan for these unicast addresses is + similar to assignment of IPv4 addresses under the CIDR scheme [CIDR]. + The IPv6 global provider-based unicast address format is as follows: + + + | 3 | n bits | m bits | o bits | 125-n-m-o bits | + +---+-----------+-----------+-------------+--------------------+ + |010|registry ID|provider ID|subscriber ID| intra-subscriber | + +---+-----------+-----------+-------------+--------------------+ + + + + + +Hinden & Deering Standards Track [Page 10] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + The high-order part of the address is assigned to registries, who + then assign portions of the address space to providers, who then + assign portions of the address space to subscribers, etc. + + The registry ID identifies the registry which assigns the provider + portion of the address. The term "registry prefix" refers to the + high-order part of the address up to and including the registry ID. + + The provider ID identifies a specific provider which assigns the + subscriber portion of the address. The term "provider prefix" refers + to the high-order part of the address up to and including the + provider ID. + + The subscriber ID distinguishes among multiple subscribers attached + to the provider identified by the provider ID. The term "subscriber + prefix" refers to the high-order part of the address up to and + including the subscriber ID. + + The intra-subscriber portion of the address is defined by an + individual subscriber and is organized according to the subscribers + local internet topology. It is likely that many subscribers will + choose to divide the intra-subscriber portion of the address into a + subnet ID and an interface ID. In this case the subnet ID identifies + a specific physical link and the interface ID identifies a single + interface on that subnet. + + + 2.4.8 Local-use IPv6 Unicast Addresses + + There are two types of local-use unicast addresses defined. These + are Link-Local and Site-Local. The Link-Local is for use on a single + link and the Site-Local is for use in a single site. Link-Local + addresses have the following format: + + | 10 | + | bits | n bits | 118-n bits | + +----------+-------------------------+----------------------------+ + |1111111010| 0 | interface ID | + +----------+-------------------------+----------------------------+ + + Link-Local addresses are designed to be used for addressing on a + single link for purposes such as auto-address configuration, neighbor + discovery, or when no routers are present. + + Routers MUST not forward any packets with link-local source + addresses. + + + + + +Hinden & Deering Standards Track [Page 11] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + Site-Local addresses have the following format: + + | 10 | + | bits | n bits | m bits | 118-n-m bits | + +----------+---------+---------------+----------------------------+ + |1111111011| 0 | subnet ID | interface ID | + +----------+---------+---------------+----------------------------+ + + + Site-Local addresses may be used for sites or organizations that are + not (yet) connected to the global Internet. They do not need to + request or "steal" an address prefix from the global Internet address + space. IPv6 site-local addresses can be used instead. When the + organization connects to the global Internet, it can then form global + addresses by replacing the site-local prefix with a subscriber + prefix. + + Routers MUST not forward any packets with site-local source addresses + outside of the site. + + 2.5 Anycast Addresses + + An IPv6 anycast address is an address that is assigned to more than + one interface (typically belonging to different nodes), with the + property that a packet sent to an anycast address is routed to the + "nearest" interface having that address, according to the routing + protocols' measure of distance. + + Anycast addresses are allocated from the unicast address space, using + any of the defined unicast address formats. Thus, anycast addresses + are syntactically indistinguishable from unicast addresses. When a + unicast address is assigned to more than one interface, thus turning + it into an anycast address, the nodes to which the address is + assigned must be explicitly configured to know that it is an anycast + address. + + For any assigned anycast address, there is a longest address prefix P + that identifies the topological region in which all interfaces + belonging to that anycast address reside. Within the region + identified by P, each member of the anycast set must be advertised as + a separate entry in the routing system (commonly referred to as a + "host route"); outside the region identified by P, the anycast + address may be aggregated into the routing advertisement for prefix + P. + + Note that in, the worst case, the prefix P of an anycast set may be + the null prefix, i.e., the members of the set may have no topological + locality. In that case, the anycast address must be advertised as a + + + +Hinden & Deering Standards Track [Page 12] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + separate routing entry throughout the entire internet, which presents + a severe scaling limit on how many such "global" anycast sets may be + supported. Therefore, it is expected that support for global anycast + sets may be unavailable or very restricted. + + One expected use of anycast addresses is to identify the set of + routers belonging to an internet service provider. Such addresses + could be used as intermediate addresses in an IPv6 Routing header, to + cause a packet to be delivered via a particular provider or sequence + of providers. Some other possible uses are to identify the set of + routers attached to a particular subnet, or the set of routers + providing entry into a particular routing domain. + + There is little experience with widespread, arbitrary use of internet + anycast addresses, and some known complications and hazards when + using them in their full generality [ANYCST]. Until more experience + has been gained and solutions agreed upon for those problems, the + following restrictions are imposed on IPv6 anycast addresses: + + o An anycast address MUST NOT be used as the source address of an + IPv6 packet. + + o An anycast address MUST NOT be assigned to an IPv6 host, that + is, it may be assigned to an IPv6 router only. + + + 2.5.1 Required Anycast Address + + The Subnet-Router anycast address is predefined. It's format is as + follows: + + + | n bits | 128-n bits | + +------------------------------------------------+----------------+ + | subnet prefix | 00000000000000 | + +------------------------------------------------+----------------+ + + + The "subnet prefix" in an anycast address is the prefix which + identifies a specific link. This anycast address is syntactically + the same as a unicast address for an interface on the link with the + interface identifier set to zero. + + Packets sent to the Subnet-Router anycast address will be delivered + to one router on the subnet. All routers are required to support the + Subnet-Router anycast addresses for the subnets which they have + interfaces. + + + + +Hinden & Deering Standards Track [Page 13] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + The subnet-router anycast address is intended to be used for + applications where a node needs to communicate with one of a set of + routers on a remote subnet. For example when a mobile host needs to + communicate with one of the mobile agents on it's "home" subnet. + + + 2.6 Multicast Addresses + + An IPv6 multicast address is an identifier for a group of nodes. A + node may belong to any number of multicast groups. Multicast + addresses have the following format: + + | 8 | 4 | 4 | 112 bits | + +------ -+----+----+---------------------------------------------+ + |11111111|flgs|scop| group ID | + +--------+----+----+---------------------------------------------+ + + 11111111 at the start of the address identifies the address as + being a multicast address. + + +-+-+-+-+ + flgs is a set of 4 flags: |0|0|0|T| + +-+-+-+-+ + + The high-order 3 flags are reserved, and must be + initialized to 0. + + T = 0 indicates a permanently-assigned ("well-known") + multicast address, assigned by the global internet + numbering authority. + + T = 1 indicates a non-permanently-assigned ("transient") + multicast address. + + scop is a 4-bit multicast scope value used to limit the scope of + the multicast group. The values are: + + 0 reserved + 1 node-local scope + 2 link-local scope + 3 (unassigned) + 4 (unassigned) + 5 site-local scope + 6 (unassigned) + 7 (unassigned) + 8 organization-local scope + 9 (unassigned) + A (unassigned) + + + +Hinden & Deering Standards Track [Page 14] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + B (unassigned) + C (unassigned) + D (unassigned) + E global scope + F reserved + + group ID identifies the multicast group, either permanent or + transient, within the given scope. + + The "meaning" of a permanently-assigned multicast address is + independent of the scope value. For example, if the "NTP servers + group" is assigned a permanent multicast address with a group ID of + 43 (hex), then: + + FF01:0:0:0:0:0:0:43 means all NTP servers on the same node as + the sender. + + FF02:0:0:0:0:0:0:43 means all NTP servers on the same link as + the sender. + + FF05:0:0:0:0:0:0:43 means all NTP servers at the same site as + the sender. + + FF0E:0:0:0:0:0:0:43 means all NTP servers in the internet. + + Non-permanently-assigned multicast addresses are meaningful only + within a given scope. For example, a group identified by the non- + permanent, site-local multicast address FF15:0:0:0:0:0:0:43 at one + site bears no relationship to a group using the same address at a + different site, nor to a non-permanent group using the same group ID + with different scope, nor to a permanent group with the same group + ID. + + Multicast addresses must not be used as source addresses in IPv6 + datagrams or appear in any routing header. + + + 2.6.1 Pre-Defined Multicast Addresses + + The following well-known multicast addresses are pre-defined: + + Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 + FF01:0:0:0:0:0:0:0 + FF02:0:0:0:0:0:0:0 + FF03:0:0:0:0:0:0:0 + FF04:0:0:0:0:0:0:0 + FF05:0:0:0:0:0:0:0 + FF06:0:0:0:0:0:0:0 + + + +Hinden & Deering Standards Track [Page 15] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + FF07:0:0:0:0:0:0:0 + FF08:0:0:0:0:0:0:0 + FF09:0:0:0:0:0:0:0 + FF0A:0:0:0:0:0:0:0 + FF0B:0:0:0:0:0:0:0 + FF0C:0:0:0:0:0:0:0 + FF0D:0:0:0:0:0:0:0 + FF0E:0:0:0:0:0:0:0 + FF0F:0:0:0:0:0:0:0 + + The above multicast addresses are reserved and shall never be + assigned to any multicast group. + + All Nodes Addresses: FF01:0:0:0:0:0:0:1 + FF02:0:0:0:0:0:0:1 + + The above multicast addresses identify the group of all IPv6 nodes, + within scope 1 (node-local) or 2 (link-local). + + All Routers Addresses: FF01:0:0:0:0:0:0:2 + FF02:0:0:0:0:0:0:2 + + The above multicast addresses identify the group of all IPv6 routers, + within scope 1 (node-local) or 2 (link-local). + + DHCP Server/Relay-Agent: FF02:0:0:0:0:0:0:C + + The above multicast addresses identify the group of all IPv6 DHCP + Servers and Relay Agents within scope 2 (link-local). + + Solicited-Node Address: FF02:0:0:0:0:1:XXXX:XXXX + + The above multicast address is computed as a function of a node's + unicast and anycast addresses. The solicited-node multicast address + is formed by taking the low-order 32 bits of the address (unicast or + anycast) and appending those bits to the 96-bit prefix FF02:0:0:0:0:1 + resulting in a multicast address in the range + + FF02:0:0:0:0:1:0000:0000 + + to + + FF02:0:0:0:0:1:FFFF:FFFF + + For example, the solicited node multicast address corresponding to + the IPv6 address 4037::01:800:200E:8C6C is FF02::1:200E:8C6C. IPv6 + addresses that differ only in the high-order bits, e.g., due to + multiple high-order prefixes associated with different providers, + + + +Hinden & Deering Standards Track [Page 16] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + + will map to the same solicited-node address thereby reducing the + number of multicast addresses a node must join. + + A node is required to compute and support a Solicited-Node multicast + addresses for every unicast and anycast address it is assigned. + + 2.7 A Node's Required Addresses + + A host is required to recognize the following addresses as + identifying itself: + + o Its Link-Local Address for each interface + o Assigned Unicast Addresses + o Loopback Address + o All-Nodes Multicast Address + o Solicited-Node Multicast Address for each of its assigned + unicast and anycast addresses + o Multicast Addresses of all other groups which the host belongs. + + A router is required to recognize the following addresses as + identifying itself: + + o Its Link-Local Address for each interface + o Assigned Unicast Addresses + o Loopback Address + o The Subnet-Router anycast addresses for the links it has + interfaces. + o All other Anycast addresses with which the router has been + configured. + o All-Nodes Multicast Address + o All-Router Multicast Address + o Solicited-Node Multicast Address for each of its assigned + unicast and anycast addresses + o Multicast Addresses of all other groups which the router + belongs. + + The only address prefixes which should be predefined in an + implementation are the: + + o Unspecified Address + o Loopback Address + o Multicast Prefix (FF) + o Local-Use Prefixes (Link-Local and Site-Local) + o Pre-Defined Multicast Addresses + o IPv4-Compatible Prefixes + + Implementations should assume all other addresses are unicast unless + specifically configured (e.g., anycast addresses). + + + +Hinden & Deering Standards Track [Page 17] + +RFC 1884 IPv6 Addressing Architecture December 1995 + + +REFERENCES + + [ALLOC] Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast + Address Allocation", RFC 1887, cisco Systems, December + 1995. + + [ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host + Anycasting Service", RFC 1546, BBN, November 1993. + + [CIDR] Fuller, V., Li, T., Varadhan, K., and J. Yu, "Supernetting: + an Address Assignment and Aggregation Strategy", RFC 1338, + BARRNet, cisco, Merit, OARnet, June 1992. + + [IPV6] Deering, S., and R. Hinden, Editors, "Internet Protocol, + Version 6 (IPv6) Specification", RFC 1883, Xerox PARC, + Ipsilon Networks, December 1995. + + [MULT] Deering, S., "Host Extensions for IP multicasting", STD 5, + RFC 1112, Stanford University, August 1989. + + [NSAP] Carpenter, B., Editor, "Mechanisms for OSIN SAPs, CLNP and + TP over IPv6", Work in Progress. + + + +SECURITY CONSIDERATIONS + + Security issues are not discussed in this document. + + +DOCUMENT EDITOR'S ADDRESSES + + Robert M. Hinden Stephen E. Deering + Ipsilon Networks, Inc. Xerox Palo Alto Research Center + 2191 E. Bayshore Road, Suite 100 3333 Coyote Hill Road + Palo Alto, CA 94303 Palo Alto, CA 94304 + USA USA + + Phone: +1 415 846 4604 Phone: +1 415 812 4839 + Fax: +1 415 855 1414 Fax: +1 415 812 4471 + EMail: hinden@ipsilon.com EMail: deering@parc.xerox.com + + + + + + + + + + +Hinden & Deering Standards Track [Page 18] + -- cgit v1.2.3