--- 1/draft-ietf-6man-rfc4291bis-07.txt 2017-06-20 05:15:27.675388213 -0700 +++ 2/draft-ietf-6man-rfc4291bis-08.txt 2017-06-20 05:15:27.751390031 -0700 @@ -1,19 +1,19 @@ Network Working Group R. Hinden Internet-Draft Check Point Software Obsoletes: 4291 (if approved) S. Deering Intended status: Standards Track Retired -Expires: August 4, 2017 January 31, 2017 +Expires: December 22, 2017 June 20, 2017 IP Version 6 Addressing Architecture - draft-ietf-6man-rfc4291bis-07 + draft-ietf-6man-rfc4291bis-08 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 4291, "IP Version 6 Addressing @@ -27,21 +27,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 4, 2017. + This Internet-Draft will expire on December 22, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -63,49 +63,49 @@ it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Addressing Model . . . . . . . . . . . . . . . . . . . . 4 2.2. Text Representation of IPv6 Addresses . . . . . . . . . . 4 2.2.1. Text Representation of Addresses . . . . . . . . . . 4 - 2.2.2. Text Representation of Address Prefixes . . . . . . . 5 + 2.2.2. Text Representation of Address Prefixes . . . . . . . 6 2.2.3. Recommendation for outputting IPv6 addresses . . . . 7 2.3. Address Type Identification . . . . . . . . . . . . . . . 9 2.4. Unicast Addresses . . . . . . . . . . . . . . . . . . . . 10 2.4.1. Interface Identifiers . . . . . . . . . . . . . . . . 11 2.4.2. The Unspecified Address . . . . . . . . . . . . . . . 12 2.4.3. The Loopback Address . . . . . . . . . . . . . . . . 12 - 2.4.4. Global Unicast Addresses . . . . . . . . . . . . . . 12 + 2.4.4. Global Unicast Addresses . . . . . . . . . . . . . . 13 2.4.5. IPv6 Addresses with Embedded IPv4 Addresses . . . . . 13 2.4.5.1. IPv4-Compatible IPv6 Address . . . . . . . . . . 13 - 2.4.5.2. IPv4-Mapped IPv6 Address . . . . . . . . . . . . 13 + 2.4.5.2. IPv4-Mapped IPv6 Address . . . . . . . . . . . . 14 2.4.6. Link-Local IPv6 Unicast Addresses . . . . . . . . . . 14 2.4.7. Other Local Unicast IPv6 Addresses . . . . . . . . . 14 - 2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . . . 14 + 2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . . . 15 2.5.1. Required Anycast Address . . . . . . . . . . . . . . 15 2.6. Multicast Addresses . . . . . . . . . . . . . . . . . . . 16 2.6.1. Pre-Defined Multicast Addresses . . . . . . . . . . . 19 2.7. A Node's Required Addresses . . . . . . . . . . . . . . . 20 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Normative References . . . . . . . . . . . . . . . . . . 23 6.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Modified EUI-64 Format Interface Identifiers . . . . 26 - A.1. Creating Modified EUI-64 Format Interface Identifiers . . 27 + A.1. Creating Modified EUI-64 Format Interface Identifiers . . 26 Appendix B. CHANGES SINCE RFC 4291 . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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 @@ -131,20 +131,25 @@ 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. + Note: The term "prefix" is used in several different contexts for + IPv6: a prefix used by a routing protocol, a prefix used by a node + to determine if another node is connected to the same link, and a + prefix used to construct the complete address of a node. + 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. @@ -392,47 +397,42 @@ registry [IANA-AD] and the IANA IPv6 Special-Purpose Address Registry [IANA-SP]. 2.4. Unicast Addresses IPv6 unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv4 addresses under Classless Inter-Domain Routing. IPv6 unicast routing is based on prefixes of any valid length up to - 128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes - on inter-router point-to-point links. However, the Interface ID of - all unicast addresses, except those that start with the binary value - 000, is required to be 64 bits long. The rationale for the 64 bit - boundary in IPv6 addresses can be found in [RFC7421] + 128 [BCP198]. There are several types of unicast addresses in IPv6, in particular, Global Unicast, Local unicast, 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. 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: + A slightly more complex host 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 @@ -455,23 +455,31 @@ Interface IDs must be viewed outside of the node that created Interface ID as an opaque bit string without any internal structure. 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 an interface identifier that is only unique on a single subnet, and a Link-Local address may be created with interface identifier that is unique over multiple subnets. - As noted in Section 2.4, all unicast addresses, except those that - start with the binary value 000, Interface IDs are required to be 64 - bits long. + Interface Identifiers are 64 bit long except if the first three bits + of the address are 000, or when the addresses are manually + configured, or by exceptions defined in standards track documents. + The rationale for using 64 bit Interface Identifiers can be found in + [RFC7421]. An example of a standards track exception is [RFC6164] + that standardises 127 bit prefixes on inter-router point-to-point + links. + + Note: In the case of manual configuration, the Prefix and + Interface Identifier can be any length as long as they add up to + 128. The details of forming interface identifiers are defined in other specifications, such as "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)"[RFC7217]. Specific cases are described in appropriate "IPv6 over " specifications, such as "IPv6 over Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T G.9959 Networks" [RFC7428]. The security and privacy considerations for IPv6 address generation is described in [RFC7721]. @@ -517,26 +525,20 @@ | 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.4.1. - As noted in Section 2.4, 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.4.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.4.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 [RFC3587]. 2.4.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 @@ -921,34 +924,29 @@ o IPv6 Multicast Address Space Registry [IANA-MC] o Application for an IPv6 Multicast Address [IANA-MA] o Internet Protocol Version 6 (IPv6) Anycast Addresses [IANA-AC] o IANA IPv6 Special-Purpose Address Registry [IANA-SP] o Reserved IPv6 Interface Identifiers [IANA-ID] - o Number Resources [IANA-NR] o Protocol Registries [IANA-PR] o Technical requirements for authoritative name servers [IANA-NS] o IP Flow Information Export (IPFIX) Entities [IANA-FE] The IANA should update these references to point to this document. - There is a reference to RFC4291 (and RFC3307) that appears to be - incorrect and should be removed in: - - o Modify a Port Number assignment [IANA-PN] There are also other references in IANA procedures documents that the IANA should investigate to see if they should be updated. 4. Security Considerations IPv6 addressing documents do not have any direct impact on Internet infrastructure security. Authentication of IPv6 packets is defined in [RFC4302]. @@ -980,22 +978,22 @@ Congxiao Bao, Mohamed Boucadair, Brian Carpenter, Ralph Droms, Christian Huitema, Sheng Jiang, Seiichi Kawamura, Masanobu Kawashima, Xing Li, and Stig Venaas. 6. References 6.1. Normative References [I-D.ietf-6man-rfc2460bis] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", draft-ietf-6man-rfc2460bis-08 (work - in progress), November 2016. + (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work + in progress), May 2017. 6.2. Informative References [BCP198] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, RFC 7608, DOI 10.17487/RFC7608, July 2015, . [EUI64] "IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority"", March 1997, @@ -1026,23 +1024,20 @@ [IANA-MC] "IPv6 Multicast Address Space Registry", . [IANA-NR] "Number Resources", . [IANA-NS] "Technical requirements for authoritative name servers", . - [IANA-PN] "Modify a Port Number assignment", - . - [IANA-PR] "Protocol Registries", . [IANA-SP] "IANA IPv6 Special-Purpose Address Registry", . [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, . @@ -1299,20 +1295,40 @@ and that it doesn't cause any problems in practice. Appendix B. CHANGES SINCE RFC 4291 This document has the following changes from RFC4291, "IP Version 6 Addressing Architecture". Numbers identify the Internet-Draft version that the change was made.: Working Group Internet Drafts + 08) Added Note: to Section 2 that the term "prefix" is used in + different contexts in IPv6: a prefix used by a routing + protocol, a prefix used by a node to determine if another + node is connected to the same link, and a prefix used to + construct the complete address of a node. + + 08) Based on results of IETF last call and extensive w.g. list + discussion, revised text to clarify that 64 bit Interface IDs + are used except when the first three bits of the address are + 000, or addresses are manually configured, or when defined by + a standard track document. This text was moved from + Section 2.4 and is now consolidated in Section 2.4.1 Also + removed text in Section 2.4.4 relating to 64 bit Interface + IDs. + + 08) Removed instruction to IANA fix error in Port Number + assignment. IANA fixed the error on 4 March 2017. + + 08) Editorial changes. + 07) Added text to Section 2.4 summarizing IPv6 unicast routing and referencing BCP198, citing RFC6164 as an example of longer prefixes, and that IIDs are required to be 64 bits long as described in RFC7421. 07) Based on review by Brian Haberman added reference to RFC5952 in Section 2.2.3, corrected case errors in Section 2.6.1, and added a reference to the IANA Multicast address registry in Section 2.6.1.