draft-ietf-6man-rfc4291bis-08.txt   draft-ietf-6man-rfc4291bis-09.txt 
Network Working Group R. Hinden Network Working Group R. Hinden
Internet-Draft Check Point Software Internet-Draft Check Point Software
Obsoletes: 4291 (if approved) S. Deering Obsoletes: 4291 (if approved) S. Deering
Intended status: Standards Track Retired Intended status: Standards Track Retired
Expires: December 22, 2017 June 20, 2017 Expires: January 4, 2018 July 3, 2017
IP Version 6 Addressing Architecture IP Version 6 Addressing Architecture
draft-ietf-6man-rfc4291bis-08 draft-ietf-6man-rfc4291bis-09
Abstract Abstract
This specification defines the addressing architecture of the IP This specification defines the addressing architecture of the IP
Version 6 (IPv6) protocol. The document includes the IPv6 addressing Version 6 (IPv6) protocol. The document includes the IPv6 addressing
model, text representations of IPv6 addresses, definition of IPv6 model, text representations of IPv6 addresses, definition of IPv6
unicast addresses, anycast addresses, and multicast addresses, and an unicast addresses, anycast addresses, and multicast addresses, and an
IPv6 node's required addresses. IPv6 node's required addresses.
This document obsoletes RFC 4291, "IP Version 6 Addressing This document obsoletes RFC 4291, "IP Version 6 Addressing
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 22, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 6 skipping to change at page 3, line 6
2.6.1. Pre-Defined Multicast Addresses . . . . . . . . . . . 19 2.6.1. Pre-Defined Multicast Addresses . . . . . . . . . . . 19
2.7. A Node's Required Addresses . . . . . . . . . . . . . . . 20 2.7. A Node's Required Addresses . . . . . . . . . . . . . . . 20
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Normative References . . . . . . . . . . . . . . . . . . 23 6.1. Normative References . . . . . . . . . . . . . . . . . . 23
6.2. Informative References . . . . . . . . . . . . . . . . . 23 6.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Modified EUI-64 Format Interface Identifiers . . . . 26 Appendix A. Modified EUI-64 Format Interface Identifiers . . . . 26
A.1. Creating Modified EUI-64 Format Interface Identifiers . . 26 A.1. Creating Modified EUI-64 Format Interface Identifiers . . 27
Appendix B. CHANGES SINCE RFC 4291 . . . . . . . . . . . . . . . 29 Appendix B. CHANGES SINCE RFC 4291 . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 B.1. Change History Since RFC4291 . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
This specification defines the addressing architecture of the IP This specification defines the addressing architecture of the IP
Version 6 protocol. It includes the basic formats for the various Version 6 protocol. It includes the basic formats for the various
types of IPv6 addresses (unicast, anycast, and multicast). types of IPv6 addresses (unicast, anycast, and multicast).
2. IPv6 Addressing 2. IPv6 Addressing
IPv6 addresses are 128-bit identifiers for interfaces and sets of IPv6 addresses are 128-bit identifiers for interfaces and sets of
skipping to change at page 4, line 35 skipping to change at page 4, line 35
interfaces. There is one exception to this addressing model: interfaces. There is one exception to this addressing model:
A unicast address or a set of unicast addresses may be assigned to A unicast address or a set of unicast addresses may be assigned to
multiple physical interfaces if the implementation treats the multiple physical interfaces if the implementation treats the
multiple physical interfaces as one interface when presenting it multiple physical interfaces as one interface when presenting it
to the internet layer. This is useful for load-sharing over to the internet layer. This is useful for load-sharing over
multiple physical interfaces. multiple physical interfaces.
Currently, IPv6 continues the IPv4 model in that a subnet prefix is Currently, IPv6 continues the IPv4 model in that a subnet prefix is
associated with one link. Multiple subnet prefixes may be assigned associated with one link. Multiple subnet prefixes may be assigned
to the same link. to the same link. The relationship between links and IPv6 subnet
prefixes differs from the IPv4 model in that all nodes automatically
configure an address from the link-local prefix. A host is by
definition on-link with it's default router, and that unicast
addresses are not automatically associated with an on-link prefix.
See [RFC5942] "The IPv6 Subnet Model: The Relationship between Links
and Subnet Prefixes" for more details.
2.2. Text Representation of IPv6 Addresses 2.2. Text Representation of IPv6 Addresses
2.2.1. Text Representation of Addresses 2.2.1. Text Representation of Addresses
There are three conventional forms for representing IPv6 addresses as There are three conventional forms for representing IPv6 addresses as
text strings: text strings:
1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to 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. four hexadecimal digits of the eight 16-bit pieces of the address.
skipping to change at page 6, line 47 skipping to change at page 7, line 9
2001:0db8::cd30/60 address to left of "/" expands to 2001:0db8::cd30/60 address to left of "/" expands to
2001:0db8:0000:0000:0000:0000:0000:cd30 2001:0db8:0000:0000:0000:0000:0000:cd30
2001:0db8::cd3/60 address to left of "/" expands to 2001:0db8::cd3/60 address to left of "/" expands to
2001:0db8:0000:0000:0000:0000:0000:0cd3 2001:0db8:0000:0000:0000:0000:0000:0cd3
When writing both a node address and a prefix of that node address 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: (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 the node address 2001:0db8:0:cd30:123:4567:89ab:cdef
and its subnet number 2001:0db8:0:cd30::/60 and its subnet prefix 2001:0db8:0:cd30::/60
can be abbreviated as 2001:0db8:0:cd30:123:4567:89ab:cdef/60 can be abbreviated as 2001:0db8:0:cd30:123:4567:89ab:cdef/60
2.2.3. Recommendation for outputting IPv6 addresses 2.2.3. Recommendation for outputting IPv6 addresses
This section provides a recommendation for systems generating and This section provides a recommendation for systems generating and
outputting IPv6 addresses as text. Note, all implementations must outputting IPv6 addresses as text. Note, all implementations must
accept and process all addresses in the formats defined in the accept and process all addresses in the formats defined in the
previous two sections of this document. Background on this previous two sections of this document. Background on this
recommendation can be found in [RFC5952]. recommendation can be found in [RFC5952].
skipping to change at page 10, line 46 skipping to change at page 11, line 10
structure of the IPv6 address, depending on the role the node plays structure of the IPv6 address, depending on the role the node plays
(for instance, host versus router). At a minimum, a node may (for instance, host versus router). At a minimum, a node may
consider that unicast addresses (including its own) have no internal consider that unicast addresses (including its own) have no internal
structure: structure:
| 128 bits | | 128 bits |
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
| node address | | node address |
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
A slightly more complex host may additionally be aware of subnet A slightly more complex node may additionally be aware of subnet
prefix(es) for the link(s) it is attached to, where different prefix(es) for the link(s) it is attached to, where different
addresses may have different values for n: addresses may have different values for n:
| n bits | 128-n bits | | n bits | 128-n bits |
+-------------------------------+---------------------------------+ +-------------------------------+---------------------------------+
| subnet prefix | interface ID | | subnet prefix | interface ID |
+-------------------------------+---------------------------------+ +-------------------------------+---------------------------------+
Though a very simple router may have no knowledge of the internal Though a very simple router may have no knowledge of the internal
structure of IPv6 unicast addresses, routers will more generally have structure of IPv6 unicast addresses, routers will more generally have
skipping to change at page 11, line 44 skipping to change at page 12, line 4
Note that the uniqueness of interface identifiers is independent of Note that the uniqueness of interface identifiers is independent of
the uniqueness of IPv6 addresses. For example, a Global Unicast the uniqueness of IPv6 addresses. For example, a Global Unicast
address may be created with an interface identifier that is only address may be created with an interface identifier that is only
unique on a single subnet, and a Link-Local address may be created unique on a single subnet, and a Link-Local address may be created
with interface identifier that is unique over multiple subnets. with interface identifier that is unique over multiple subnets.
Interface Identifiers are 64 bit long except if the first three bits Interface Identifiers are 64 bit long except if the first three bits
of the address are 000, or when the addresses are manually of the address are 000, or when the addresses are manually
configured, or by exceptions defined in standards track documents. configured, or by exceptions defined in standards track documents.
The rationale for using 64 bit Interface Identifiers can be found in The rationale for using 64 bit Interface Identifiers can be found in
[RFC7421]. An example of a standards track exception is [RFC6164] [RFC7421]. An example of a standards track exception is [RFC6164]
that standardises 127 bit prefixes on inter-router point-to-point that standardises 127 bit prefixes on inter-router point-to-point
links. 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 The details of forming interface identifiers are defined in other
specifications, such as "Privacy Extensions for Stateless Address specifications, such as "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating Autoconfiguration in IPv6" [RFC4941] or "A Method for Generating
Semantically Opaque Interface Identifiers with IPv6 Stateless Address Semantically Opaque Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)"[RFC7217]. Specific cases are described in Autoconfiguration (SLAAC)"[RFC7217]. Specific cases are described in
appropriate "IPv6 over <link>" specifications, such as "IPv6 over appropriate "IPv6 over <link>" specifications, such as "IPv6 over
Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T Ethernet" [RFC2464] and "Transmission of IPv6 Packets over ITU-T
G.9959 Networks" [RFC7428]. The security and privacy considerations G.9959 Networks" [RFC7428]. The security and privacy considerations
for IPv6 address generation is described in [RFC7721]. for IPv6 address generation is described in [RFC7721].
skipping to change at page 22, line 37 skipping to change at page 22, line 37
of this document were published, several approaches have been of this document were published, several approaches have been
developed that mitigate these problems. These are described in developed that mitigate these problems. These are described in
"Security and Privacy Considerations for IPv6 Address Generation "Security and Privacy Considerations for IPv6 Address Generation
Mechanisms" [RFC7721], "Privacy Extensions for Stateless Address Mechanisms" [RFC7721], "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6" [RFC4941], and "A Method for Generating Autoconfiguration in IPv6" [RFC4941], and "A Method for Generating
Semantically Opaque Interface Identifiers with IPv6 Stateless Address Semantically Opaque Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)" [RFC7217]. Autoconfiguration (SLAAC)" [RFC7217].
5. Acknowledgments 5. Acknowledgments
The authors would like to acknowledge the contributions of Paul The authors would like to acknowledge the contributions of Bill
Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, Simpson, Bob Fink, Bob Gilligan, Brian Carpenter, Christian Huitema,
Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, Deborah Estrin, Dimitry Haskin, Erik Nordmark, Greg Minshall, James
Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg Woodyatt. Jim Bound, Jun-ichiro Itojun Hagino, Larry Masinter,
Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, Mahmood Ali, Markku Savela, Matt Crawford, Paul Francis, Peter Ford,
Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino, Roger Fajman, Scott Bradner, Sue Thomson, Suresh Krishnan, Tatuya
Tatuya Jinmei, Suresh Krishnan, and Mahmood Ali. Jinmei, Thomas Narten, Tom Harsch, Tony Li, and Yakov Rekhter.
The authors would also like to acknowledge the authors of the The authors would also like to acknowledge the authors of the
updating RFCs that were incorporated in this version of the document updating RFCs that were incorporated in this version of the document
to move IPv6 to Internet Standard. This includes Marcelo Bagnulo, to move IPv6 to Internet Standard. This includes Marcelo Bagnulo,
Congxiao Bao, Mohamed Boucadair, Brian Carpenter, Ralph Droms, Congxiao Bao, Mohamed Boucadair, Brian Carpenter, Ralph Droms,
Christian Huitema, Sheng Jiang, Seiichi Kawamura, Masanobu Kawashima, Christian Huitema, Sheng Jiang, Seiichi Kawamura, Masanobu Kawashima,
Xing Li, and Stig Venaas. Xing Li, and Stig Venaas.
6. References 6. References
skipping to change at page 25, line 19 skipping to change at page 25, line 19
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <http://www.rfc-editor.org/info/rfc4632>. 2006, <http://www.rfc-editor.org/info/rfc4632>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <http://www.rfc-editor.org/info/rfc4941>.
[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
Model: The Relationship between Links and Subnet
Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010,
<http://www.rfc-editor.org/info/rfc5942>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, DOI 10.17487/ Address Text Representation", RFC 5952, DOI 10.17487/
RFC5952, August 2010, RFC5952, August 2010,
<http://www.rfc-editor.org/info/rfc5952>. <http://www.rfc-editor.org/info/rfc5952>.
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011,
<http://www.rfc-editor.org/info/rfc6164>. <http://www.rfc-editor.org/info/rfc6164>.
skipping to change at page 29, line 36 skipping to change at page 29, line 43
This document purposely continues the use of 0xFF and 0xFE This document purposely continues the use of 0xFF and 0xFE
because it meets the requirements for IPv6 interface because it meets the requirements for IPv6 interface
identifiers (i.e., that they must be unique on the link), IEEE identifiers (i.e., that they must be unique on the link), IEEE
EUI-48 and MAC-48 identifiers are syntactically equivalent, EUI-48 and MAC-48 identifiers are syntactically equivalent,
and that it doesn't cause any problems in practice. and that it doesn't cause any problems in practice.
Appendix B. CHANGES SINCE RFC 4291 Appendix B. CHANGES SINCE RFC 4291
This document has the following changes from RFC4291, "IP Version 6 This document has the following changes from RFC4291, "IP Version 6
Addressing Architecture". Numbers identify the Internet-Draft Addressing Architecture":
version that the change was made.:
o 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.
o Added text to the last paragraph in Section 2.1 to clarify the
differences on how subnets are hangled in IPv4 and IPv6, includes
a reference to RFC5942 "The IPv6 Subnet Model: The Relationship
between Links and Subnet Prefixes".
o Incorporate the updates made by RFC5952 in Section 2.2.3 regarding
the text format when outputting IPv6 addresses. A new section was
added for this and addresses shown in this document were changed
to lower case. This includes a reference to RFC5952.
o Incorporate the updates made by RFC6052. The change was to add a
text in Section 2.3 that points to the IANA registries that
records the prefix defined in RFC6052 and a number of other
special use prefixes.
o Clarified text 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. Added
text that Modified EUI-64 identifiers not recommended and moved
the text describing the format to Appendix A. 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.
o 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.
o Incorporate the updates made by RFC7136 to deprecate the U and G
bits in Modified EUI-64 format Internet IDs.
o Rename Section 2.4.7 to "Other Local Unicast Addresses" and
rewrote the text to point to ULAs and say that Site-Local
addresses were deprecated by RFC3879. The format of Site-Local
was removed.
o Incorporate the updates made by RFC7346. The change was to add
Realm-Local scope to the multicast scope table in Section 2.6, and
add the updating text to the same section.
o Added a reference to the IANA Multicast address registry in
Section 2.6.1.
o Added instructions in IANA Considerations to update references in
the IANA registries that currently point to RFC4291 to point to
this document.
o Expanded Security Considerations Section to discuss privacy issues
related to using stable interface identifiers to create IPv6
addresses, and reference solutions that mitigate these issues such
as RFC7721, RFC4941, RFC7271.
o Add note to Section 5 section acknowledging the authors of the
updating documents.
o Updates to resolve the open Errata on RFC4291. These are:
Errata ID: 3480: Corrects the definition of Interface-Local
multicast scope to also state that packets with interface-local
scope received from another node must be discarded.
Errata ID: 1627: Remove extraneous "of" in Section 2.7.
Errata ID: 2702: This errata is marked rejected. No change is
required.
Errata ID: 2735: This errata is marked rejected. No change is
required.
Errata ID: 4406: This errata is marked rejected. No change is
required.
Errata ID: 2406: This errata is marked rejected. No change is
required.
Errata ID: 863: This errata is marked rejected. No change is
required.
Errata ID: 864: This errata is marked rejected. No change is
required.
Errata ID: 866: This errata is marked rejected. No change is
required.
o Editorial changes.
B.1. Change History Since RFC4291
NOTE TO RFC EDITOR: Please remove this subsection prior to RFC
Publication
This section describes change history made in each Internet Draft
that went into producing this version. The numbers identify the
Internet-Draft version in which the change was made.
Working Group Internet Drafts Working Group Internet Drafts
09) Added text to the last paragraph in Section 2.1 to clarify
the differences on how subnets are hangled in IPv4 and IPv6,
includes a reference to RFC5942 "The IPv6 Subnet Model: The
Relationship between Links and Subnet Prefixes".
09) Removed short paragraph about manual configuration in
Section 2.4.1 that was added in the -08 version.
09) Revised "Changes since RFC4291" Section to have a summary of
changes since RFC4291 and a separate subsection with a change
history of each Internet Draft. This subsection will be
removed when the RFC is published.
09) Editorial changes.
08) Added Note: to Section 2 that the term "prefix" is used in 08) Added Note: to Section 2 that the term "prefix" is used in
different contexts in IPv6: a prefix used by a routing different contexts in IPv6: a prefix used by a routing
protocol, a prefix used by a node to determine if another protocol, a prefix used by a node to determine if another
node is connected to the same link, and a prefix used to node is connected to the same link, and a prefix used to
construct the complete address of a node. construct the complete address of a node.
08) Based on results of IETF last call and extensive w.g. list 08) Based on results of IETF last call and extensive w.g. list
discussion, revised text to clarify that 64 bit Interface IDs discussion, revised text to clarify that 64 bit Interface IDs
are used except when the first three bits of the address are are used except when the first three bits of the address are
000, or addresses are manually configured, or when defined by 000, or addresses are manually configured, or when defined by
 End of changes. 14 change blocks. 
21 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/