summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4291.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4291.txt')
-rw-r--r--doc/rfc/rfc4291.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc4291.txt b/doc/rfc/rfc4291.txt
new file mode 100644
index 0000000..06ef736
--- /dev/null
+++ b/doc/rfc/rfc4291.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group R. Hinden
+Request for Comments: 4291 Nokia
+Obsoletes: 3513 S. Deering
+Category: Standards Track Cisco Systems
+ February 2006
+
+
+ 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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This specification defines the addressing architecture of the IP
+ Version 6 (IPv6) protocol. 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 node's required addresses.
+
+ This document obsoletes RFC 3513, "IP Version 6 Addressing
+ Architecture".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden Standards Track [Page 1]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. IPv6 Addressing .................................................2
+ 2.1. Addressing Model ...........................................3
+ 2.2. Text Representation of Addresses ...........................4
+ 2.3. Text Representation of Address Prefixes ....................5
+ 2.4. Address Type Identification ................................6
+ 2.5. Unicast Addresses ..........................................6
+ 2.5.1. Interface Identifiers ...............................7
+ 2.5.2. The Unspecified Address .............................9
+ 2.5.3. The Loopback Address ................................9
+ 2.5.4. Global Unicast Addresses ............................9
+ 2.5.5. IPv6 Addresses with Embedded IPv4 Addresses ........10
+ 2.5.6. Link-Local IPv6 Unicast Addresses ..................11
+ 2.5.7. Site-Local IPv6 Unicast Addresses ..................11
+ 2.6. Anycast Addresses .........................................12
+ 2.6.1. Required Anycast Address ...........................12
+ 2.7. Multicast Addresses .......................................13
+ 2.7.1. Pre-Defined Multicast Addresses ....................15
+ 2.8. A Node's Required Addresses ...............................17
+ 3. Security Considerations ........................................18
+ 4. IANA Considerations ............................................18
+ 5. Acknowledgements ...............................................18
+ 6. References .....................................................18
+ 6.1. Normative References ......................................18
+ 6.2. Informative References ....................................18
+ Appendix A: Creating Modified EUI-64 Format Interface Identifiers .20
+ Appendix B: Changes from RFC 3513 .................................22
+
+1. Introduction
+
+ This specification defines the addressing architecture of the IP
+ Version 6 protocol. It includes the basic formats for the various
+ types of IPv6 addresses (unicast, anycast, and multicast).
+
+2. IPv6 Addressing
+
+ IPv6 addresses are 128-bit identifiers for interfaces and sets of
+ interfaces (where "interface" is as defined in Section 2 of [IPV6]).
+ 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.
+
+
+
+
+
+
+Hinden Standards Track [Page 2]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ 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, "subnet". When this name is used with the term "ID" for
+ identifier after the name (e.g., "subnet ID"), it refers to the
+ contents of the named field. When it is used with the term "prefix"
+ (e.g., "subnet prefix"), it refers to all of the address from the
+ left 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, or
+ end with, zero-valued fields.
+
+2.1. Addressing Model
+
+ IPv6 addresses of all types are assigned to interfaces, not nodes.
+ An IPv6 unicast address refers to a single interface. 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.
+
+ All interfaces are required to have at least one Link-Local unicast
+ address (see Section 2.8 for additional required addresses). A
+ single interface may also have multiple IPv6 addresses of any type
+ (unicast, anycast, and multicast) or scope. Unicast addresses with a
+ scope greater than link-scope are not needed for interfaces that are
+ not used as the origin or destination of any IPv6 packets to or from
+ non-neighbors. This is sometimes convenient for point-to-point
+ interfaces. There is one exception to this addressing model:
+
+ A unicast address or a set of unicast addresses 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.
+
+
+
+
+
+Hinden Standards Track [Page 3]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ Currently, IPv6 continues the IPv4 model in that a subnet prefix is
+ associated with one link. Multiple subnet prefixes 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 one to
+ four hexadecimal digits of the eight 16-bit pieces of the address.
+ Examples:
+
+ ABCD:EF01:2345:6789:ABCD:EF01:2345:6789
+
+ 2001:DB8: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 some methods 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 containing zero
+ bits easier, a special syntax is available to compress the zeros.
+ The use of "::" indicates one or more groups of 16 bits of zeros.
+ The "::" can only appear once in an address. The "::" can also be
+ used to compress leading or trailing zeros in an address.
+
+ For example, the following addresses
+
+ 2001:DB8:0:0:8:800:200C:417A a unicast address
+ FF01:0:0:0:0:0:0:101 a multicast address
+ 0:0:0:0:0:0:0:1 the loopback address
+ 0:0:0:0:0:0:0:0 the unspecified address
+
+ may be represented as
+
+ 2001:DB8::8:800:200C:417A a unicast address
+ FF01::101 a multicast address
+ ::1 the loopback address
+ :: the unspecified address
+
+ 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
+
+
+
+
+Hinden Standards Track [Page 4]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ 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. Text Representation of Address Prefixes
+
+ The text representation of IPv6 address prefixes is similar to the
+ way IPv4 address prefixes are written in Classless Inter-Domain
+ Routing (CIDR) notation [CIDR]. An IPv6 address prefix is
+ represented by the notation:
+
+ ipv6-address/prefix-length
+
+ where
+
+ ipv6-address is an IPv6 address in any of the notations listed
+ in Section 2.2.
+
+ prefix-length is a decimal value specifying how many of the
+ leftmost contiguous bits of the address comprise
+ the prefix.
+
+ For example, the following are legal representations of the 60-bit
+ prefix 20010DB80000CD3 (hexadecimal):
+
+ 2001:0DB8:0000:CD30:0000:0000:0000:0000/60
+ 2001:0DB8::CD30:0:0:0:0/60
+ 2001:0DB8:0:CD30::/60
+
+ The following are NOT legal representations of the above prefix:
+
+ 2001:0DB8:0:CD3/60 may drop leading zeros, but not trailing
+ zeros, within any 16-bit chunk of the address
+
+ 2001:0DB8::CD30/60 address to left of "/" expands to
+ 2001:0DB8:0000:0000:0000:0000:0000:CD30
+
+ 2001:0DB8::CD3/60 address to left of "/" expands to
+ 2001:0DB8:0000:0000:0000:0000:0000:0CD3
+
+
+
+Hinden Standards Track [Page 5]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ When writing both a node address and a prefix of that node address
+ (e.g., the node's subnet prefix), the two can be combined as follows:
+
+ the node address 2001:0DB8:0:CD30:123:4567:89AB:CDEF
+ and its subnet number 2001:0DB8:0:CD30::/60
+
+ can be abbreviated as 2001:0DB8:0:CD30:123:4567:89AB:CDEF/60
+
+2.4. Address Type Identification
+
+ The type of an IPv6 address is identified by the high-order bits of
+ the address, as follows:
+
+ Address type Binary prefix IPv6 notation Section
+ ------------ ------------- ------------- -------
+ Unspecified 00...0 (128 bits) ::/128 2.5.2
+ Loopback 00...1 (128 bits) ::1/128 2.5.3
+ Multicast 11111111 FF00::/8 2.7
+ Link-Local unicast 1111111010 FE80::/10 2.5.6
+ Global Unicast (everything else)
+
+ Anycast addresses are taken from the unicast address spaces (of any
+ scope) and are not syntactically distinguishable from unicast
+ addresses.
+
+ The general format of Global Unicast addresses is described in
+ Section 2.5.4. Some special-purpose subtypes of Global Unicast
+ addresses that contain embedded IPv4 addresses (for the purposes of
+ IPv4-IPv6 interoperation) are described in Section 2.5.5.
+
+ Future specifications may redefine one or more sub-ranges of the
+ Global Unicast space for other purposes, but unless and until that
+ happens, implementations must treat all addresses that do not start
+ with any of the above-listed prefixes as Global Unicast addresses.
+
+2.5. Unicast Addresses
+
+ IPv6 unicast addresses are aggregatable with prefixes of arbitrary
+ bit-length, similar to IPv4 addresses under Classless Inter-Domain
+ Routing.
+
+ There are several types of unicast addresses in IPv6, in particular,
+ Global Unicast, site-local unicast (deprecated, see Section 2.5.7),
+ and Link-Local unicast. There are also some special-purpose subtypes
+ of Global Unicast, such as IPv6 addresses with embedded IPv4
+ addresses. Additional address types or subtypes can be defined in
+ the future.
+
+
+
+
+Hinden Standards Track [Page 6]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ 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 |
+ +-------------------------------+---------------------------------+
+
+ Though a very simple router may have no knowledge of the internal
+ structure of IPv6 unicast 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.
+
+ Except for the knowledge of the subnet boundary discussed in the
+ previous paragraphs, nodes should not make any assumptions about the
+ structure of an IPv6 address.
+
+2.5.1. Interface Identifiers
+
+ Interface identifiers in IPv6 unicast addresses are used to identify
+ interfaces on a link. They are required to be unique within a subnet
+ prefix. It is recommended that the same interface identifier not be
+ assigned to different nodes on a link. They may also be unique over
+ a broader scope. In some cases, an interface's identifier will be
+ derived directly from that interface's link-layer address. The same
+ interface identifier may be used on multiple interfaces on a single
+ node, as long as they are attached to different subnets.
+
+ Note that the uniqueness of interface identifiers is independent of
+ the uniqueness of IPv6 addresses. For example, a Global Unicast
+ address may be created with a local scope interface identifier and a
+ Link-Local address may be created with a universal scope interface
+ identifier.
+
+
+
+Hinden Standards Track [Page 7]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ For all unicast addresses, except those that start with the binary
+ value 000, Interface IDs are required to be 64 bits long and to be
+ constructed in Modified EUI-64 format.
+
+ Modified EUI-64 format-based interface identifiers may have universal
+ scope when derived from a universal token (e.g., IEEE 802 48-bit MAC
+ or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
+ global token is not available (e.g., serial links, tunnel end-points)
+ or where global tokens are undesirable (e.g., temporary tokens for
+ privacy [PRIV]).
+
+ Modified EUI-64 format interface identifiers are formed by inverting
+ the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
+ forming the interface identifier from IEEE EUI-64 identifiers. In
+ the resulting Modified EUI-64 format, the "u" bit is set to one (1)
+ to indicate universal scope, and it is set to zero (0) to indicate
+ local scope. The first three octets in binary of an IEEE EUI-64
+ identifier are as follows:
+
+ 0 0 0 1 1 2
+ |0 7 8 5 6 3|
+ +----+----+----+----+----+----+
+ |cccc|ccug|cccc|cccc|cccc|cccc|
+ +----+----+----+----+----+----+
+
+ written in Internet standard bit-order, where "u" is the
+ universal/local bit, "g" is the individual/group bit, and "c" is the
+ bits of the company_id. Appendix A, "Creating Modified EUI-64 Format
+ Interface Identifiers", provides examples on the creation of Modified
+ EUI-64 format-based interface identifiers.
+
+ The motivation for inverting the "u" bit when forming an interface
+ identifier is to make it easy for system administrators to hand
+ configure non-global identifiers when hardware tokens are not
+ available. This is expected to be the case for serial links and
+ tunnel end-points, for example. The alternative would have been for
+ these to be of the form 0200:0:0:1, 0200:0:0:2, etc., instead of the
+ much simpler 0:0:0:1, 0:0:0:2, etc.
+
+ IPv6 nodes are not required to validate that interface identifiers
+ created with modified EUI-64 tokens with the "u" bit set to universal
+ are unique.
+
+ The use of the universal/local bit in the Modified EUI-64 format
+ identifier is to allow development of future technology that can take
+ advantage of interface identifiers with universal scope.
+
+
+
+
+
+Hinden Standards Track [Page 8]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ The details of forming interface identifiers are defined in the
+ appropriate "IPv6 over <link>" specification, such as "IPv6 over
+ Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI].
+
+2.5.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 packets 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 packets or in IPv6 Routing headers. An IPv6 packet with a
+ source address of unspecified must never be forwarded by an IPv6
+ router.
+
+2.5.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 packet to itself. It must
+ not be assigned to any physical interface. It is treated as having
+ Link-Local scope, and may be thought of as the Link-Local unicast
+ address of a virtual interface (typically called the "loopback
+ interface") to an imaginary link that goes nowhere.
+
+ The loopback address must not be used as the source address in IPv6
+ packets that are sent outside of a single node. An IPv6 packet with
+ a destination address of loopback must never be sent outside of a
+ single node and must never be forwarded by an IPv6 router. A packet
+ received on an interface with a destination address of loopback must
+ be dropped.
+
+2.5.4. Global Unicast Addresses
+
+ The general format for IPv6 Global Unicast addresses is as follows:
+
+ | n bits | m bits | 128-n-m bits |
+ +------------------------+-----------+----------------------------+
+ | global routing prefix | subnet ID | interface ID |
+ +------------------------+-----------+----------------------------+
+
+ where the global routing prefix is a (typically hierarchically-
+ structured) value assigned to a site (a cluster of subnets/links),
+ the subnet ID is an identifier of a link within the site, and the
+ interface ID is as defined in Section 2.5.1.
+
+
+
+
+
+Hinden Standards Track [Page 9]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ All Global Unicast addresses other than those that start with binary
+ 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
+ described in Section 2.5.1. Global Unicast addresses that start with
+ binary 000 have no such constraint on the size or structure of the
+ interface ID field.
+
+ Examples of Global Unicast addresses that start with binary 000 are
+ the IPv6 address with embedded IPv4 addresses described in Section
+ 2.5.5. An example of global addresses starting with a binary value
+ other than 000 (and therefore having a 64-bit interface ID field) can
+ be found in [GLOBAL].
+
+2.5.5. IPv6 Addresses with Embedded IPv4 Addresses
+
+ Two types of IPv6 addresses are defined that carry an IPv4 address in
+ the low-order 32 bits of the address. These are the "IPv4-Compatible
+ IPv6 address" and the "IPv4-mapped IPv6 address".
+
+2.5.5.1. IPv4-Compatible IPv6 Address
+
+ The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6
+ transition. The format of the "IPv4-Compatible IPv6 address" is as
+ follows:
+
+ | 80 bits | 16 | 32 bits |
+ +--------------------------------------+--------------------------+
+ |0000..............................0000|0000| IPv4 address |
+ +--------------------------------------+----+---------------------+
+
+ Note: The IPv4 address used in the "IPv4-Compatible IPv6 address"
+ must be a globally-unique IPv4 unicast address.
+
+ The "IPv4-Compatible IPv6 address" is now deprecated because the
+ current IPv6 transition mechanisms no longer use these addresses.
+ New or updated implementations are not required to support this
+ address type.
+
+2.5.5.2. IPv4-Mapped IPv6 Address
+
+ A second type of IPv6 address that holds an embedded IPv4 address is
+ defined. This address type is used to represent the addresses of
+ IPv4 nodes as IPv6 addresses. The format of the "IPv4-mapped IPv6
+ address" is as follows:
+
+
+
+
+
+
+
+
+Hinden Standards Track [Page 10]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+
+ | 80 bits | 16 | 32 bits |
+ +--------------------------------------+--------------------------+
+ |0000..............................0000|FFFF| IPv4 address |
+ +--------------------------------------+----+---------------------+
+
+ See [RFC4038] for background on the usage of the "IPv4-mapped IPv6
+ address".
+
+2.5.6. Link-Local IPv6 Unicast Addresses
+
+ Link-Local addresses are for use on a single link. Link-Local
+ addresses have the following format:
+
+ | 10 |
+ | bits | 54 bits | 64 bits |
+ +----------+-------------------------+----------------------------+
+ |1111111010| 0 | interface ID |
+ +----------+-------------------------+----------------------------+
+
+ Link-Local addresses are designed to be used for addressing on a
+ single link for purposes such as automatic address configuration,
+ neighbor discovery, or when no routers are present.
+
+ Routers must not forward any packets with Link-Local source or
+ destination addresses to other links.
+
+2.5.7. Site-Local IPv6 Unicast Addresses
+
+ Site-Local addresses were originally designed to be used for
+ addressing inside of a site without the need for a global prefix.
+ Site-local addresses are now deprecated as defined in [SLDEP].
+
+ Site-Local addresses have the following format:
+
+ | 10 |
+ | bits | 54 bits | 64 bits |
+ +----------+-------------------------+----------------------------+
+ |1111111011| subnet ID | interface ID |
+ +----------+-------------------------+----------------------------+
+
+ The special behavior of this prefix defined in [RFC3513] must no
+ longer be supported in new implementations (i.e., new implementations
+ must treat this prefix as Global Unicast).
+
+ Existing implementations and deployments may continue to use this
+ prefix.
+
+
+
+
+Hinden Standards Track [Page 11]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+2.6. 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 prefix P of that
+ address that identifies the topological region in which all
+ interfaces belonging to that anycast address reside. Within the
+ region identified by P, the anycast address must be maintained 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 entry 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 maintained as a
+ 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 organization providing Internet service.
+ Such addresses could be used as intermediate addresses in an IPv6
+ Routing header, to cause a packet to be delivered via a particular
+ service provider or sequence of service 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.
+
+2.6.1. Required Anycast Address
+
+ The Subnet-Router anycast address is predefined. Its format is as
+ follows:
+
+
+
+
+
+Hinden Standards Track [Page 12]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+
+ | n bits | 128-n bits |
+ +------------------------------------------------+----------------+
+ | subnet prefix | 00000000000000 |
+ +------------------------------------------------+----------------+
+
+ The "subnet prefix" in an anycast address is the prefix that
+ 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 to which they have
+ interfaces.
+
+ The Subnet-Router anycast address is intended to be used for
+ applications where a node needs to communicate with any one of the
+ set of routers.
+
+2.7. Multicast Addresses
+
+ An IPv6 multicast address is an identifier for a group of interfaces
+ (typically on different nodes). An interface may belong to any
+ number of multicast groups. Multicast addresses have the following
+ format:
+
+ | 8 | 4 | 4 | 112 bits |
+ +------ -+----+----+---------------------------------------------+
+ |11111111|flgs|scop| group ID |
+ +--------+----+----+---------------------------------------------+
+
+ binary 11111111 at the start of the address identifies the address
+ as being a multicast address.
+
+ +-+-+-+-+
+ flgs is a set of 4 flags: |0|R|P|T|
+ +-+-+-+-+
+
+ The high-order flag is reserved, and must be initialized to 0.
+
+ T = 0 indicates a permanently-assigned ("well-known") multicast
+ address, assigned by the Internet Assigned Numbers Authority
+ (IANA).
+
+ T = 1 indicates a non-permanently-assigned ("transient" or
+ "dynamically" assigned) multicast address.
+
+
+
+
+Hinden Standards Track [Page 13]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ The P flag's definition and usage can be found in [RFC3306].
+
+ The R flag's definition and usage can be found in [RFC3956].
+
+ scop is a 4-bit multicast scope value used to limit the scope of
+ the multicast group. The values are as follows:
+
+ 0 reserved
+ 1 Interface-Local scope
+ 2 Link-Local scope
+ 3 reserved
+ 4 Admin-Local scope
+ 5 Site-Local scope
+ 6 (unassigned)
+ 7 (unassigned)
+ 8 Organization-Local scope
+ 9 (unassigned)
+ A (unassigned)
+ B (unassigned)
+ C (unassigned)
+ D (unassigned)
+ E Global scope
+ F reserved
+
+ Interface-Local scope spans only a single interface on a node
+ and is useful only for loopback transmission of multicast.
+
+ Link-Local multicast scope spans the same topological region as
+ the corresponding unicast scope.
+
+ Admin-Local scope is the smallest scope that must be
+ administratively configured, i.e., not automatically derived
+ from physical connectivity or other, non-multicast-related
+ configuration.
+
+ Site-Local scope is intended to span a single site.
+
+ Organization-Local scope is intended to span multiple sites
+ belonging to a single organization.
+
+ scopes labeled "(unassigned)" are available for administrators
+ to define additional multicast regions.
+
+ group ID identifies the multicast group, either permanent or
+ transient, within the given scope. Additional definitions of the
+ multicast group ID field structure are provided in [RFC3306].
+
+
+
+
+
+Hinden Standards Track [Page 14]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ 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
+ 101 (hex), then
+
+ FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
+ (i.e., the same node) as the sender.
+
+ FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
+ sender.
+
+ FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the
+ sender.
+
+ FF0E:0:0:0:0:0:0:101 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:101 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 a different scope, nor to a permanent group with the same group
+ ID.
+
+ Multicast addresses must not be used as source addresses in IPv6
+ packets or appear in any Routing header.
+
+ Routers must not forward any multicast packets beyond of the scope
+ indicated by the scop field in the destination multicast address.
+
+ Nodes must not originate a packet to a multicast address whose scop
+ field contains the reserved value 0; if such a packet is received, it
+ must be silently dropped. Nodes should not originate a packet to a
+ multicast address whose scop field contains the reserved value F; if
+ such a packet is sent or received, it must be treated the same as
+ packets destined to a global (scop E) multicast address.
+
+2.7.1. Pre-Defined Multicast Addresses
+
+ The following well-known multicast addresses are pre-defined. The
+ group IDs defined in this section are defined for explicit scope
+ values.
+
+ Use of these group IDs for any other scope values, with the T flag
+ equal to 0, is not allowed.
+
+
+
+
+
+
+Hinden Standards Track [Page 15]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ 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
+ 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 (interface-local) or 2 (link-local).
+
+ All Routers Addresses: FF01:0:0:0:0:0:0:2
+ FF02:0:0:0:0:0:0:2
+ FF05:0:0:0:0:0:0:2
+
+ The above multicast addresses identify the group of all IPv6 routers,
+ within scope 1 (interface-local), 2 (link-local), or 5 (site-local).
+
+ Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX
+
+ Solicited-Node multicast address are computed as a function of a
+ node's unicast and anycast addresses. A Solicited-Node multicast
+ address is formed by taking the low-order 24 bits of an address
+ (unicast or anycast) and appending those bits to the prefix
+ FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
+ range
+
+ FF02:0:0:0:0:1:FF00:0000
+
+ to
+
+ FF02:0:0:0:0:1:FFFF:FFFF
+
+
+
+
+Hinden Standards Track [Page 16]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ For example, the Solicited-Node multicast address corresponding to
+ the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6
+ addresses that differ only in the high-order bits (e.g., due to
+ multiple high-order prefixes associated with different aggregations)
+ 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 join (on the appropriate interface)
+ the associated Solicited-Node multicast addresses for all unicast and
+ anycast addresses that have been configured for the node's interfaces
+ (manually or automatically).
+
+2.8. A Node's Required Addresses
+
+ A host is required to recognize the following addresses as
+ identifying itself:
+
+ o Its required Link-Local address for each interface.
+
+ o Any additional Unicast and Anycast addresses that have been
+ configured for the node's interfaces (manually or
+ automatically).
+
+ o The loopback address.
+
+ o The All-Nodes multicast addresses defined in Section 2.7.1.
+
+ o The Solicited-Node multicast address for each of its unicast and
+ anycast addresses.
+
+ o Multicast addresses of all other groups to which the node
+ belongs.
+
+ A router is required to recognize all addresses that a host is
+ required to recognize, plus the following addresses as identifying
+ itself:
+
+ o The Subnet-Router Anycast addresses for all interfaces for which
+ it is configured to act as a router.
+
+ o All other Anycast addresses with which the router has been
+ configured.
+
+ o The All-Routers multicast addresses defined in Section 2.7.1.
+
+
+
+
+
+
+
+Hinden Standards Track [Page 17]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+3. Security Considerations
+
+ IPv6 addressing documents do not have any direct impact on Internet
+ infrastructure security. Authentication of IPv6 packets is defined
+ in [AUTH].
+
+4. IANA Considerations
+
+ The "IPv4-Compatible IPv6 address" is deprecated by this document.
+ The IANA should continue to list the address block containing these
+ addresses at http://www.iana.org/assignments/ipv6-address-space as
+ "Reserved by IETF" and not reassign it for any other purpose. For
+ example:
+
+ 0000::/8 Reserved by IETF [RFC3513] [1]
+
+ The IANA has added the following note and link to this address block.
+
+ [5] 0000::/96 was previously defined as the "IPv4-Compatible IPv6
+ address" prefix. This definition has been deprecated by RFC
+ 4291.
+
+ The IANA has updated the references for the IPv6 Address Architecture
+ in the IANA registries accordingly.
+
+5. Acknowledgements
+
+ The authors would like to acknowledge the contributions of Paul
+ Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
+ Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
+ Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
+ Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
+ Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino,
+ Tatuya Jinmei, Suresh Krishnan, and Mahmood Ali.
+
+6. References
+
+6.1. Normative References
+
+ [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+6.2. Informative References
+
+ [AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
+ 2402, November 1998.
+
+
+
+
+
+Hinden Standards Track [Page 18]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ [CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
+ Inter-Domain Routing (CIDR): an Address Assignment and
+ Aggregation Strategy", RFC 1519, September 1993.
+
+ [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
+ Networks", RFC 2464, December 1998.
+
+ [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
+ Registration Authority",
+ http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
+ March 1997.
+
+ [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
+ Networks", RFC 2467, December 1998.
+
+ [GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
+ Unicast Address Format", RFC 3587, August 2003.
+
+ [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless
+ Address Autoconfiguration in IPv6", RFC 3041, January 2001.
+
+ [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
+ (IPv6) Addressing Architecture", RFC 3513, April 2005.
+
+ [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
+ Multicast Addresses", RFC 3306, August 2002.
+
+ [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point
+ (RP) Address in an IPv6 Multicast Address", RFC 3956,
+ November 2004.
+
+ [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+ Castro, "Application Aspects of IPv6 Transition", RFC 4038,
+ March 2005.
+
+ [SLDEP] Huitema, C. and B. Carpenter, "Deprecating Site Local
+ Addresses", RFC 3879, September 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden Standards Track [Page 19]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+Appendix A: Creating Modified EUI-64 Format Interface Identifiers
+
+ Depending on the characteristics of a specific link or node, there
+ are a number of approaches for creating Modified EUI-64 format
+ interface identifiers. This appendix describes some of these
+ approaches.
+
+ Links or Nodes with IEEE EUI-64 Identifiers
+
+ The only change needed to transform an IEEE EUI-64 identifier to an
+ interface identifier is to invert the "u" (universal/local) bit. An
+ example is a globally unique IEEE EUI-64 identifier of the form:
+
+ |0 1|1 3|3 4|4 6|
+ |0 5|6 1|2 7|8 3|
+ +----------------+----------------+----------------+----------------+
+ |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+ +----------------+----------------+----------------+----------------+
+
+ where "c" is the bits of the assigned company_id, "0" is the value of
+ the universal/local bit to indicate universal scope, "g" is
+ individual/group bit, and "m" is the bits of the manufacturer-
+ selected extension identifier. The IPv6 interface identifier would
+ be of the form:
+
+ |0 1|1 3|3 4|4 6|
+ |0 5|6 1|2 7|8 3|
+ +----------------+----------------+----------------+----------------+
+ |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+ +----------------+----------------+----------------+----------------+
+
+ The only change is inverting the value of the universal/local bit.
+
+ Links or Nodes with IEEE 802 48-bit MACs
+
+ [EUI64] defines a method to create an IEEE EUI-64 identifier from an
+ IEEE 48-bit MAC identifier. This is to insert two octets, with
+ hexadecimal values of 0xFF and 0xFE (see the Note at the end of
+ appendix), in the middle of the 48-bit MAC (between the company_id
+ and vendor-supplied id). An example is the 48-bit IEEE MAC with
+ Global scope:
+
+ |0 1|1 3|3 4|
+ |0 5|6 1|2 7|
+ +----------------+----------------+----------------+
+ |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
+ +----------------+----------------+----------------+
+
+
+
+
+Hinden Standards Track [Page 20]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ where "c" is the bits of the assigned company_id, "0" is the value of
+ the universal/local bit to indicate Global scope, "g" is
+ individual/group bit, and "m" is the bits of the manufacturer-
+ selected extension identifier. The interface identifier would be of
+ the form:
+
+ |0 1|1 3|3 4|4 6|
+ |0 5|6 1|2 7|8 3|
+ +----------------+----------------+----------------+----------------+
+ |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+ +----------------+----------------+----------------+----------------+
+
+ When IEEE 802 48-bit MAC addresses are available (on an interface or
+ a node), an implementation may use them to create interface
+ identifiers due to their availability and uniqueness properties.
+
+ Links with Other Kinds of Identifiers
+
+ There are a number of types of links that have link-layer interface
+ identifiers other than IEEE EUI-64 or IEEE 802 48-bit MACs. Examples
+ include LocalTalk and Arcnet. The method to create a Modified EUI-64
+ format identifier is to take the link identifier (e.g., the LocalTalk
+ 8-bit node identifier) and zero fill it to the left. For example, a
+ LocalTalk 8-bit node identifier of hexadecimal value 0x4F results in
+ the following interface identifier:
+
+ |0 1|1 3|3 4|4 6|
+ |0 5|6 1|2 7|8 3|
+ +----------------+----------------+----------------+----------------+
+ |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
+ +----------------+----------------+----------------+----------------+
+
+ Note that this results in the universal/local bit set to "0" to
+ indicate local scope.
+
+ Links without Identifiers
+
+ There are a number of links that do not have any type of built-in
+ identifier. The most common of these are serial links and configured
+ tunnels. Interface identifiers that are unique within a subnet
+ prefix must be chosen.
+
+ When no built-in identifier is available on a link, the preferred
+ approach is to use a universal interface identifier from another
+ interface or one that is assigned to the node itself. When using
+ this approach, no other interface connecting the same node to the
+ same subnet prefix may use the same identifier.
+
+
+
+
+Hinden Standards Track [Page 21]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ If there is no universal interface identifier available for use on
+ the link, the implementation needs to create a local-scope interface
+ identifier. The only requirement is that it be unique within a
+ subnet prefix. There are many possible approaches to select a
+ subnet-prefix-unique interface identifier. These include the
+ following:
+
+ Manual Configuration
+ Node Serial Number
+ Other Node-Specific Token
+
+ The subnet-prefix-unique interface identifier should be generated in
+ a manner such that it does not change after a reboot of a node or if
+ interfaces are added or deleted from the node.
+
+ The selection of the appropriate algorithm is link and implementation
+ dependent. The details on forming interface identifiers are defined
+ in the appropriate "IPv6 over <link>" specification. It is strongly
+ recommended that a collision detection algorithm be implemented as
+ part of any automatic algorithm.
+
+ Note: [EUI-64] actually defines 0xFF and 0xFF as the bits to be
+ inserted to create an IEEE EUI-64 identifier from an IEEE MAC-
+ 48 identifier. The 0xFF and 0xFE values are used when starting
+ with an IEEE EUI-48 identifier. The incorrect value was used
+ in earlier versions of the specification due to a
+ misunderstanding about the differences between IEEE MAC-48 and
+ EUI-48 identifiers.
+
+ This document purposely continues the use of 0xFF and 0xFE
+ because it meets the requirements for IPv6 interface
+ identifiers (i.e., that they must be unique on the link), IEEE
+ EUI-48 and MAC-48 identifiers are syntactically equivalent, and
+ that it doesn't cause any problems in practice.
+
+Appendix B: Changes from RFC 3513
+
+ The following changes were made from RFC 3513, "IP Version 6
+ Addressing Architecture":
+
+ o The restrictions on using IPv6 anycast addresses were removed
+ because there is now sufficient experience with the use of anycast
+ addresses, the issues are not specific to IPv6, and the GROW
+ working group is working in this area.
+
+ o Deprecated the Site-Local unicast prefix. Changes include the
+ following:
+
+
+
+
+Hinden Standards Track [Page 22]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+ - Removed Site-Local from special list of prefixes in Section
+ 2.4.
+
+ - Split section titled "Local-use IPv6 Unicast Addresses" into
+ two sections, "Link-Local IPv6 Unicast Addresses" and "Site-
+ Local IPv6 Unicast Addresses".
+
+ - Added text to new section describing Site-Local deprecation.
+
+ o Changes to resolve issues raised in IAB response to Robert Elz
+ appeal. Changes include the following:
+
+ - Added clarification to Section 2.5 that nodes should make no
+ assumptions about the structure of an IPv6 address.
+
+ - Changed the text in Section 2.5.1 and Appendix A to refer to
+ the Modified EUI-64 format interface identifiers with the "u"
+ bit set to one (1) as universal.
+
+ - Added clarification to Section 2.5.1 that IPv6 nodes are not
+ required to validate that interface identifiers created in
+ Modified EUI-64 format with the "u" bit set to one are unique.
+
+ o Changed the reference indicated in Section 2.5.4 "Global Unicast
+ Addresses" to RFC 3587.
+
+ o Removed mention of NSAP addresses in examples.
+
+ o Clarified that the "x" in the textual representation can be one to
+ four digits.
+
+ o Deprecated the "IPv6 Compatible Address" because it is not being
+ used in the IPv6 transition mechanisms.
+
+ o Added the "R" and "P" flags to Section 2.7 on multicast addresses,
+ and pointers to the documents that define them.
+
+ o Editorial changes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden Standards Track [Page 23]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+Authors' Addresses
+
+ Robert M. Hinden
+ Nokia
+ 313 Fairchild Drive
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 650 625-2004
+ EMail: bob.hinden@nokia.com
+
+
+ Stephen E. Deering
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134-1706
+ USA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden Standards Track [Page 24]
+
+RFC 4291 IPv6 Addressing Architecture February 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Hinden Standards Track [Page 25]
+