diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2373.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2373.txt | 1459 |
1 files changed, 0 insertions, 1459 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2373.txt b/contrib/bind9/doc/rfc/rfc2373.txt deleted file mode 100644 index 59fcff8..0000000 --- a/contrib/bind9/doc/rfc/rfc2373.txt +++ /dev/null @@ -1,1459 +0,0 @@ - - - - - - -Network Working Group R. Hinden -Request for Comments: 2373 Nokia -Obsoletes: 1884 S. Deering -Category: Standards Track Cisco Systems - July 1998 - - 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 (1998). All Rights Reserved. - -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 node's required addresses. - -Table of Contents - - 1. Introduction.................................................2 - 2. IPv6 Addressing..............................................2 - 2.1 Addressing Model.........................................3 - 2.2 Text Representation of Addresses.........................3 - 2.3 Text Representation of Address Prefixes..................5 - 2.4 Address Type Representation..............................6 - 2.5 Unicast Addresses........................................7 - 2.5.1 Interface Identifiers................................8 - 2.5.2 The Unspecified Address..............................9 - 2.5.3 The Loopback Address.................................9 - 2.5.4 IPv6 Addresses with Embedded IPv4 Addresses.........10 - 2.5.5 NSAP Addresses......................................10 - 2.5.6 IPX Addresses.......................................10 - 2.5.7 Aggregatable Global Unicast Addresses...............11 - 2.5.8 Local-use IPv6 Unicast Addresses....................11 - 2.6 Anycast Addresses.......................................12 - 2.6.1 Required Anycast Address............................13 - 2.7 Multicast Addresses.....................................14 - - - -Hinden & Deering Standards Track [Page 1] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - 2.7.1 Pre-Defined Multicast Addresses.....................15 - 2.7.2 Assignment of New IPv6 Multicast Addresses..........17 - 2.8 A Node's Required Addresses.............................17 - 3. Security Considerations.....................................18 - APPENDIX A: Creating EUI-64 based Interface Identifiers........19 - APPENDIX B: ABNF Description of Text Representations...........22 - APPENDIX C: CHANGES FROM RFC-1884..............................23 - REFERENCES.....................................................24 - AUTHORS' ADDRESSES.............................................25 - FULL COPYRIGHT STATEMENT.......................................26 - - -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 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, - and Sue Thomson. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - -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. - - - -Hinden & Deering Standards Track [Page 2] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - 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. - -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 be assigned multiple IPv6 addresses of any - type (unicast, anycast, and multicast) or scope. Unicast addresses - with 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: - - An 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. - - Currently IPv6 continues the IPv4 model 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 the - hexadecimal values of the eight 16-bit pieces of the address. - Examples: - - - -Hinden & Deering Standards Track [Page 3] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - 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 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 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: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 addresses - - may be represented as: - - 1080::8:800:200C:417A a unicast address - FF01::101 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 - - - - - -Hinden & Deering Standards Track [Page 4] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -2.3 Text Representation of Address Prefixes - - The text representation of IPv6 address prefixes is similar to the - way IPv4 addresses prefixes are written in CIDR notation. 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 12AB00000000CD3 (hexadecimal): - - 12AB:0000:0000:CD30:0000:0000:0000:0000/60 - 12AB::CD30:0:0:0:0/60 - 12AB:0:0:CD30::/60 - - The following are NOT legal representations of the above prefix: - - 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, - within any 16-bit chunk of the address - - 12AB::CD30/60 address to left of "/" expands to - 12AB:0000:0000:0000:0000:000:0000:CD30 - - 12AB::CD3/60 address to left of "/" expands to - 12AB:0000:0000:0000:0000:000:0000:0CD3 - - When writing both a node address and a prefix of that node address - (e.g., the node's subnet prefix), the two can combined as follows: - - the node address 12AB:0:0:CD30:123:4567:89AB:CDEF - and its subnet number 12AB:0:0:CD30::/60 - - can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 - - - - - - - - - -Hinden & Deering Standards Track [Page 5] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -2.4 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: - - 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 - - Aggregatable Global Unicast Addresses 001 1/8 - Unassigned 010 1/8 - Unassigned 011 1/8 - Unassigned 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 Unicast Addresses 1111 1110 10 1/1024 - Site-Local Unicast Addresses 1111 1110 11 1/1024 - - Multicast Addresses 1111 1111 1/256 - - Notes: - - (1) The "unspecified address" (see section 2.5.2), the loopback - address (see section 2.5.3), and the IPv6 Addresses with - Embedded IPv4 Addresses (see section 2.5.4), are assigned out - of the 0000 0000 format prefix space. - - - - - - - -Hinden & Deering Standards Track [Page 6] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - (2) The format prefixes 001 through 111, except for Multicast - Addresses (1111 1111), are all required to have to have 64-bit - interface identifiers in EUI-64 format. See section 2.5.1 for - definitions. - - This allocation supports the direct allocation of aggregation - addresses, local use addresses, and multicast addresses. Space is - reserved for NSAP addresses and IPX addresses. The remainder of the - address space is unassigned for future use. This can be used for - expansion of existing use (e.g., additional aggregatable addresses, - etc.) or new uses (e.g., separate locators and identifiers). Fifteen - percent of the address space is initially 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.5 Unicast Addresses - - IPv6 unicast addresses are aggregatable with contiguous bit-wise - masks similar to IPv4 addresses under Class-less Interdomain Routing - [CIDR]. - - There are several forms of unicast address assignment in IPv6, - including the global aggregatable global unicast address, the NSAP - address, the IPX hierarchical address, the site-local address, the - link-local 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: - - - -Hinden & Deering Standards Track [Page 7] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - | 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 - 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.5.1 Interface Identifiers - - Interface identifiers in IPv6 unicast addresses are used to identify - interfaces on a link. They are required to be unique on that link. - They may also be unique over a broader scope. In many cases an - interface's identifier will be the same as that interface's link- - layer address. The same interface identifier may be used on multiple - interfaces on a single node. - - Note that the use of the same interface identifier on multiple - interfaces of a single node does not affect the interface - identifier's global uniqueness or each IPv6 addresses global - uniqueness created using that interface identifier. - - In a number of the format prefixes (see section 2.4) Interface IDs - are required to be 64 bits long and to be constructed in IEEE EUI-64 - format [EUI64]. EUI-64 based Interface identifiers may have global - scope when a global token is available (e.g., IEEE 48bit MAC) or may - have local scope where a global token is not available (e.g., serial - links, tunnel end-points, etc.). It is required that the "u" bit - (universal/local bit in IEEE EUI-64 terminology) be inverted when - forming the interface identifier from the EUI-64. The "u" bit is set - to one (1) to indicate global scope, and it is set to zero (0) to - indicate local scope. The first three octets in binary of an EUI-64 - identifier are as follows: - - 0 0 0 1 1 2 - |0 7 8 5 6 3| - +----+----+----+----+----+----+ - |cccc|ccug|cccc|cccc|cccc|cccc| - +----+----+----+----+----+----+ - - - - - - -Hinden & Deering Standards Track [Page 8] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - written in Internet standard bit-order , where "u" is the - universal/local bit, "g" is the individual/group bit, and "c" are the - bits of the company_id. Appendix A: "Creating EUI-64 based Interface - Identifiers" provides examples on the creation of different EUI-64 - based interface identifiers. - - The motivation for inverting the "u" bit when forming the interface - identifier is to make it easy for system administrators to hand - configure local scope identifiers when hardware tokens are not - available. This is expected to be case for serial links, tunnel end- - points, etc. 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 ::1, - ::2, etc. - - The use of the universal/local bit in the IEEE EUI-64 identifier is - to allow development of future technology that can take advantage of - interface identifiers with global scope. - - The details of forming interface identifiers are defined in the - appropriate "IPv6 over <link>" specification such as "IPv6 over - Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. - -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. - -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 may - never be assigned to any physical interface. It may be thought of as - being associated with a virtual interface (e.g., the loopback - interface). - - 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. - - - - - - -Hinden & Deering Standards Track [Page 9] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -2.5.4 IPv6 Addresses with Embedded IPv4 Addresses - - The IPv6 transition mechanisms [TRAN] 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: - - | 80 bits | 16 | 32 bits | - +--------------------------------------+--------------------------+ - |0000..............................0000|FFFF| IPv4 address | - +--------------------------------------+----+---------------------+ - -2.5.5 NSAP Addresses - - This mapping of NSAP address into IPv6 addresses is defined in - [NSAP]. This document recommends that network implementors who have - planned or deployed an OSI NSAP addressing plan, and who wish to - deploy or transition to IPv6, should redesign a native IPv6 - addressing plan to meet their needs. However, it also defines a set - of mechanisms for the support of OSI NSAP addressing in an IPv6 - network. These mechanisms are the ones that must be used if such - support is required. This document also defines a mapping of IPv6 - addresses within the OSI address format, should this be required. - -2.5.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. - - - - -Hinden & Deering Standards Track [Page 10] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -2.5.7 Aggregatable Global Unicast Addresses - - The global aggregatable global unicast address is defined in [AGGR]. - This address format is designed to support both the current provider - based aggregation and a new type of aggregation called exchanges. - The combination will allow efficient routing aggregation for both - sites which connect directly to providers and who connect to - exchanges. Sites will have the choice to connect to either type of - aggregation point. - - The IPv6 aggregatable global unicast address format is as follows: - - | 3| 13 | 8 | 24 | 16 | 64 bits | - +--+-----+---+--------+--------+--------------------------------+ - |FP| TLA |RES| NLA | SLA | Interface ID | - | | ID | | ID | ID | | - +--+-----+---+--------+--------+--------------------------------+ - - Where - - 001 Format Prefix (3 bit) for Aggregatable Global - Unicast Addresses - TLA ID Top-Level Aggregation Identifier - RES Reserved for future use - NLA ID Next-Level Aggregation Identifier - SLA ID Site-Level Aggregation Identifier - INTERFACE ID Interface Identifier - - The contents, field sizes, and assignment rules are defined in - [AGGR]. - -2.5.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 | 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 auto-address configuration, neighbor - discovery, or when no routers are present. - - - - -Hinden & Deering Standards Track [Page 11] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - Routers must not forward any packets with link-local source or - destination addresses to other links. - - Site-Local addresses have the following format: - - | 10 | - | bits | 38 bits | 16 bits | 64 bits | - +----------+-------------+-----------+----------------------------+ - |1111111011| 0 | subnet ID | interface ID | - +----------+-------------+-----------+----------------------------+ - - Site-Local addresses are designed to be used for addressing inside of - a site without the need for a global prefix. - - Routers must not forward any packets with site-local source or - destination addresses outside of the site. - -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 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 - separate routing entry throughout the entire internet, which presents - - - - - -Hinden & Deering Standards Track [Page 12] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - 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 - aggregation or sequence of aggregations. 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.6.1 Required Anycast Address - - The Subnet-Router anycast address is predefined. Its 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 2373 IPv6 Addressing Architecture July 1998 - - - 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 its "home" subnet. - -2.7 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) - B (unassigned) - C (unassigned) - - - -Hinden & Deering Standards Track [Page 14] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - 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 - 101 (hex), then: - - FF01:0:0:0:0:0:0:101 means all NTP servers on 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 at 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 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. - -2.7.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 - FF07:0:0:0:0:0:0:0 - FF08:0:0:0:0:0:0:0 - FF09:0:0:0:0:0:0:0 - - - -Hinden & Deering Standards Track [Page 15] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - 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 - FF05:0:0:0:0:0:0:2 - - The above multicast addresses identify the group of all IPv6 routers, - within scope 1 (node-local), 2 (link-local), or 5 (site-local). - - Solicited-Node Address: FF02:0:0:0:0:1:FFXX: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 24 bits of the 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 - - 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 the associated Solicited-Node - multicast addresses for every unicast and anycast address it is - assigned. - - - -Hinden & Deering Standards Track [Page 16] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -2.7.2 Assignment of New IPv6 Multicast Addresses - - The current approach [ETHER] to map IPv6 multicast addresses into - IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 - multicast address and uses it to create a MAC address. Note that - Token Ring networks are handled differently. This is defined in - [TOKEN]. Group ID's less than or equal to 32 bits will generate - unique MAC addresses. Due to this new IPv6 multicast addresses - should be assigned so that the group identifier is always in the low - order 32 bits as shown in the following: - - | 8 | 4 | 4 | 80 bits | 32 bits | - +------ -+----+----+---------------------------+-----------------+ - |11111111|flgs|scop| reserved must be zero | group ID | - +--------+----+----+---------------------------+-----------------+ - - While this limits the number of permanent IPv6 multicast groups to - 2^32 this is unlikely to be a limitation in the future. If it - becomes necessary to exceed this limit in the future multicast will - still work but the processing will be sightly slower. - - Additional IPv6 multicast addresses are defined and registered by the - IANA [MASGN]. - -2.8 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 Addresses - o Solicited-Node Multicast Address for each of its assigned - unicast and anycast addresses - o Multicast Addresses of all other groups to which the host - 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 the interfaces it is - configured to act as a router on. - o All other Anycast addresses with which the router has been - configured. - o All-Routers Multicast Addresses - - - - -Hinden & Deering Standards Track [Page 17] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - o Multicast Addresses of all other groups to 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). - -3. Security Considerations - - IPv6 addressing documents do not have any direct impact on Internet - infrastructure security. Authentication of IPv6 packets is defined - in [AUTH]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 18] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -APPENDIX A : Creating EUI-64 based Interface Identifiers --------------------------------------------------------- - - Depending on the characteristics of a specific link or node there are - a number of approaches for creating EUI-64 based interface - identifiers. This appendix describes some of these approaches. - -Links or Nodes with EUI-64 Identifiers - - The only change needed to transform an EUI-64 identifier to an - interface identifier is to invert the "u" (universal/local) bit. For - example, a globally unique 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" are 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" are 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 MAC's - - [EUI64] defines a method to create a EUI-64 identifier from an IEEE - 48bit MAC identifier. This is to insert two octets, with hexadecimal - values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the - company_id and vendor supplied id). For example the 48 bit MAC with - global scope: - - |0 1|1 3|3 4| - |0 5|6 1|2 7| - +----------------+----------------+----------------+ - |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+ - - - - - -Hinden & Deering Standards Track [Page 19] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - where "c" are 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" are 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 48bit MAC addresses are available (on an interface or a - node), an implementation should use them to create interface - identifiers due to their availability and uniqueness properties. - -Links with Non-Global Identifiers - - There are a number of types of links that, while multi-access, do not - have globally unique link identifiers. Examples include LocalTalk - and Arcnet. The method to create an EUI-64 formatted 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 must be chosen that are unique for - the link. - - When no built-in identifier is available on a link the preferred - approach is to use a global interface identifier from another - interface or one which is assigned to the node itself. To use this - approach no other interface connecting the same node to the same link - may use the same identifier. - - - - -Hinden & Deering Standards Track [Page 20] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - If there is no global 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 on the link. - There are many possible approaches to select a link-unique interface - identifier. They include: - - Manual Configuration - Generated Random Number - Node Serial Number (or other node-specific token) - - The link-unique interface identifier should be generated in a manner - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 21] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -APPENDIX B: ABNF Description of Text Representations ----------------------------------------------------- - - This appendix defines the text representation of IPv6 addresses and - prefixes in Augmented BNF [ABNF] for reference purposes. - - IPv6address = hexpart [ ":" IPv4address ] - IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT - - IPv6prefix = hexpart "/" 1*2DIGIT - - hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] - hexseq = hex4 *( ":" hex4) - hex4 = 1*4HEXDIG - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 22] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -APPENDIX C: CHANGES FROM RFC-1884 ---------------------------------- - - The following changes were made from RFC-1884 "IP Version 6 - Addressing Architecture": - - - Added an appendix providing a ABNF description of text - representations. - - Clarification that link unique identifiers not change after - reboot or other interface reconfigurations. - - Clarification of Address Model based on comments. - - Changed aggregation format terminology to be consistent with - aggregation draft. - - Added text to allow interface identifier to be used on more than - one interface on same node. - - Added rules for defining new multicast addresses. - - Added appendix describing procedures for creating EUI-64 based - interface ID's. - - Added notation for defining IPv6 prefixes. - - Changed solicited node multicast definition to use a longer - prefix. - - Added site scope all routers multicast address. - - Defined Aggregatable Global Unicast Addresses to use "001" Format - Prefix. - - Changed "010" (Provider-Based Unicast) and "100" (Reserved for - Geographic) Format Prefixes to Unassigned. - - Added section on Interface ID definition for unicast addresses. - Requires use of EUI-64 in range of format prefixes and rules for - setting global/local scope bit in EUI-64. - - Updated NSAP text to reflect working in RFC1888. - - Removed protocol specific IPv6 multicast addresses (e.g., DHCP) - and referenced the IANA definitions. - - Removed section "Unicast Address Example". Had become OBE. - - Added new and updated references. - - Minor text clarifications and improvements. - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 23] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -REFERENCES - - [ABNF] Crocker, D., and P. Overell, "Augmented BNF for - Syntax Specifications: ABNF", RFC 2234, November 1997. - - [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An - Aggregatable Global Unicast Address Format", RFC 2374, July - 1998. - - [AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August - 1995. - - [ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host - Anycasting Service", RFC 1546, November 1993. - - [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 Pacekts over Ethernet - Networks", Work in Progress. - - [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) - Registration Authority", - http://standards.ieee.org/db/oui/tutorials/EUI64.html, - March 1997. - - [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI - Networks", Work in Progress. - - [IPV6] Deering, S., and R. Hinden, Editors, "Internet Protocol, - Version 6 (IPv6) Specification", RFC 1883, December 1995. - - [MASGN] Hinden, R., and S. Deering, "IPv6 Multicast Address - Assignments", RFC 2375, July 1998. - - [NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J., - and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [TOKEN] Thomas, S., "Transmission of IPv6 Packets over Token Ring - Networks", Work in Progress. - - [TRAN] Gilligan, R., and E. Nordmark, "Transition Mechanisms for - IPv6 Hosts and Routers", RFC 1993, April 1996. - - - - -Hinden & Deering Standards Track [Page 24] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -AUTHORS' ADDRESSES - - Robert M. Hinden - Nokia - 232 Java Drive - Sunnyvale, CA 94089 - USA - - Phone: +1 408 990-2004 - Fax: +1 408 743-5677 - EMail: hinden@iprg.nokia.com - - - Stephen E. Deering - Cisco Systems, Inc. - 170 West Tasman Drive - San Jose, CA 95134-1706 - USA - - Phone: +1 408 527-8213 - Fax: +1 408 527-8254 - EMail: deering@cisco.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 25] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 26] - |
