draft-ietf-6man-rfc6434-bis-00.txt   draft-ietf-6man-rfc6434-bis-01.txt 
Internet Engineering Task Force T. Chown Internet Engineering Task Force T. Chown
Internet-Draft Jisc Internet-Draft Jisc
Obsoletes: 6434 (if approved) J. Loughney Obsoletes: 6434 (if approved) J. Loughney
Intended status: Informational Nokia Intended status: Informational Nokia
Expires: November 2, 2017 T. Winters Expires: January 4, 2018 T. Winters
University of New Hampshire University of New Hampshire
May 2017 July 3, 2017
IPv6 Node Requirements IPv6 Node Requirements
draft-ietf-6man-rfc6434-bis-00 draft-ietf-6man-rfc6434-bis-01
Abstract Abstract
This document defines requirements for IPv6 nodes. It is expected This document defines requirements for IPv6 nodes. It is expected
that IPv6 will be deployed in a wide range of devices and situations. that IPv6 will be deployed in a wide range of devices and situations.
Specifying the requirements for IPv6 nodes allows IPv6 to function Specifying the requirements for IPv6 nodes allows IPv6 to function
well and interoperate in a large number of situations and well and interoperate in a large number of situations and
deployments. deployments.
This document obsoletes RFC 6434, and in turn RFC 4294. This document obsoletes RFC 6434, and in turn RFC 4294.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 November 2, 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 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of This Document . . . . . . . . . . . . . . . . . 4 1.1. Scope of This Document . . . . . . . . . . . . . . . . . 4
1.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 4 1.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Abbreviations Used in This Document . . . . . . . . . . . . . 5 3. Abbreviations Used in This Document . . . . . . . . . . . . . 5
4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Internet Protocol Version 6 - RFC 2460 . . . . . . . . . 6 5.1. Internet Protocol Version 6 - RFC 2460 . . . . . . . . . 6
5.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 7 5.2. Support for IPv6 Extension Headers . . . . . . . . . . . 7
5.3. Default Router Preferences and More-Specific Routes - 5.3. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 8
RFC 4191 . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. SEcure Neighbor Discovery (SEND) - RFC 3971 . . . . . . . 9 5.4. SEcure Neighbor Discovery (SEND) - RFC 3971 . . . . . . . 9
5.5. IPv6 Router Advertisement Flags Option - RFC 5175 . 9 5.5. IPv6 Router Advertisement Flags Option - RFC 5175 . . . . 10
5.6. Path MTU Discovery and Packet Size . . . . . . . . . . . 10 5.6. Path MTU Discovery and Packet Size . . . . . . . . . . . 10
5.6.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 10 5.6.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 10
5.7. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . 10 5.7. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . 10
5.8. ICMP for the Internet Protocol Version 6 (IPv6) - 5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC
RFC 4443 . . . . . . . . . . . . . . . . . . . . . . . . 11 4443 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.9. Addressing . . . . . . . . . . . . . . . . . . . . . . . 11 5.9. Default Router Preferences and More-Specific Routes - RFC
5.9.1. IP Version 6 Addressing Architecture - RFC 4291 . . . 11 4191 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.9.2. Host Address Availability Recommendations . . . . . . 11 5.10. First-Hop Router Selection - RFC 8028 . . . . . . . . . . 11
5.9.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 . 11 5.11. Multicast Listener Discovery (MLD) for IPv6 - RFC 3810 . 11
5.9.4. Privacy Extensions for Address Configuration in IPv6 5.12. Explicit Congestion Notification (ECN) - RFC 3168 . . . . 12
- RFC 4941 . . . . . . . . . . . . . . . . . . . . . 12 6. Addressing and Address Configuration . . . . . . . . . . . . 12
5.9.5. Default Address Selection for IPv6 - RFC 6724 . . . . 13 6.1. IP Version 6 Addressing Architecture - RFC 4291 . . . . . 12
5.9.6. Stateful Address Autoconfiguration (DHCPv6) - RFC 6.2. Host Address Availability Recommendations . . . . . . . . 12
3315 . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 . . . 13
5.10. Multicast Listener Discovery (MLD) for IPv6 . . . . . . . 13 6.4. Privacy Extensions for Address Configuration in IPv6 -
6. DHCP versus Router Advertisement Options for Host RFC 4941 . . . . . . . . . . . . . . . . . . . . . . . . 14
Configuration . . . . . . . . . . . . . . . . . . . . . . . . 14 6.5. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 14
7. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . 15 6.6. Default Address Selection for IPv6 - RFC 6724 . . . . . . 15
7.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - 8. Configuring Non-Address Information . . . . . . . . . . . . . 15
RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. DHCP for Other Configuration Information . . . . . . . . 15
7.2.1. Other Configuration Information . . . . . . . . . . . 15 8.2. Router Advertisements and Default Gateway . . . . . . . . 16
7.2.2. Use of Router Advertisements in Managed Environments 16 8.3. IPv6 Router Advertisement Options for DNS
7.3. IPv6 Router Advertisement Options for DNS Configuration - RFC 8106 . . . . . . . . . . . . . . . . 16
Configuration - RFC 6106 . . . . . . . . . . . . . . . . 16 8.4. DHCP Options versus Router Advertisement Options for Host
8. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 16 Configuration . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Transition Mechanisms . . . . . . . . . . . . . . . . . . 16 9. Service Discovery Protocols . . . . . . . . . . . . . . . . . 17
8.1.1. Basic Transition Mechanisms for IPv6 Hosts and 10. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 17
Routers - RFC 4213 . . . . . . . . . . . . . . . . . 16 10.1. Transition Mechanisms . . . . . . . . . . . . . . . . . 17
9. Application Support . . . . . . . . . . . . . . . . . . . . . 16 10.1.1. Basic Transition Mechanisms for IPv6 Hosts and
9.1. Textual Representation of IPv6 Addresses - RFC 5952 . 16 Routers - RFC 4213 . . . . . . . . . . . . . . . . . 17
9.2. Application Programming Interfaces (APIs) . . . . . . . . 17 11. Application Support . . . . . . . . . . . . . . . . . . . . . 17
10. Cellular Host . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Textual Representation of IPv6 Addresses - RFC 5952 . . 17
11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.2. Application Programming Interfaces (APIs) . . . . . . . 17
11.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 18 12. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.2. Transforms and Algorithms . . . . . . . . . . . . . . . 19 13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Router-Specific Functionality . . . . . . . . . . . . . . . . 19 13.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 20
12.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . 19 13.2. Transforms and Algorithms . . . . . . . . . . . . . . . 20
12.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 19 14. Router-Specific Functionality . . . . . . . . . . . . . . . . 21
12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 20 14.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . 21
13. Network Management . . . . . . . . . . . . . . . . . . . . . 20 14.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 21
13.1. Management Information Base (MIB) Modules . . . . . . . 20 14.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 21
13.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . 21 15. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 22
13.1.2. Management Information Base for the Internet 16. Network Management . . . . . . . . . . . . . . . . . . . . . 22
Protocol (IP) . . . . . . . . . . . . . . . . . . . 21 16.1. Management Information Base (MIB) Modules . . . . . . . 22
14. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 21 16.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . 23
15. Security Considerations . . . . . . . . . . . . . . . . . . . 21 16.1.2. Management Information Base for the Internet
16. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 21 Protocol (IP) . . . . . . . . . . . . . . . . . . . 23
16.1. Authors and Acknowledgments (Current Document) . . . . . 21 16.2. YANG Data Models . . . . . . . . . . . . . . . . . . . . 23
16.2. Authors and Acknowledgments from RFC 6434 . . . . . . . 21 16.2.1. IP Management YANG Model . . . . . . . . . . . . . . 23
16.3. Authors and Acknowledgments from RFC 4294 . . . . . . . 21 16.2.2. System Management YANG Model . . . . . . . . . . . . 23
17. Appendix: Changes from RFC 6434 . . . . . . . . . . . . . . . 23 16.2.3. System Management YANG Model . . . . . . . . . . . . 23
18. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 23 17. Security Considerations . . . . . . . . . . . . . . . . . . . 23
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
19.1. Normative References . . . . . . . . . . . . . . . . . . 24 19. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 23
19.2. Informative References . . . . . . . . . . . . . . . . . 30 19.1. Authors and Acknowledgments (Current Document) . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 19.2. Authors and Acknowledgments from RFC 6434 . . . . . . . 24
19.3. Authors and Acknowledgments from RFC 4294 . . . . . . . 24
20. Appendix: Changes from RFC 6434 . . . . . . . . . . . . . . . 26
21. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 26
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
22.1. Normative References . . . . . . . . . . . . . . . . . . 28
22.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
This document defines common functionality required from both IPv6 This document defines common functionality required by both IPv6
hosts and routers. Many IPv6 nodes will implement optional or hosts and routers. Many IPv6 nodes will implement optional or
additional features, but this document collects and summarizes additional features, but this document collects and summarizes
requirements from other published Standards Track documents in one requirements from other published Standards Track documents in one
place. place.
This document tries to avoid discussion of protocol details and This document tries to avoid discussion of protocol details and
references RFCs for this purpose. This document is intended to be an references RFCs for this purpose. This document is intended to be an
applicability statement and to provide guidance as to which IPv6 applicability statement and to provide guidance as to which IPv6
specifications should be implemented in the general case and which specifications should be implemented in the general case and which
specifications may be of interest to specific deployment scenarios. specifications may be of interest to specific deployment scenarios.
skipping to change at page 6, line 17 skipping to change at page 6, line 24
- Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) - Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP)
Packets over Fibre Channel [RFC4338] Packets over Fibre Channel [RFC4338]
- Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944] - Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944]
- Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE - Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE
802.16 Networks [RFC5121] 802.16 Networks [RFC5121]
- IP version 6 over PPP [RFC5072] - IP version 6 over PPP [RFC5072]
- IPv6 over IEEE 802.15.4 Networks [RFC4944]
In addition to traditional physical link-layers, it is also possible In addition to traditional physical link-layers, it is also possible
to tunnel IPv6 over other protocols. Examples include: to tunnel IPv6 over other protocols. Examples include:
- Teredo: Tunneling IPv6 over UDP through Network Address - Teredo: Tunneling IPv6 over UDP through Network Address
Translations (NATs) [RFC4380] Translations (NATs) [RFC4380]
- Section 3 of "Basic Transition Mechanisms for IPv6 Hosts and - Section 3 of "Basic Transition Mechanisms for IPv6 Hosts and
Routers" [RFC4213] Routers" [RFC4213]
**BIS Do we want a small section somewhere on UDP IPv6 tunneling, and **BIS Do we want a small section somewhere on UDP IPv6 tunneling, and
skipping to change at page 7, line 4 skipping to change at page 7, line 9
The node MUST follow the packet transmission rules in RFC 2460. The node MUST follow the packet transmission rules in RFC 2460.
Nodes MUST always be able to send, receive, and process fragment Nodes MUST always be able to send, receive, and process fragment
headers. All conformant IPv6 implementations MUST be capable of headers. All conformant IPv6 implementations MUST be capable of
sending and receiving IPv6 packets; the forwarding functionality MAY sending and receiving IPv6 packets; the forwarding functionality MAY
be supported. Overlapping fragments MUST be handled as described in be supported. Overlapping fragments MUST be handled as described in
[RFC5722]. [RFC5722].
[RFC6946] discusses IPv6 atomic fragments, and recommends that IPv6 [RFC6946] discusses IPv6 atomic fragments, and recommends that IPv6
atomic fragments are processed independently of any other fragments, atomic fragments are processed independently of any other fragments,
to protect against fragmenttation-based attacks. [RFC8021] goes to protect against fragmentation-based attacks. [RFC8021] goes
further and recommends the deprecation of atomic fragments. Nodes further and recommends the deprecation of atomic fragments. Nodes
thus MUST not generate atomic fragments. thus MUST NOT generate atomic fragments.
To mitigate a variety of potential attacks, nodes SHOULD avoid using To mitigate a variety of potential attacks, nodes SHOULD avoid using
predictable fragment Identification values in Fragment Headers, as predictable fragment Identification values in Fragment Headers, as
discussed in [RFC7739]. discussed in [RFC7739].
All nodes SHOULD support the setting and use of the IPv6 Flow Label
field as defined in the IPv6 Flow Label specification [RFC6437].
Forwarding nodes such as routers and load distributors MUST NOT
depend only on Flow Label values being uniformly distributed. It is
RECOMMENDED that source hosts support the flow label by setting the
Flow Label field for all packets of a given flow to the same value
chosen from an approximation to a discrete uniform distribution.
5.2. Support for IPv6 Extension Headers
RFC 2460 specifies extension headers and the processing for these RFC 2460 specifies extension headers and the processing for these
headers. headers.
An IPv6 node MUST be able to process these headers. An exception is An IPv6 node MUST be able to process these headers. An exception is
Routing Header type 0 (RH0), which was deprecated by [RFC5095] due to Routing Header type 0 (RH0), which was deprecated by [RFC5095] due to
security concerns and which MUST be treated as an unrecognized security concerns and which MUST be treated as an unrecognized
routing type. routing type.
Should a new type of Extension Header need to be defined, its format
MUST follow the consistent format described in Section 4 of
[RFC6564].
Further, [RFC7045] adds specific requirements for processing of Further, [RFC7045] adds specific requirements for processing of
Extension Headers, in particular that any forwarding node along an Extension Headers, in particular that any forwarding node along an
IPv6 packet's path, which forwards the packet for any reason, SHOULD IPv6 packet's path, which forwards the packet for any reason, SHOULD
do so regardless of any extension headers that are present. do so regardless of any extension headers that are present.
[RFC7112] discusses issues with oversized IPv6 Extension Header [RFC7112] discusses issues with oversized IPv6 Extension Header
chains, and states that when a node fragments an IPv6 datagram, it chains, and states that when a node fragments an IPv6 datagram, it
MUST include the entire IPv6 Header Chain in the First Fragment. MUST include the entire IPv6 Header Chain in the First Fragment.
**BIS Wait to see outcome of insertion of EHs issue in 2460-bis, and As stated in RFC2460, extension headers (except for the Hop-by-Hop
re-state here? ** Options header) are not processed, inserted, or deleted by any node
along a packet's delivery path, until the packet reaches the node (or
each of the set of nodes, in the case of multicast) identified in the
Destination Address field of the IPv6 header.
All nodes SHOULD support the setting and use of the IPv6 Flow Label Should a new type of Extension Header need to be defined, its format
field as defined in the IPv6 Flow Label specification [RFC6437]. MUST follow the consistent format described in Section 4 of
Forwarding nodes such as routers and load distributors MUST NOT [RFC6564].
depend only on Flow Label values being uniformly distributed. It is
RECOMMENDED that source hosts support the flow label by setting the
Flow Label field for all packets of a given flow to the same value
chosen from an approximation to a discrete uniform distribution.
5.2. Neighbor Discovery for IPv6 - RFC 4861 ** BIS add text on host side processing of IPv6 EHs. From list
discussion about protecting receiver from excessive EH options/pads/
etc.
5.3. Neighbor Discovery for IPv6 - RFC 4861
Neighbor Discovery is defined in [RFC4861]; the definition was Neighbor Discovery is defined in [RFC4861]; the definition was
updated by [RFC5942]. Neighbor Discovery SHOULD be supported. RFC updated by [RFC5942]. Neighbor Discovery SHOULD be supported. RFC
4861 states: 4861 states:
Unless specified otherwise (in a document that covers operating IP Unless specified otherwise (in a document that covers operating IP
over a particular link type) this document applies to all link over a particular link type) this document applies to all link
types. However, because ND uses link-layer multicast for some of types. However, because ND uses link-layer multicast for some of
its services, it is possible that on some link types (e.g., Non- its services, it is possible that on some link types (e.g., Non-
Broadcast Multi-Access (NBMA) links), alternative protocols or Broadcast Multi-Access (NBMA) links), alternative protocols or
skipping to change at page 9, line 13 skipping to change at page 9, line 31
are only useful on networks supporting hosts. In core networks are only useful on networks supporting hosts. In core networks
dominated by routers, Redirects are typically disabled. The sending dominated by routers, Redirects are typically disabled. The sending
of Redirects SHOULD be disabled by default on backbone routers. They of Redirects SHOULD be disabled by default on backbone routers. They
MAY be enabled by default on routers intended to support hosts on MAY be enabled by default on routers intended to support hosts on
edge networks. edge networks.
"IPv6 Host-to-Router Load Sharing" [RFC4311] includes additional "IPv6 Host-to-Router Load Sharing" [RFC4311] includes additional
recommendations on how to select from a set of available routers. recommendations on how to select from a set of available routers.
[RFC4311] SHOULD be supported. [RFC4311] SHOULD be supported.
5.3. Default Router Preferences and More-Specific Routes - RFC 4191
"Default Router Preferences and More-Specific Routes" [RFC4191]
provides support for nodes attached to multiple (different) networks,
each providing routers that advertise themselves as default routers
via Router Advertisements. In some scenarios, one router may provide
connectivity to destinations the other router does not, and choosing
the "wrong" default router can result in reachability failures. In
such cases, RFC 4191 can help.
Small Office/Home Office (SOHO) deployments supported by routers
adhering to [RFC7084] use RFC 4191 to advertise routes to certain
local destinations. Consequently, nodes that will be deployed in
SOHO environments SHOULD implement RFC 4191.
5.4. SEcure Neighbor Discovery (SEND) - RFC 3971 5.4. SEcure Neighbor Discovery (SEND) - RFC 3971
SEND [RFC3971] and Cryptographically Generated Addresses (CGAs) SEND [RFC3971] and Cryptographically Generated Addresses (CGAs)
[RFC3972] provide a way to secure the message exchanges of Neighbor [RFC3972] provide a way to secure the message exchanges of Neighbor
Discovery. SEND has the potential to address certain classes of Discovery. SEND has the potential to address certain classes of
spoofing attacks, but it does not provide specific protection for spoofing attacks, but it does not provide specific protection for
threats from off-link attackers. It requires relatively heavyweight threats from off-link attackers. It requires relatively heavyweight
provisioning, so is only likely to be used in scenarios where provisioning, so is only likely to be used in scenarios where
security considerations are particularly important. security considerations are particularly important.
skipping to change at page 10, line 41 skipping to change at page 10, line 48
such messages to determine what size messages can be successfully such messages to determine what size messages can be successfully
sent. "Packetization Layer Path MTU Discovery" [RFC4821] avoids sent. "Packetization Layer Path MTU Discovery" [RFC4821] avoids
having a dependency on Packet Too Big messages. having a dependency on Packet Too Big messages.
**BIS Add note about 1280 MTU and UDP, as per Mark Andrews' comments **BIS Add note about 1280 MTU and UDP, as per Mark Andrews' comments
in Berlin? ** in Berlin? **
5.7. IPv6 Jumbograms - RFC 2675 5.7. IPv6 Jumbograms - RFC 2675
IPv6 Jumbograms [RFC2675] are an optional extension that allow the IPv6 Jumbograms [RFC2675] are an optional extension that allow the
sending of IP datagrams larger than 65.535 bytes. IPv6 Jumbograms sending of IP datagrams larger than 65,535 bytes. IPv6 Jumbograms
make use of IPv6 hop-by-hop options and are only suitable on paths in make use of IPv6 hop-by-hop options and are only suitable on paths in
which every hop and link are capable of supporting Jumbograms (e.g., which every hop and link are capable of supporting Jumbograms (e.g.,
within a campus or datacenter). To date, few implementations exist, within a campus or datacenter). To date, few implementations exist,
and there is essentially no reported experience from usage. and there is essentially no reported experience from usage.
Consequently, IPv6 Jumbograms [RFC2675] remain optional at this time. Consequently, IPv6 Jumbograms [RFC2675] remain optional at this time.
**BIS Are these used? Do we need to modify the text for that? ** **BIS Are these used? Do we need to modify the text for that? **
5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443 5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443
ICMPv6 [RFC4443] MUST be supported. "Extended ICMP to Support Multi- ICMPv6 [RFC4443] MUST be supported. "Extended ICMP to Support Multi-
Part Messages" [RFC4884] MAY be supported. Part Messages" [RFC4884] MAY be supported.
5.9. Addressing 5.9. Default Router Preferences and More-Specific Routes - RFC 4191
5.9.1. IP Version 6 Addressing Architecture - RFC 4291 "Default Router Preferences and More-Specific Routes" [RFC4191]
provides support for nodes attached to multiple (different) networks,
each providing routers that advertise themselves as default routers
via Router Advertisements. In some scenarios, one router may provide
connectivity to destinations the other router does not, and choosing
the "wrong" default router can result in reachability failures. In
such cases, RFC 4191 can help.
Small Office/Home Office (SOHO) deployments supported by routers
adhering to [RFC7084] use RFC 4191 to advertise routes to certain
local destinations. Consequently, nodes that will be deployed in
SOHO environments SHOULD implement RFC 4191.
5.10. First-Hop Router Selection - RFC 8028
In multihomed scenarios, where a host has more than one prefix, each
allocated by an upstream network that is assumed to implement BCP 38
ingress filtering, the host may have multiple routers to choose from.
Hosts that may be deployed in such multihomed environments SHOULD
follow the guidance given in [RFC8028].
5.11. Multicast Listener Discovery (MLD) for IPv6 - RFC 3810
Nodes that need to join multicast groups MUST support MLDv2
[RFC3810]. MLD is needed by any node that is expected to receive and
process multicast traffic and in particular MLDv2 is required for
support for source-specific multicast (SSM) as per [RFC4607].
Previous version of this document only required MLDv1 to be
implemented on all nodes. Since participation of any MLDv1-only
nodes on a link require that all other nodeas on the link then
operate in version 1 compatibility mode, the requirement to support
MLDv2 on all nodes was upgraded to a MUST. Further, SSM is now the
preferred multicast distribution method, rather than ASM.
Note that Neighbor Discovery (as used on most link types -- see
Section 5.3) depends on multicast and requires that nodes join
Solicited Node multicast addresses.
5.12. Explicit Congestion Notification (ECN) - RFC 3168
An ECN-aware router may set a mark in the IP header instead of
dropping a packet in order to signal impending congestion. The
receiver of the packet echoes the congestion indication to the
sender, which can then reduce its transmission rate as if it detected
a dropped packet.
Nodes that may be deployed in environments where they would benefit
from such early congestion notification SHOULD implement [RFC3168].
** BIS - but note draft-ietf-tsvwg-ecn-experimentation-03, e.g.,
nonce comment
6. Addressing and Address Configuration
6.1. IP Version 6 Addressing Architecture - RFC 4291
The IPv6 Addressing Architecture [RFC4291] MUST be supported. The IPv6 Addressing Architecture [RFC4291] MUST be supported.
**BIS Update to 4291-bis ** **BIS Update to 4291-bis **
**BIS Add note on Why /64? RFC 7421, after the conclusion of the **BIS Add note on Why /64? RFC 7421, after the conclusion of the
RFC4291-bis (lengthy!!!) discussions on the 64-bit IID topic. But no RFC4291-bis (lengthy!!!) discussions on the 64-bit IID topic. But no
need for /127 p2p text RFC 6164. And no need for note on IID need for /127 p2p text RFC 6164. And no need for note on IID
significance, as per RFC 7136. ** significance, as per RFC 7136. **
5.9.2. Host Address Availability Recommendations 6.2. Host Address Availability Recommendations
Hosts may be configured with addresses through a variety of methods, Hosts may be configured with addresses through a variety of methods,
including SLAAC, DHCPv6, or manual configuration. including SLAAC, DHCPv6, or manual configuration.
[RFC7934] recommends that networks provide general-purpose end hosts [RFC7934] recommends that networks provide general-purpose end hosts
with multiple global IPv6 addresses when they attach, and it with multiple global IPv6 addresses when they attach, and it
describes the benefits of and the options for doing so. There are, describes the benefits of and the options for doing so. There are,
for example, benefits to multiple addresses for privacy reasons, or for example, benefits to multiple addresses for privacy reasons, or
to assigning hosts a whole /64 to avoid the need for host-based NAT. to assigning hosts a whole /64 to avoid the need for host-based NAT.
5.9.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 **BIS could add a reference to draft-ietf-v6ops-unique-ipv6-prefix-
per-host-06 as a BCP?
6.3. IPv6 Stateless Address Autoconfiguration - RFC 4862
Hosts MUST support IPv6 Stateless Address Autoconfiguration as Hosts MUST support IPv6 Stateless Address Autoconfiguration as
defined in either [RFC4862] or [RFC7217]. It is recommended that, defined in either [RFC4862] or [RFC7217]. It is recommended that,
unless there is a specific requirement for MAC addresses to be unless there is a specific requirement for MAC addresses to be
embedded in an IID, nodes follow the procedure in RFC7217 to generate embedded in an IID, nodes follow the procedure in RFC7217 to generate
SLAAC-based addresses. Addresses generated through RFC7217 will be SLAAC-based addresses. Addresses generated through RFC7217 will be
the same whenever a given device (re)appears on the same subnet (with the same whenever a given device (re)appears on the same subnet (with
a specific IPv6 prefix), but the IID will vary on each subnet a specific IPv6 prefix), but the IID will vary on each subnet
visited. visited.
skipping to change at page 12, line 34 skipping to change at page 14, line 5
the time needed to acquire and configure addresses as devices quickly the time needed to acquire and configure addresses as devices quickly
move from one network to another, and it is desirable to minimize move from one network to another, and it is desirable to minimize
transition delays. For general purpose devices, RFC 4429 remains transition delays. For general purpose devices, RFC 4429 remains
optional at this time. optional at this time.
[RFC7527] discusses enhanced DAD, and describes an algorithm to [RFC7527] discusses enhanced DAD, and describes an algorithm to
automate the detection of looped back IPv6 ND messages used by DAD. automate the detection of looped back IPv6 ND messages used by DAD.
Nodes SHOULD implement this behaviour where such detection is Nodes SHOULD implement this behaviour where such detection is
beneficial. beneficial.
5.9.4. Privacy Extensions for Address Configuration in IPv6 - RFC 4941 6.4. Privacy Extensions for Address Configuration in IPv6 - RFC 4941
A node using Stateless Address Autoconfiguration [RFC4862] to form a A node using Stateless Address Autoconfiguration [RFC4862] to form a
globally unique IPv6 address using its MAC address to generate the globally unique IPv6 address using its MAC address to generate the
IID will see that IID remain the same on any visited network, even IID will see that IID remain the same on any visited network, even
though the network prefix part changes. Thus it is possible for 3rd though the network prefix part changes. Thus it is possible for 3rd
party devices such nodes communicate with to track the activities of party devices such nodes communicate with to track the activities of
the node as it moves around the network. Privacy Extensions for the node as it moves around the network. Privacy Extensions for
Stateless Address Autoconfiguration [RFC4941] address this concern by Stateless Address Autoconfiguration [RFC4941] address this concern by
allowing nodes to configure an additional temporary address where the allowing nodes to configure an additional temporary address where the
IID is effectively randomly generated. Privacy addresses are then IID is effectively randomly generated. Privacy addresses are then
skipping to change at page 13, line 16 skipping to change at page 14, line 35
enable or disable the use of such temporary addresses. enable or disable the use of such temporary addresses.
Note that RFC4941 can be used independently of traditional SLAAC, or Note that RFC4941 can be used independently of traditional SLAAC, or
of RFC7217-based SLAAC. of RFC7217-based SLAAC.
Implementers of RFC 4941 should be aware that certain addresses are Implementers of RFC 4941 should be aware that certain addresses are
reserved and should not be chosen for use as temporary addresses. reserved and should not be chosen for use as temporary addresses.
Consult "Reserved IPv6 Interface Identifiers" [RFC5453] for more Consult "Reserved IPv6 Interface Identifiers" [RFC5453] for more
details. details.
5.9.5. Default Address Selection for IPv6 - RFC 6724 6.5. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315
IPv6 nodes will invariably have multiple addresses configured
simultaneously, and thus will need to choose which addresses to use
for which communications. The rules specified in the Default Address
Selection for IPv6 [RFC6724] document MUST be implemented.
5.9.6. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315
DHCPv6 [RFC3315] can be used to obtain and configure addresses. In DHCPv6 [RFC3315] can be used to obtain and configure addresses. In
general, a network may provide for the configuration of addresses general, a network may provide for the configuration of addresses
through Router Advertisements, DHCPv6, or both. There will be a wide through Router Advertisements, DHCPv6, or both. There will be a wide
range of IPv6 deployment models and differences in address assignment range of IPv6 deployment models and differences in address assignment
requirements, some of which may require DHCPv6 for stateful address requirements, some of which may require DHCPv6 for stateful address
assignment. Consequently, all hosts SHOULD implement address assignment. Consequently, all hosts SHOULD implement address
configuration via DHCPv6. configuration via DHCPv6.
In the absence of a router, IPv6 nodes using DHCP for address In the absence of a router, IPv6 nodes using DHCP for address
assignment MAY initiate DHCP to obtain IPv6 addresses and other assignment MAY initiate DHCP to obtain IPv6 addresses and other
configuration information, as described in Section 5.5.2 of configuration information, as described in Section 5.5.2 of
[RFC4862]. [RFC4862].
5.10. Multicast Listener Discovery (MLD) for IPv6 Where devices are likely to be carried by users and attached to
multiple visisted networks, DHCPv6 client anonymity profiles SHOULD
**BIS MLDv2 only? be supported as described in [RFC7844] to minimise the discolosure of
identifying information.
Nodes that need to join multicast groups MUST support MLDv1
[RFC2710]. MLDv1 is needed by any node that is expected to receive
and process multicast traffic. Note that Neighbor Discovery (as used
on most link types -- see Section 5.2) depends on multicast and
requires that nodes join Solicited Node multicast addresses.
MLDv2 [RFC3810] extends the functionality of MLDv1 by supporting
Source-Specific Multicast. The original MLDv2 protocol [RFC3810]
supporting Source-Specific Multicast [RFC4607] supports two types of
"filter modes". Using an INCLUDE filter, a node indicates a
multicast group along with a list of senders for the group from which
it wishes to receive traffic. Using an EXCLUDE filter, a node
indicates a multicast group along with a list of senders from which
it wishes to exclude receiving traffic. In practice, operations to
block source(s) using EXCLUDE mode are rarely used but add
considerable implementation complexity to MLDv2. Lightweight MLDv2
[RFC5790] is a simplified subset of the original MLDv2 specification
that omits EXCLUDE filter mode to specify undesired source(s).
Nodes SHOULD implement either MLDv2 [RFC3810] or Lightweight MLDv2
[RFC5790]. Specifically, nodes supporting applications using Source-
Specific Multicast that expect to take advantage of MLDv2's EXCLUDE
functionality [RFC3810] MUST support MLDv2 as defined in [RFC3810],
[RFC4604], and [RFC4607]. Nodes supporting applications that expect
to only take advantage of MLDv2's INCLUDE functionality as well as
Any-Source Multicast will find it sufficient to support Lightweight
MLDv2 as defined in [RFC5790].
If a node only supports applications that use Any-Source Multicast
(i.e, they do not use Source-Specific Multicast), implementing MLDv1
[RFC2710] is sufficient. In all cases, however, nodes are strongly
encouraged to implement MLDv2 or Lightweight MLDv2 rather than MLDv1,
as the presence of a single MLDv1 participant on a link requires that
all other nodes on the link operate in version 1 compatibility mode.
When MLDv1 is used, the rules in the Source Address Selection for the
Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be
followed.
6. DHCP versus Router Advertisement Options for Host Configuration
**BIS this section probably needs rewriting **
In IPv6, there are two main protocol mechanisms for propagating
configuration information to hosts: Router Advertisements (RAs) and
DHCP. Historically, RA options have been restricted to those deemed
essential for basic network functioning and for which all nodes are
configured with exactly the same information. Examples include the
Prefix Information Options, the MTU option, etc. On the other hand,
DHCP has generally been preferred for configuration of more general
parameters and for parameters that may be client-specific. That
said, identifying the exact line on whether a particular option
should be configured via DHCP versus an RA option has not always been
easy. Generally speaking, however, there has been a desire to define
only one mechanism for configuring a given option, rather than
defining multiple (different) ways of configuring the same
information.
One issue with having multiple ways of configuring the same 6.6. Default Address Selection for IPv6 - RFC 6724
information is that interoperability suffers if a host chooses one
mechanism but the network operator chooses a different mechanism.
For "closed" environments, where the network operator has significant
influence over what devices connect to the network and thus what
configuration mechanisms they support, the operator may be able to
ensure that a particular mechanism is supported by all connected
hosts. In more open environments, however, where arbitrary devices
may connect (e.g., a WIFI hotspot), problems can arise. To maximize
interoperability in such environments, hosts would need to implement
multiple configuration mechanisms to ensure interoperability.
7. DNS and DHCP IPv6 nodes will invariably have multiple addresses configured
simultaneously, and thus will need to choose which addresses to use
for which communications. The rules specified in the Default Address
Selection for IPv6 [RFC6724] document MUST be implemented.
7.1. DNS 7. DNS
DNS is described in [RFC1034], [RFC1035], [RFC3363], and [RFC3596]. DNS is described in [RFC1034], [RFC1035], [RFC3363], and [RFC3596].
Not all nodes will need to resolve names; those that will never need Not all nodes will need to resolve names; those that will never need
to resolve DNS names do not need to implement resolver functionality. to resolve DNS names do not need to implement resolver functionality.
However, the ability to resolve names is a basic infrastructure However, the ability to resolve names is a basic infrastructure
capability on which applications rely, and most nodes will need to capability on which applications rely, and most nodes will need to
provide support. All nodes SHOULD implement stub-resolver [RFC1034] provide support. All nodes SHOULD implement stub-resolver [RFC1034]
functionality, as in [RFC1034], Section 5.3.1, with support for: functionality, as in [RFC1034], Section 5.3.1, with support for:
- AAAA type Resource Records [RFC3596]; - AAAA type Resource Records [RFC3596];
- reverse addressing in ip6.arpa using PTR records [RFC3596]; - reverse addressing in ip6.arpa using PTR records [RFC3596];
- Extension Mechanisms for DNS (EDNS0) [RFC2671] to allow for DNS - Extension Mechanisms for DNS (EDNS0) [RFC6891] to allow for DNS
packet sizes larger than 512 octets. packet sizes larger than 512 octets.
Those nodes are RECOMMENDED to support DNS security extensions Those nodes are RECOMMENDED to support DNS security extensions
[RFC4033] [RFC4034] [RFC4035]. [RFC4033] [RFC4034] [RFC4035].
A6 Resource Records, which were only ever defined with Experimental A6 Resource Records, which were only ever defined with Experimental
status in [RFC3363], are now classified as Historic, as per status in [RFC3363], are now classified as Historic, as per
[RFC6563]. [RFC6563].
**BIS Add DNS-SD? ** 8. Configuring Non-Address Information
7.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315
7.2.1. Other Configuration Information 8.1. DHCP for Other Configuration Information
IPv6 nodes use DHCP [RFC3315] to obtain address configuration IPv6 nodes use DHCP [RFC3315] to obtain address configuration
information (see Section 5.9.6) and to obtain additional (non- information (see Section 6.5) and to obtain additional (non-address)
address) configuration. If a host implementation supports configuration. If a host implementation supports applications or
applications or other protocols that require configuration that is other protocols that require configuration that is only available via
only available via DHCP, hosts SHOULD implement DHCP. For DHCP, hosts SHOULD implement DHCP. For specialized devices on which
specialized devices on which no such configuration need is present, no such configuration need is present, DHCP may not be necessary.
DHCP may not be necessary.
An IPv6 node can use the subset of DHCP (described in [RFC3736]) to An IPv6 node can use the subset of DHCP (described in [RFC3736]) to
obtain other configuration information. obtain other configuration information.
7.2.2. Use of Router Advertisements in Managed Environments 8.2. Router Advertisements and Default Gateway
There is no defined DHCPv6 Gateway option.
Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
are expected to determine their default router information and on- are thus expected to determine their default router information and
link prefix information from received Router Advertisements. There on-link prefix information from received Router Advertisements.
is no defined DHCPv6 Gateway option.
7.3. IPv6 Router Advertisement Options for DNS Configuration - RFC 6106 8.3. IPv6 Router Advertisement Options for DNS Configuration - RFC 8106
Router Advertisements have historically limited options to those that Router Advertisements have historically limited options to those that
are critical to basic IPv6 functioning. Originally, DNS are critical to basic IPv6 functioning. Originally, DNS
configuration was not included as an RA option, and DHCP was the configuration was not included as an RA option, and DHCP was the
recommended way to obtain DNS configuration information. Over time, recommended way to obtain DNS configuration information. Over time,
the thinking surrounding such an option has evolved. It is now the thinking surrounding such an option has evolved. It is now
generally recognized that few nodes can function adequately without generally recognized that few nodes can function adequately without
having access to a working DNS resolver. [RFC5006] was published as having access to a working DNS resolver, and thus a Standards Track
an Experimental document in 2007, and recently, a revised version was document has been published to provide this capability [RFC8106].
placed on the Standards Track [RFC6106].
Implementations SHOULD implement the DNS RA option [RFC6106]. Implementations MUST include support for the DNS RA option [RFC8106].
8. IPv4 Support and Transition 8.4. DHCP Options versus Router Advertisement Options for Host
Configuration
**BIS needs rewriting
In IPv6, there are two main protocol mechanisms for propagating
configuration information to hosts: Router Advertisements (RAs) and
DHCP. Historically, RA options have been restricted to those deemed
essential for basic network functioning and for which all nodes are
configured with exactly the same information. Examples include the
Prefix Information Options, the MTU option, etc. On the other hand,
DHCP has generally been preferred for configuration of more general
parameters and for parameters that may be client-specific. That
said, identifying the exact line on whether a particular option
should be configured via DHCP versus an RA option has not always been
easy. Generally speaking, however, there has been a desire to define
only one mechanism for configuring a given option, rather than
defining multiple (different) ways of configuring the same
information.
One issue with having multiple ways of configuring the same
information is that interoperability suffers if a host chooses one
mechanism but the network operator chooses a different mechanism.
For "closed" environments, where the network operator has significant
influence over what devices connect to the network and thus what
configuration mechanisms they support, the operator may be able to
ensure that a particular mechanism is supported by all connected
hosts. In more open environments, however, where arbitrary devices
may connect (e.g., a WIFI hotspot), problems can arise. To maximize
interoperability in such environments, hosts would need to implement
multiple configuration mechanisms to ensure interoperability.
9. Service Discovery Protocols
[RFC6762] and [RFC6763] describe multicast DNS (mDNS) and DNS-Based
Service Discovery (DNS-SD) respectively. These protocols,
collectively commonly referred to as the 'Bonjour' protocols after
their naming by Apple, provide the means for devices to discover
services within a local link and, in the absence of a unicast DNS
service, to exchange naming information.
Where devices are to be deployed in networks where service dicovery
would be beneficial, e.g., for users seeking to discover printers or
display devices, mDNS and DNS-SD SHOULD be supported.
The IETF dnssd WG is defining solutions for DNS-based service
discovery in multi-link networks.
10. IPv4 Support and Transition
IPv6 nodes MAY support IPv4. IPv6 nodes MAY support IPv4.
8.1. Transition Mechanisms 10.1. Transition Mechanisms
8.1.1. Basic Transition Mechanisms for IPv6 Hosts and Routers - RFC 10.1.1. Basic Transition Mechanisms for IPv6 Hosts and Routers - RFC
4213 4213
If an IPv6 node implements dual stack and tunneling, then [RFC4213] If an IPv6 node implements dual stack and tunneling, then [RFC4213]
MUST be supported. MUST be supported.
9. Application Support 11. Application Support
9.1. Textual Representation of IPv6 Addresses - RFC 5952 11.1. Textual Representation of IPv6 Addresses - RFC 5952
Software that allows users and operators to input IPv6 addresses in Software that allows users and operators to input IPv6 addresses in
text form SHOULD support "A Recommendation for IPv6 Address Text text form SHOULD support "A Recommendation for IPv6 Address Text
Representation" [RFC5952]. Representation" [RFC5952].
9.2. Application Programming Interfaces (APIs) 11.2. Application Programming Interfaces (APIs)
There are a number of IPv6-related APIs. This document does not There are a number of IPv6-related APIs. This document does not
mandate the use of any, because the choice of API does not directly mandate the use of any, because the choice of API does not directly
relate to on-the-wire behavior of protocols. Implementers, however, relate to on-the-wire behavior of protocols. Implementers, however,
would be advised to consider providing a common API or reviewing would be advised to consider providing a common API or reviewing
existing APIs for the type of functionality they provide to existing APIs for the type of functionality they provide to
applications. applications.
"Basic Socket Interface Extensions for IPv6" [RFC3493] provides IPv6 "Basic Socket Interface Extensions for IPv6" [RFC3493] provides IPv6
functionality used by typical applications. Implementers should note functionality used by typical applications. Implementers should note
skipping to change at page 17, line 35 skipping to change at page 18, line 28
Address Selection rules of [RFC6724]. Address Selection rules of [RFC6724].
"Socket Interface Extensions for Multicast Source Filters" [RFC3678] "Socket Interface Extensions for Multicast Source Filters" [RFC3678]
provides support for expressing source filters on multicast group provides support for expressing source filters on multicast group
memberships. memberships.
"Extension to Sockets API for Mobile IPv6" [RFC4584] provides "Extension to Sockets API for Mobile IPv6" [RFC4584] provides
application support for accessing and enabling Mobile IPv6 [RFC6275] application support for accessing and enabling Mobile IPv6 [RFC6275]
features. features.
10. Cellular Host 12. Mobility
Mobile IPv6 [RFC6275] and associated specifications [RFC3776]
[RFC4877] allow a node to change its point of attachment within the
Internet, while maintaining (and using) a permanent address. All
communication using the permanent address continues to proceed as
expected even as the node moves around. The definition of Mobile IP
includes requirements for the following types of nodes:
- mobile nodes
- correspondent nodes with support for route optimization
- home agents
- all IPv6 routers
At the present time, Mobile IP has seen only limited implementation
and no significant deployment, partly because it originally assumed
an IPv6-only environment rather than a mixed IPv4/IPv6 Internet.
Recently, additional work has been done to support mobility in mixed-
mode IPv4 and IPv6 networks [RFC5555].
More usage and deployment experience is needed with mobility before
any specific approach can be recommended for broad implementation in
all hosts and routers. Consequently, [RFC6275], [RFC5555], and
associated standards such as [RFC4877] are considered a MAY at this
time.
IPv6 for 3GPP [RFC7066] lists IPv6 Functionalities that need to be IPv6 for 3GPP [RFC7066] lists IPv6 Functionalities that need to be
implemented above and beyond the recommendations in this document. implemented above and beyond the recommendations in this document.
Additionally a 3GPP IPv6 Host MAY implement [RFC7278] for delivering Additionally a 3GPP IPv6 Host MAY implement [RFC7278] for delivering
IPv6 prefixes on the LAN link. IPv6 prefixes on the LAN link.
11. Security 13. Security
This section describes the specification for security for IPv6 nodes. This section describes the specification for security for IPv6 nodes.
Achieving security in practice is a complex undertaking. Operational Achieving security in practice is a complex undertaking. Operational
procedures, protocols, key distribution mechanisms, certificate procedures, protocols, key distribution mechanisms, certificate
management approaches, etc., are all components that impact the level management approaches, etc., are all components that impact the level
of security actually achieved in practice. More importantly, of security actually achieved in practice. More importantly,
deficiencies or a poor fit in any one individual component can deficiencies or a poor fit in any one individual component can
significantly reduce the overall effectiveness of a particular significantly reduce the overall effectiveness of a particular
security approach. security approach.
skipping to change at page 18, line 27 skipping to change at page 19, line 50
needs and environments. Moreover, IPsec is not viewed as the ideal needs and environments. Moreover, IPsec is not viewed as the ideal
security technology in all cases and is unlikely to displace the security technology in all cases and is unlikely to displace the
others. others.
Previously, IPv6 mandated implementation of IPsec and recommended the Previously, IPv6 mandated implementation of IPsec and recommended the
key management approach of IKE. This document updates that key management approach of IKE. This document updates that
recommendation by making support of the IPsec Architecture [RFC4301] recommendation by making support of the IPsec Architecture [RFC4301]
a SHOULD for all IPv6 nodes. Note that the IPsec Architecture a SHOULD for all IPv6 nodes. Note that the IPsec Architecture
requires (e.g., Section 4.5 of RFC 4301) the implementation of both requires (e.g., Section 4.5 of RFC 4301) the implementation of both
manual and automatic key management. Currently, the default manual and automatic key management. Currently, the default
automated key management protocol to implement is IKEv2 [RFC5996]. automated key management protocol to implement is IKEv2 [RFC7296].
This document recognizes that there exists a range of device types This document recognizes that there exists a range of device types
and environments where approaches to security other than IPsec can be and environments where approaches to security other than IPsec can be
justified. For example, special-purpose devices may support only a justified. For example, special-purpose devices may support only a
very limited number or type of applications, and an application- very limited number or type of applications, and an application-
specific security approach may be sufficient for limited management specific security approach may be sufficient for limited management
or configuration capabilities. Alternatively, some devices may run or configuration capabilities. Alternatively, some devices may run
on extremely constrained hardware (e.g., sensors) where the full on extremely constrained hardware (e.g., sensors) where the full
IPsec Architecture is not justified. IPsec Architecture is not justified.
**BIS Add note on security in IPv4-only networks? RFC 7123? Because most common platforms now support IPv6 and have it enabled by
Relevant? ** default, IPv6 security is an issue for networks that are ostensibly
IPv4-only; see [RFC7123] for guidance on this area.
11.1. Requirements 13.1. Requirements
"Security Architecture for the Internet Protocol" [RFC4301] SHOULD be "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be
supported by all IPv6 nodes. Note that the IPsec Architecture supported by all IPv6 nodes. Note that the IPsec Architecture
requires (e.g., Section 4.5 of [RFC4301]) the implementation of both requires (e.g., Section 4.5 of [RFC4301]) the implementation of both
manual and automatic key management. Currently, the default manual and automatic key management. Currently, the default
automated key management protocol to implement is IKEv2. As required automated key management protocol to implement is IKEv2. As required
in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST
implement ESP [RFC4303] and MAY implement AH [RFC4302]. implement ESP [RFC4303] and MAY implement AH [RFC4302].
11.2. Transforms and Algorithms 13.2. Transforms and Algorithms
The current set of mandatory-to-implement algorithms for the IPsec The current set of mandatory-to-implement algorithms for the IPsec
Architecture are defined in "Cryptographic Algorithm Implementation Architecture are defined in "Cryptographic Algorithm Implementation
Requirements For ESP and AH" [RFC4835]. IPv6 nodes implementing the Requirements For ESP and AH" [RFC7321]. IPv6 nodes implementing the
IPsec Architecture MUST conform to the requirements in [RFC4835]. IPsec Architecture MUST conform to the requirements in [RFC7321].
Preferred cryptographic algorithms often change more frequently than Preferred cryptographic algorithms often change more frequently than
security protocols. Therefore, implementations MUST allow for security protocols. Therefore, implementations MUST allow for
migration to new algorithms, as RFC 4835 is replaced or updated in migration to new algorithms, as RFC 7321 is replaced or updated in
the future. the future.
**BIS update to 7321bis** **BIS update to 7321bis**
The current set of mandatory-to-implement algorithms for IKEv2 are The current set of mandatory-to-implement algorithms for IKEv2 are
defined in "Cryptographic Algorithms for Use in the Internet Key defined in "Cryptographic Algorithms for Use in the Internet Key
Exchange Version 2 (IKEv2)" [RFC4307]. IPv6 nodes implementing IKEv2 Exchange Version 2 (IKEv2)" [RFC4307]. IPv6 nodes implementing IKEv2
MUST conform to the requirements in [RFC4307] and/or any future MUST conform to the requirements in [RFC4307] and/or any future
updates or replacements to [RFC4307]. updates or replacements to [RFC4307].
**BIS update to 4307bis** **BIS update to 4307bis**
12. Router-Specific Functionality 14. Router-Specific Functionality
This section defines general host considerations for IPv6 nodes that This section defines general host considerations for IPv6 nodes that
act as routers. Currently, this section does not discuss routing- act as routers. Currently, this section does not discuss routing-
specific requirements; for the case of typical home routers, specific requirements; for the case of typical home routers,
[RFC7084] defines basic requirements for customer edge routers. [RFC7084] defines basic requirements for customer edge routers.
**BIS Sync here with work by John Brzozowski et al. in draft-ali- **BIS Sync here with work by John Brzozowski et al. in draft-ali-
ipv6rtr-reqs-02** ipv6rtr-reqs-02**
12.1. IPv6 Router Alert Option - RFC 2711 14.1. IPv6 Router Alert Option - RFC 2711
The IPv6 Router Alert Option [RFC2711] is an optional IPv6 Hop-by-Hop The IPv6 Router Alert Option [RFC2711] is an optional IPv6 Hop-by-Hop
Header that is used in conjunction with some protocols (e.g., RSVP Header that is used in conjunction with some protocols (e.g., RSVP
[RFC2205] or Multicast Listener Discovery (MLD) [RFC2710]). The [RFC2205] or Multicast Listener Discovery (MLD) [RFC2710]). The
Router Alert option will need to be implemented whenever protocols Router Alert option will need to be implemented whenever protocols
that mandate its usage (e.g., MLD) are implemented. See that mandate its usage (e.g., MLD) are implemented. See
Section 5.10. Section 5.11.
12.2. Neighbor Discovery for IPv6 - RFC 4861 14.2. Neighbor Discovery for IPv6 - RFC 4861
Sending Router Advertisements and processing Router Solicitations Sending Router Advertisements and processing Router Solicitations
MUST be supported. MUST be supported.
Section 7 of [RFC6275] includes some mobility-specific extensions to Section 7 of [RFC6275] includes some mobility-specific extensions to
Neighbor Discovery. Routers SHOULD implement Sections 7.3 and 7.5, Neighbor Discovery. Routers SHOULD implement Sections 7.3 and 7.5,
even if they do not implement Home Agent functionality. even if they do not implement Home Agent functionality.
12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 14.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315
A single DHCP server ([RFC3315] or [RFC4862]) can provide A single DHCP server ([RFC3315] or [RFC4862]) can provide
configuration information to devices directly attached to a shared configuration information to devices directly attached to a shared
link, as well as to devices located elsewhere within a site. link, as well as to devices located elsewhere within a site.
Communication between a client and a DHCP server located on different Communication between a client and a DHCP server located on different
links requires the use of DHCP relay agents on routers. links requires the use of DHCP relay agents on routers.
In simple deployments, consisting of a single router and either a In simple deployments, consisting of a single router and either a
single LAN or multiple LANs attached to the single router, together single LAN or multiple LANs attached to the single router, together
with a WAN connection, a DHCP server embedded within the router is with a WAN connection, a DHCP server embedded within the router is
skipping to change at page 20, line 33 skipping to change at page 22, line 13
traditional server, rather than as part of a router. traditional server, rather than as part of a router.
Because of the wide range of deployment scenarios, support for DHCP Because of the wide range of deployment scenarios, support for DHCP
server functionality on routers is optional. However, routers server functionality on routers is optional. However, routers
targeted for deployment within more complex scenarios (as described targeted for deployment within more complex scenarios (as described
above) SHOULD support relay agent functionality. Note that "Basic above) SHOULD support relay agent functionality. Note that "Basic
Requirements for IPv6 Customer Edge Routers" [RFC7084] requires Requirements for IPv6 Customer Edge Routers" [RFC7084] requires
implementation of a DHCPv6 server function in IPv6 Customer Edge (CE) implementation of a DHCPv6 server function in IPv6 Customer Edge (CE)
routers. routers.
13. Network Management 15. Constrained Devices
The target for this document is general IPv6 nodes. In the case of
constrained nodes, with limited CPU, memory, bandwidth or power,
support for certain IPv6 functionality may need to be considered due
to those limitations. The requirements of this document are
RECOMMENDED for all nodes, including constrained nodes, but
compromises may need to be made in certain cases. Where such
compromises are made, the interoperability of devices should be
strongly considered, paticularly where this may impact other nodes on
the same link, e.g., only supporting MLDv1 will affect other nodes.
The IETF 6LowPAN (IPv6 over Low Power LWPAN) WG defined six RFCs,
including a general overview and problem statement ([RFC4919], the
means by which IPv6 packets are transmitted over IEEE 802.15.4
networks [RFC4944] and ND optimisations for that medium [RFC6775].
**BIS What else to say here? Talk about resource management in
nodes? Low power operation?
16. Network Management
Network management MAY be supported by IPv6 nodes. However, for IPv6 Network management MAY be supported by IPv6 nodes. However, for IPv6
nodes that are embedded devices, network management may be the only nodes that are embedded devices, network management may be the only
possible way of controlling these nodes. possible way of controlling these nodes.
**BIS This is a little thin. Add Netconf, restconf, yang models? ** A node supporting network management SHOULD support NETCONF [RFC6241]
and SNMP configuration [RFC3411].
**BIS add the network polling/syslod nd for none DHCPv6 network
tracking.**
13.1. Management Information Base (MIB) Modules 16.1. Management Information Base (MIB) Modules
**BIS Address MIB Obsolete draft IPv6 MIB have been updated since the last release of the document,
[RFC8096] obseletes several MIBs, the nodes need to not support any
longer.
The following two MIB modules SHOULD be supported by nodes that The following two MIB modules SHOULD be supported by nodes that
support a Simple Network Management Protocol (SNMP) agent. support a Simple Network Management Protocol (SNMP) agent.
13.1.1. IP Forwarding Table MIB 16.1.1. IP Forwarding Table MIB
The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes
that support an SNMP agent. that support an SNMP agent.
13.1.2. Management Information Base for the Internet Protocol (IP) 16.1.2. Management Information Base for the Internet Protocol (IP)
The IP MIB [RFC4293] SHOULD be supported by nodes that support an The IP MIB [RFC4293] SHOULD be supported by nodes that support an
SNMP agent. SNMP agent.
14. Constrained Devices 16.2. YANG Data Models
**BIS Should we add notes on constrained devices, and power The following YANG data models SHOULD be supported by nodes that
efficiency here in a new section? Talk about resource management in support a NETCONF agent.
nodes. Low power operation.
15. Security Considerations 16.2.1. IP Management YANG Model
The IP Management YANG Model [RFC7277] SHOULD be supported by nodes
that support NETCONF.
16.2.2. System Management YANG Model
The System Management YANG Model [RFC7317] SHOULD be supported by
nodes that support NETCONF.
16.2.3. System Management YANG Model
The Interface Management YANG Model [RFC7223] SHOULD be supported by
nodes that support NETCONF.
17. Security Considerations
This document does not directly affect the security of the Internet, This document does not directly affect the security of the Internet,
beyond the security considerations associated with the individual beyond the security considerations associated with the individual
protocols. protocols.
Security is also discussed in Section 11 above. Security is also discussed in Section 13 above.
16. Authors and Acknowledgments 18. IANA Considerations
16.1. Authors and Acknowledgments (Current Document) This document does not require any IANA actions.
19. Authors and Acknowledgments
19.1. Authors and Acknowledgments (Current Document)
For this version of the IPv6 Node Requirements document, the authors For this version of the IPv6 Node Requirements document, the authors
would like to thank **BIS Add new acknowledgements for significant would like to thank Brian Carpenter and Dave Thaler for their
comments ** for their contributions. contributions.
16.2. Authors and Acknowledgments from RFC 6434 19.2. Authors and Acknowledgments from RFC 6434
Ed Jankiewicz and Thomas Narten were named authors of the previous Ed Jankiewicz and Thomas Narten were named authors of the previous
iteration of this document, RFC6434. iteration of this document, RFC6434.
For this version of the document, the authors thanked Hitoshi Asaeda, For this version of the document, the authors thanked Hitoshi Asaeda,
Brian Carpenter, Tim Chown, Ralph Droms, Sheila Frankel, Sam Hartman, Brian Carpenter, Tim Chown, Ralph Droms, Sheila Frankel, Sam Hartman,
Bob Hinden, Paul Hoffman, Pekka Savola, Yaron Sheffer, and Dave Bob Hinden, Paul Hoffman, Pekka Savola, Yaron Sheffer, and Dave
Thaler. Thaler.
16.3. Authors and Acknowledgments from RFC 4294 19.3. Authors and Acknowledgments from RFC 4294
The original version of this document (RFC 4294) was written by the The original version of this document (RFC 4294) was written by the
IPv6 Node Requirements design team: IPv6 Node Requirements design team:
Jari Arkko Jari Arkko
jari.arkko@ericsson.com jari.arkko@ericsson.com
Marc Blanchet Marc Blanchet
marc.blanchet@viagenie.qc.ca marc.blanchet@viagenie.qc.ca
skipping to change at page 23, line 5 skipping to change at page 26, line 5
Juha Wiljakka Juha Wiljakka
juha.wiljakka@Nokia.com juha.wiljakka@Nokia.com
The authors would like to thank Ran Atkinson, Jim Bound, Brian The authors would like to thank Ran Atkinson, Jim Bound, Brian
Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas
Narten, Juha Ollila, and Pekka Savola for their comments. Thanks to Narten, Juha Ollila, and Pekka Savola for their comments. Thanks to
Mark Andrews for comments and corrections on DNS text. Thanks to Mark Andrews for comments and corrections on DNS text. Thanks to
Alfred Hoenes for tracking the updates to various RFCs. Alfred Hoenes for tracking the updates to various RFCs.
17. Appendix: Changes from RFC 6434 20. Appendix: Changes from RFC 6434
There have been many editorial clarifications as well as significant There have been many editorial clarifications as well as significant
additions and updates. While this section highlights some of the additions and updates. While this section highlights some of the
changes, readers should not rely on this section for a comprehensive changes, readers should not rely on this section for a comprehensive
list of all changes. list of all changes.
1. Added 6LoWPAN to link layers 1. Restructured sections
2. Removed DOD IPv6 Profile updates 2. Added 6LoWPAN to link layers.
3. Removed IPv6 Mobility RFC6275 3. Removed DOD IPv6 Profile updates.
18. Appendix: Changes from RFC 4294 4. Updated to state MLDv2 support is a MUST.
5. Require DNS RA Options, RFC8106 is a MUST.
6. Added section on constrained devices.
7. Added text on RFC7934, address availability to hosts.
8. Added text on RFC7844, anonymity profiles for DHCPv6 clients.
9. mDNS and DNS-SD added.
10. Added RFC8028 as a SHOULD.
11. Added ECN RFC3168 as a SHOULD.
12. Added reference to RFC7123.
21. Appendix: Changes from RFC 4294
There have been many editorial clarifications as well as significant There have been many editorial clarifications as well as significant
additions and updates. While this section highlights some of the additions and updates. While this section highlights some of the
changes, readers should not rely on this section for a comprehensive changes, readers should not rely on this section for a comprehensive
list of all changes. list of all changes.
1. Updated the Introduction to indicate that this document is an 1. Updated the Introduction to indicate that this document is an
applicability statement and is aimed at general nodes. applicability statement and is aimed at general nodes.
2. Significantly updated the section on Mobility protocols, adding 2. Significantly updated the section on Mobility protocols, adding
skipping to change at page 23, line 45 skipping to change at page 27, line 14
5. Revised section on Privacy Extensions [RFC4941] to add more 5. Revised section on Privacy Extensions [RFC4941] to add more
nuance to recommendation. nuance to recommendation.
6. Completely revised IPsec/IKEv2 section, downgrading overall 6. Completely revised IPsec/IKEv2 section, downgrading overall
recommendation to a SHOULD. recommendation to a SHOULD.
7. Upgraded recommendation of DHCPv6 to SHOULD. 7. Upgraded recommendation of DHCPv6 to SHOULD.
8. Added background section on DHCP versus RA options, added SHOULD 8. Added background section on DHCP versus RA options, added SHOULD
recommendation for DNS configuration via RAs [RFC6106], and recommendation for DNS configuration via RAs (RFC6106), and
cleaned up DHCP recommendations. cleaned up DHCP recommendations.
9. Added recommendation that routers implement Sections 7.3 and 7.5 9. Added recommendation that routers implement Sections 7.3 and 7.5
of [RFC6275]. of [RFC6275].
10. Added pointer to subnet clarification document [RFC5942]. 10. Added pointer to subnet clarification document [RFC5942].
11. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311] 11. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311]
SHOULD be implemented. SHOULD be implemented.
skipping to change at page 24, line 40 skipping to change at page 28, line 10
it a MUST to implement. it a MUST to implement.
20. Updated MLD section to include reference to Lightweight MLD 20. Updated MLD section to include reference to Lightweight MLD
[RFC5790]. [RFC5790].
21. Added SHOULD recommendation for "Default Router Preferences and 21. Added SHOULD recommendation for "Default Router Preferences and
More-Specific Routes" [RFC4191]. More-Specific Routes" [RFC4191].
22. Made "IPv6 Flow Label Specification" [RFC6437] a SHOULD. 22. Made "IPv6 Flow Label Specification" [RFC6437] a SHOULD.
19. References 22. References
19.1. Normative References 22.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
skipping to change at page 25, line 18 skipping to change at page 28, line 35
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, DOI 10.17487/RFC2671, August 1999,
<http://www.rfc-editor.org/info/rfc2671>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710,
DOI 10.17487/RFC2710, October 1999, DOI 10.17487/RFC2710, October 1999,
<http://www.rfc-editor.org/info/rfc2710>. <http://www.rfc-editor.org/info/rfc2710>.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, DOI 10.17487/RFC2711, October 1999, RFC 2711, DOI 10.17487/RFC2711, October 1999,
<http://www.rfc-editor.org/info/rfc2711>. <http://www.rfc-editor.org/info/rfc2711>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3590] Haberman, B., "Source Address Selection for the Multicast [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Listener Discovery (MLD) Protocol", RFC 3590, Architecture for Describing Simple Network Management
DOI 10.17487/RFC3590, September 2003, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
<http://www.rfc-editor.org/info/rfc3590>. DOI 10.17487/RFC3411, December 2002,
<http://www.rfc-editor.org/info/rfc3411>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", RFC 3596,
DOI 10.17487/RFC3596, October 2003, DOI 10.17487/RFC3596, October 2003,
<http://www.rfc-editor.org/info/rfc3596>. <http://www.rfc-editor.org/info/rfc3596>.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736,
April 2004, <http://www.rfc-editor.org/info/rfc3736>. April 2004, <http://www.rfc-editor.org/info/rfc3736>.
skipping to change at page 27, line 20 skipping to change at page 30, line 32
[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
Sharing", RFC 4311, DOI 10.17487/RFC4311, November 2005, Sharing", RFC 4311, DOI 10.17487/RFC4311, November 2005,
<http://www.rfc-editor.org/info/rfc4311>. <http://www.rfc-editor.org/info/rfc4311>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443, Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006, DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>. <http://www.rfc-editor.org/info/rfc4443>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604,
August 2006, <http://www.rfc-editor.org/info/rfc4604>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<http://www.rfc-editor.org/info/rfc4607>. <http://www.rfc-editor.org/info/rfc4607>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <http://www.rfc-editor.org/info/rfc4862>.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835,
DOI 10.17487/RFC4835, April 2007,
<http://www.rfc-editor.org/info/rfc4835>.
[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>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007, DOI 10.17487/RFC5095, December 2007,
<http://www.rfc-editor.org/info/rfc5095>. <http://www.rfc-editor.org/info/rfc5095>.
skipping to change at page 28, line 34 skipping to change at page 31, line 34
[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
Model: The Relationship between Links and Subnet Model: The Relationship between Links and Subnet
Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010,
<http://www.rfc-editor.org/info/rfc5942>. <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, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<http://www.rfc-editor.org/info/rfc5952>. <http://www.rfc-editor.org/info/rfc5952>.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
"Internet Key Exchange Protocol Version 2 (IKEv2)", and A. Bierman, Ed., "Network Configuration Protocol
RFC 5996, DOI 10.17487/RFC5996, September 2010, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc5996>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, DOI 10.17487/RFC6106, November 2010,
<http://www.rfc-editor.org/info/rfc6106>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, "IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011, DOI 10.17487/RFC6437, November 2011,
<http://www.rfc-editor.org/info/rfc6437>. <http://www.rfc-editor.org/info/rfc6437>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers", M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012, RFC 6564, DOI 10.17487/RFC6564, April 2012,
<http://www.rfc-editor.org/info/rfc6564>. <http://www.rfc-editor.org/info/rfc6564>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>. <http://www.rfc-editor.org/info/rfc6724>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments",
RFC 6946, DOI 10.17487/RFC6946, May 2013, RFC 6946, DOI 10.17487/RFC6946, May 2013,
<http://www.rfc-editor.org/info/rfc6946>. <http://www.rfc-editor.org/info/rfc6946>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013, DOI 10.17487/RFC7045, December 2013,
<http://www.rfc-editor.org/info/rfc7045>. <http://www.rfc-editor.org/info/rfc7045>.
[RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
skipping to change at page 29, line 35 skipping to change at page 32, line 49
Oversized IPv6 Header Chains", RFC 7112, Oversized IPv6 Header Chains", RFC 7112,
DOI 10.17487/RFC7112, January 2014, DOI 10.17487/RFC7112, January 2014,
<http://www.rfc-editor.org/info/rfc7112>. <http://www.rfc-editor.org/info/rfc7112>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <http://www.rfc-editor.org/info/rfc7317>.
[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm
Implementation Requirements and Usage Guidance for
Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014,
<http://www.rfc-editor.org/info/rfc7321>.
[RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., [RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E.,
and W. George, "Enhanced Duplicate Address Detection", and W. George, "Enhanced Duplicate Address Detection",
RFC 7527, DOI 10.17487/RFC7527, April 2015, RFC 7527, DOI 10.17487/RFC7527, April 2015,
<http://www.rfc-editor.org/info/rfc7527>. <http://www.rfc-editor.org/info/rfc7527>.
[RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss
Resiliency for Router Solicitations", RFC 7559, Resiliency for Router Solicitations", RFC 7559,
DOI 10.17487/RFC7559, May 2015, DOI 10.17487/RFC7559, May 2015,
<http://www.rfc-editor.org/info/rfc7559>. <http://www.rfc-editor.org/info/rfc7559>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment [RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739, Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <http://www.rfc-editor.org/info/rfc7739>. February 2016, <http://www.rfc-editor.org/info/rfc7739>.
[RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6 [RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6
Atomic Fragments Considered Harmful", RFC 8021, Atomic Fragments Considered Harmful", RFC 8021,
DOI 10.17487/RFC8021, January 2017, DOI 10.17487/RFC8021, January 2017,
<http://www.rfc-editor.org/info/rfc8021>. <http://www.rfc-editor.org/info/rfc8021>.
19.2. Informative References [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<http://www.rfc-editor.org/info/rfc8106>.
22.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <http://www.rfc-editor.org/info/rfc2205>. September 1997, <http://www.rfc-editor.org/info/rfc2205>.
skipping to change at page 31, line 19 skipping to change at page 35, line 14
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
Extensions for Multicast Source Filters", RFC 3678, Extensions for Multicast Source Filters", RFC 3678,
DOI 10.17487/RFC3678, January 2004, DOI 10.17487/RFC3678, January 2004,
<http://www.rfc-editor.org/info/rfc3678>. <http://www.rfc-editor.org/info/rfc3678>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <http://www.rfc-editor.org/info/rfc6275>. 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, DOI 10.17487/RFC3776, June 2004,
<http://www.rfc-editor.org/info/rfc3776>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005, DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>. <http://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>. <http://www.rfc-editor.org/info/rfc3972>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
skipping to change at page 32, line 9 skipping to change at page 36, line 9
<http://www.rfc-editor.org/info/rfc4429>. <http://www.rfc-editor.org/info/rfc4429>.
[RFC4584] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API [RFC4584] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API
for Mobile IPv6", RFC 4584, DOI 10.17487/RFC4584, July for Mobile IPv6", RFC 4584, DOI 10.17487/RFC4584, July
2006, <http://www.rfc-editor.org/info/rfc4584>. 2006, <http://www.rfc-editor.org/info/rfc4584>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>. <http://www.rfc-editor.org/info/rfc4821>.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
DOI 10.17487/RFC4877, April 2007,
<http://www.rfc-editor.org/info/rfc4877>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884, "Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007, DOI 10.17487/RFC4884, April 2007,
<http://www.rfc-editor.org/info/rfc4884>. <http://www.rfc-editor.org/info/rfc4884>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007,
<http://www.rfc-editor.org/info/rfc4919>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>. <http://www.rfc-editor.org/info/rfc4944>.
[RFC5006] Jeong, J., Ed., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Option for DNS Configuration",
RFC 5006, DOI 10.17487/RFC5006, September 2007,
<http://www.rfc-editor.org/info/rfc5006>.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014, Socket API for Source Address Selection", RFC 5014,
DOI 10.17487/RFC5014, September 2007, DOI 10.17487/RFC5014, September 2007,
<http://www.rfc-editor.org/info/rfc5014>. <http://www.rfc-editor.org/info/rfc5014>.
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007,
<http://www.rfc-editor.org/info/rfc5072>. <http://www.rfc-editor.org/info/rfc5072>.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6 Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
DOI 10.17487/RFC5121, February 2008, DOI 10.17487/RFC5121, February 2008,
<http://www.rfc-editor.org/info/rfc5121>. <http://www.rfc-editor.org/info/rfc5121>.
[RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack
Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June
2009, <http://www.rfc-editor.org/info/rfc5555>.
[RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to [RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to
Historic Status", RFC 6563, DOI 10.17487/RFC6563, March Historic Status", RFC 6563, DOI 10.17487/RFC6563, March
2012, <http://www.rfc-editor.org/info/rfc6563>. 2012, <http://www.rfc-editor.org/info/rfc6563>.
[RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S. [RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S.
Krishnan, "IPv6 for Third Generation Partnership Project Krishnan, "IPv6 for Third Generation Partnership Project
(3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066, (3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066,
November 2013, <http://www.rfc-editor.org/info/rfc7066>. November 2013, <http://www.rfc-editor.org/info/rfc7066>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084, Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013, DOI 10.17487/RFC7084, November 2013,
<http://www.rfc-editor.org/info/rfc7084>. <http://www.rfc-editor.org/info/rfc7084>.
[RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on
IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February
2014, <http://www.rfc-editor.org/info/rfc7123>.
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
/64 Prefix from a Third Generation Partnership Project /64 Prefix from a Third Generation Partnership Project
(3GPP) Mobile Interface to a LAN Link", RFC 7278, (3GPP) Mobile Interface to a LAN Link", RFC 7278,
DOI 10.17487/RFC7278, June 2014, DOI 10.17487/RFC7278, June 2014,
<http://www.rfc-editor.org/info/rfc7278>. <http://www.rfc-editor.org/info/rfc7278>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>. <http://www.rfc-editor.org/info/rfc7721>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016,
<http://www.rfc-editor.org/info/rfc7844>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204, "Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016, RFC 7934, DOI 10.17487/RFC7934, July 2016,
<http://www.rfc-editor.org/info/rfc7934>. <http://www.rfc-editor.org/info/rfc7934>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016,
<http://www.rfc-editor.org/info/rfc8028>.
[RFC8096] Fenner, B., "The IPv6-Specific MIB Modules Are Obsolete",
RFC 8096, DOI 10.17487/RFC8096, April 2017,
<http://www.rfc-editor.org/info/rfc8096>.
[POSIX] IEEE, "IEEE Std. 1003.1-2008 Standard for Information [POSIX] IEEE, "IEEE Std. 1003.1-2008 Standard for Information
Technology -- Portable Operating System Interface (POSIX), Technology -- Portable Operating System Interface (POSIX),
ISO/IEC 9945:2009", <http://www.ieee.org>. ISO/IEC 9945:2009", <http://www.ieee.org>.
[USGv6] National Institute of Standards and Technology, "A Profile [USGv6] National Institute of Standards and Technology, "A Profile
for IPv6 in the U.S. Government - Version 1.0", July 2008, for IPv6 in the U.S. Government - Version 1.0", July 2008,
<http://www.antd.nist.gov/usgv6/usgv6-v1.pdf>. <http://www.antd.nist.gov/usgv6/usgv6-v1.pdf>.
Authors' Addresses Authors' Addresses
 End of changes. 96 change blocks. 
290 lines changed or deleted 469 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/