doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

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]
+