draft-ietf-6man-rfc4291bis-07.txt   draft-ietf-6man-rfc4291bis-08.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: August 4, 2017 January 31, 2017 Expires: December 22, 2017 June 20, 2017
IP Version 6 Addressing Architecture IP Version 6 Addressing Architecture
draft-ietf-6man-rfc4291bis-07 draft-ietf-6man-rfc4291bis-08
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 August 4, 2017. This Internet-Draft will expire on December 22, 2017.
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 2, line 28 skipping to change at page 2, line 28
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . 3 2. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Addressing Model . . . . . . . . . . . . . . . . . . . . 4 2.1. Addressing Model . . . . . . . . . . . . . . . . . . . . 4
2.2. Text Representation of IPv6 Addresses . . . . . . . . . . 4 2.2. Text Representation of IPv6 Addresses . . . . . . . . . . 4
2.2.1. Text Representation of 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.2.3. Recommendation for outputting IPv6 addresses . . . . 7
2.3. Address Type Identification . . . . . . . . . . . . . . . 9 2.3. Address Type Identification . . . . . . . . . . . . . . . 9
2.4. Unicast Addresses . . . . . . . . . . . . . . . . . . . . 10 2.4. Unicast Addresses . . . . . . . . . . . . . . . . . . . . 10
2.4.1. Interface Identifiers . . . . . . . . . . . . . . . . 11 2.4.1. Interface Identifiers . . . . . . . . . . . . . . . . 11
2.4.2. The Unspecified Address . . . . . . . . . . . . . . . 12 2.4.2. The Unspecified Address . . . . . . . . . . . . . . . 12
2.4.3. The Loopback 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. IPv6 Addresses with Embedded IPv4 Addresses . . . . . 13
2.4.5.1. IPv4-Compatible IPv6 Address . . . . . . . . . . 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.6. Link-Local IPv6 Unicast Addresses . . . . . . . . . . 14
2.4.7. Other Local Unicast IPv6 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.5.1. Required Anycast Address . . . . . . . . . . . . . . 15
2.6. Multicast Addresses . . . . . . . . . . . . . . . . . . . 16 2.6. Multicast Addresses . . . . . . . . . . . . . . . . . . . 16
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 . . 27 A.1. Creating Modified EUI-64 Format Interface Identifiers . . 26
Appendix B. CHANGES SINCE RFC 4291 . . . . . . . . . . . . . . . 29 Appendix B. CHANGES SINCE RFC 4291 . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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 3, line 48 skipping to change at page 3, line 48
There are no broadcast addresses in IPv6, their function being There are no broadcast addresses in IPv6, their function being
superseded by multicast addresses. superseded by multicast addresses.
In this document, fields in addresses are given a specific name, for In this document, fields in addresses are given a specific name, for
example, "subnet". When this name is used with the term "ID" 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 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" 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 (e.g., "subnet prefix"), it refers to all of the address from the
left up to and including this field. 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, In IPv6, all zeros and all ones are legal values for any field,
unless specifically excluded. Specifically, prefixes may contain, or unless specifically excluded. Specifically, prefixes may contain, or
end with, zero-valued fields. end with, zero-valued fields.
2.1. Addressing Model 2.1. Addressing Model
IPv6 addresses of all types are assigned to interfaces, not nodes. IPv6 addresses of all types are assigned to interfaces, not nodes.
An IPv6 unicast address refers to a single interface. Since each An IPv6 unicast address refers to a single interface. Since each
interface belongs to a single node, any of that node's interfaces' interface belongs to a single node, any of that node's interfaces'
unicast addresses may be used as an identifier for the node. unicast addresses may be used as an identifier for the node.
skipping to change at page 10, line 24 skipping to change at page 10, line 27
registry [IANA-AD] and the IANA IPv6 Special-Purpose Address Registry registry [IANA-AD] and the IANA IPv6 Special-Purpose Address Registry
[IANA-SP]. [IANA-SP].
2.4. Unicast Addresses 2.4. Unicast Addresses
IPv6 unicast addresses are aggregatable with prefixes of arbitrary IPv6 unicast addresses are aggregatable with prefixes of arbitrary
bit-length, similar to IPv4 addresses under Classless Inter-Domain bit-length, similar to IPv4 addresses under Classless Inter-Domain
Routing. Routing.
IPv6 unicast routing is based on prefixes of any valid length up to IPv6 unicast routing is based on prefixes of any valid length up to
128 [BCP198]. For example, [RFC6164] standardises 127 bit prefixes 128 [BCP198].
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]
There are several types of unicast addresses in IPv6, in particular, There are several types of unicast addresses in IPv6, in particular,
Global Unicast, Local unicast, and Link-Local unicast. There are Global Unicast, Local unicast, and Link-Local unicast. There are
also some special-purpose subtypes of Global Unicast, such as IPv6 also some special-purpose subtypes of Global Unicast, such as IPv6
addresses with embedded IPv4 addresses. Additional address types or addresses with embedded IPv4 addresses. Additional address types or
subtypes can be defined in the future. subtypes can be defined in the future.
IPv6 nodes may have considerable or little knowledge of the internal IPv6 nodes may have considerable or little knowledge of the internal
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 sophisticated host (but still rather simple) may A slightly more complex host may additionally be aware of subnet
additionally be aware of subnet prefix(es) for the link(s) it is prefix(es) for the link(s) it is attached to, where different
attached to, where different addresses may have different values for addresses may have different values for n:
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
knowledge of one or more of the hierarchical boundaries for the knowledge of one or more of the hierarchical boundaries for the
operation of routing protocols. The known boundaries will differ operation of routing protocols. The known boundaries will differ
skipping to change at page 11, line 40 skipping to change at page 11, line 40
Interface IDs must be viewed outside of the node that created Interface IDs must be viewed outside of the node that created
Interface ID as an opaque bit string without any internal structure. Interface ID as an opaque bit string without any internal structure.
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.
As noted in Section 2.4, all unicast addresses, except those that Interface Identifiers are 64 bit long except if the first three bits
start with the binary value 000, Interface IDs are required to be 64 of the address are 000, or when the addresses are manually
bits long. 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 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 13, line 5 skipping to change at page 13, line 19
| n bits | m bits | 128-n-m bits | | n bits | m bits | 128-n-m bits |
+------------------------+-----------+----------------------------+ +------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID | | global routing prefix | subnet ID | interface ID |
+------------------------+-----------+----------------------------+ +------------------------+-----------+----------------------------+
where the global routing prefix is a (typically hierarchically- where the global routing prefix is a (typically hierarchically-
structured) value assigned to a site (a cluster of subnets/links), 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 the subnet ID is an identifier of a link within the site, and the
interface ID is as defined in Section 2.4.1. 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 Examples of Global Unicast addresses that start with binary 000 are
the IPv6 address with embedded IPv4 addresses described in the IPv6 address with embedded IPv4 addresses described in
Section 2.4.5. An example of global addresses starting with a binary 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 value other than 000 (and therefore having a 64-bit interface ID
field) can be found in [RFC3587]. field) can be found in [RFC3587].
2.4.5. IPv6 Addresses with Embedded IPv4 Addresses 2.4.5. IPv6 Addresses with Embedded IPv4 Addresses
Two types of IPv6 addresses are defined that carry an IPv4 address in 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 the low-order 32 bits of the address. These are the "IPv4-Compatible
skipping to change at page 21, line 40 skipping to change at page 22, line 4
o IPv6 Multicast Address Space Registry [IANA-MC] o IPv6 Multicast Address Space Registry [IANA-MC]
o Application for an IPv6 Multicast Address [IANA-MA] o Application for an IPv6 Multicast Address [IANA-MA]
o Internet Protocol Version 6 (IPv6) Anycast Addresses [IANA-AC] o Internet Protocol Version 6 (IPv6) Anycast Addresses [IANA-AC]
o IANA IPv6 Special-Purpose Address Registry [IANA-SP] o IANA IPv6 Special-Purpose Address Registry [IANA-SP]
o Reserved IPv6 Interface Identifiers [IANA-ID] o Reserved IPv6 Interface Identifiers [IANA-ID]
o Number Resources [IANA-NR] o Number Resources [IANA-NR]
o Protocol Registries [IANA-PR] o Protocol Registries [IANA-PR]
o Technical requirements for authoritative name servers [IANA-NS] o Technical requirements for authoritative name servers [IANA-NS]
o IP Flow Information Export (IPFIX) Entities [IANA-FE] o IP Flow Information Export (IPFIX) Entities [IANA-FE]
The IANA should update these references to point to this document. 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 There are also other references in IANA procedures documents that the
IANA should investigate to see if they should be updated. IANA should investigate to see if they should be updated.
4. Security Considerations 4. Security Considerations
IPv6 addressing documents do not have any direct impact on Internet IPv6 addressing documents do not have any direct impact on Internet
infrastructure security. Authentication of IPv6 packets is defined infrastructure security. Authentication of IPv6 packets is defined
in [RFC4302]. in [RFC4302].
One area relavant to IPv6 addressing is privacy. IPv6 addresses can One area relavant to IPv6 addressing is privacy. IPv6 addresses can
be created using interface identifiers constructed with unique stable be created using interface identifiers constructed with unique stable
tokens. The addresses created in this manner can be used to track tokens. The addresses created in this manner can be used to track
the movement of devices across the Internet. Since earlier versions the movement of devices across the Internet. Since earlier versions
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 Paul
Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino, Sue Thomson, Markku Savela, Larry Masinter, Jun-ichiro Itojun Hagino,
Tatuya Jinmei, Suresh Krishnan, and Mahmood Ali. Tatuya Jinmei, Suresh Krishnan, and Mahmood Ali.
skipping to change at page 23, line 11 skipping to change at page 23, line 11
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
6.1. Normative References 6.1. Normative References
[I-D.ietf-6man-rfc2460bis] [I-D.ietf-6man-rfc2460bis]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", draft-ietf-6man-rfc2460bis-08 (work (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work
in progress), November 2016. in progress), May 2017.
6.2. Informative References 6.2. Informative References
[BCP198] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix [BCP198] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
Length Recommendation for Forwarding", BCP 198, RFC 7608, Length Recommendation for Forwarding", BCP 198, RFC 7608,
DOI 10.17487/RFC7608, July 2015, DOI 10.17487/RFC7608, July 2015,
<http://www.rfc-editor.org/info/rfc7608>. <http://www.rfc-editor.org/info/rfc7608>.
[EUI64] "IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) [EUI64] "IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority"", March 1997, Registration Authority"", March 1997,
skipping to change at page 24, line 8 skipping to change at page 24, line 8
[IANA-MC] "IPv6 Multicast Address Space Registry", [IANA-MC] "IPv6 Multicast Address Space Registry",
<http://www.iana.org/assignments/ipv6-multicast-addresses/ <http://www.iana.org/assignments/ipv6-multicast-addresses/
ipv6-multicast-addresses.xhtml>. ipv6-multicast-addresses.xhtml>.
[IANA-NR] "Number Resources", <http://https://www.iana.org/numbers>. [IANA-NR] "Number Resources", <http://https://www.iana.org/numbers>.
[IANA-NS] "Technical requirements for authoritative name servers", [IANA-NS] "Technical requirements for authoritative name servers",
<https://www.iana.org/help/nameserver-requirements>. <https://www.iana.org/help/nameserver-requirements>.
[IANA-PN] "Modify a Port Number assignment",
<https://www.iana.org/form/port-modification>.
[IANA-PR] "Protocol Registries", <https://www.iana.org/protocols>. [IANA-PR] "Protocol Registries", <https://www.iana.org/protocols>.
[IANA-SP] "IANA IPv6 Special-Purpose Address Registry", [IANA-SP] "IANA IPv6 Special-Purpose Address Registry",
<https://www.iana.org/assignments/iana-ipv6-special- <https://www.iana.org/assignments/iana-ipv6-special-
registry/iana-ipv6-special-registry.xhtml>. registry/iana-ipv6-special-registry.xhtml>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<http://www.rfc-editor.org/info/rfc2464>. <http://www.rfc-editor.org/info/rfc2464>.
skipping to change at page 29, line 48 skipping to change at page 29, line 41
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". Numbers identify the Internet-Draft
version that the change was made.: version that the change was made.:
Working Group Internet Drafts 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 07) Added text to Section 2.4 summarizing IPv6 unicast routing
and referencing BCP198, citing RFC6164 as an example of and referencing BCP198, citing RFC6164 as an example of
longer prefixes, and that IIDs are required to be 64 bits longer prefixes, and that IIDs are required to be 64 bits
long as described in RFC7421. long as described in RFC7421.
07) Based on review by Brian Haberman added reference to RFC5952 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 in Section 2.2.3, corrected case errors in Section 2.6.1, and
added a reference to the IANA Multicast address registry in added a reference to the IANA Multicast address registry in
Section 2.6.1. Section 2.6.1.
 End of changes. 20 change blocks. 
38 lines changed or deleted 52 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/