draft-ietf-6man-node-req-bis-10.txt   draft-ietf-6man-node-req-bis-11.txt 
Internet Engineering Task Force E. Jankiewicz Internet Engineering Task Force E. Jankiewicz
Internet-Draft SRI International, Inc. Internet-Draft SRI International, Inc.
Obsoletes: 4294 (if approved) J. Loughney Obsoletes: 4294 (if approved) J. Loughney
Intended status: Informational Nokia Intended status: Informational Nokia
Expires: November 24, 2011 T. Narten Expires: December 2, 2011 T. Narten
IBM Corporation IBM Corporation
May 23, 2011 May 31, 2011
IPv6 Node Requirements IPv6 Node Requirements
draft-ietf-6man-node-req-bis-10.txt draft-ietf-6man-node-req-bis-11.txt
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 RFC4294. This document obsoletes RFC4294.
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 24, 2011. This Internet-Draft will expire on December 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 31 skipping to change at page 3, line 31
5.6.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 10 5.6.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 10
5.7. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . . 11 5.7. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . . 11
5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC
4443 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4443 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.9. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 11 5.9. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 11
5.9.1. IP Version 6 Addressing Architecture - RFC 4291 . . . 11 5.9.1. IP Version 6 Addressing Architecture - RFC 4291 . . . 11
5.9.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 . 11 5.9.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 . 11
5.9.3. Privacy Extensions for Address Configuration in 5.9.3. Privacy Extensions for Address Configuration in
IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . 12 IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . 12
5.9.4. Default Address Selection for IPv6 - RFC 3484 . . . . 12 5.9.4. Default Address Selection for IPv6 - RFC 3484 . . . . 12
5.9.5. Stateful Address Autoconfiguration - RFC 3315 . . . . 13 5.9.5. Stateful Address Autoconfiguration (DHCPv6) - RFC
3315 . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.10. Multicast Listener Discovery (MLD) for IPv6 . . . . . . . 13 5.10. Multicast Listener Discovery (MLD) for IPv6 . . . . . . . 13
6. DHCP vs. Router Advertisement Options for Host 6. DHCP vs. Router Advertisement Options for Host
Configuration . . . . . . . . . . . . . . . . . . . . . . . . 14 Configuration . . . . . . . . . . . . . . . . . . . . . . . . 14
7. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 7.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
- RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 15 - RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2.1. Other Configuration Information . . . . . . . . . . . 15 7.2.1. Other Configuration Information . . . . . . . . . . . 15
7.2.2. Use of Router Advertisements in Managed 7.2.2. Use of Router Advertisements in Managed
Environments . . . . . . . . . . . . . . . . . . . . . 15 Environments . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 4, line 7 skipping to change at page 4, line 8
8.1.1. Basic Transition Mechanisms for IPv6 Hosts and 8.1.1. Basic Transition Mechanisms for IPv6 Hosts and
Routers - RFC 4213 . . . . . . . . . . . . . . . . . . 16 Routers - RFC 4213 . . . . . . . . . . . . . . . . . . 16
9. Application Support . . . . . . . . . . . . . . . . . . . . . 16 9. Application Support . . . . . . . . . . . . . . . . . . . . . 16
9.1. Textual Representation of IPv6 Addresses - RFC 5952 . . . 16 9.1. Textual Representation of IPv6 Addresses - RFC 5952 . . . 16
9.2. Application Program Interfaces (APIs) . . . . . . . . . . 16 9.2. Application Program Interfaces (APIs) . . . . . . . . . . 16
10. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18
11.2. Transforms and Algorithms . . . . . . . . . . . . . . . . 19 11.2. Transforms and Algorithms . . . . . . . . . . . . . . . . 19
12. Router-Specific Functionality . . . . . . . . . . . . . . . . 19 12. Router-Specific Functionality . . . . . . . . . . . . . . . . 19
12.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . . 19
12.1.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . 19 12.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 19
12.1.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . 19 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . . 19
13. Network Management . . . . . . . . . . . . . . . . . . . . . . 19 13. Network Management . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Management Information Base Modules (MIBs) . . . . . . . . 20 13.1. Management Information Base Modules (MIBs) . . . . . . . . 20
13.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . . 20 13.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . . 20
13.1.2. Management Information Base for the Internet 13.1.2. Management Information Base for the Internet
Protocol (IP) . . . . . . . . . . . . . . . . . . . . 20 Protocol (IP) . . . . . . . . . . . . . . . . . . . . 20
14. Security Considerations . . . . . . . . . . . . . . . . . . . 20 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
16. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 20 16. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 21
16.1. Authors and Acknowledgments (Current Document) . . . . . . 20 16.1. Authors and Acknowledgments (Current Document) . . . . . . 21
16.2. Authors and Acknowledgments From RFC 4279 . . . . . . . . 20 16.2. Authors and Acknowledgments From RFC 4279 . . . . . . . . 21
17. Appendix: Changes from One ID version to Another . . . . . . . 21 17. Appendix: Changes from One ID version to Another . . . . . . . 22
17.1. Appendix: Changes from -09 to -10 . . . . . . . . . . . . 21 17.1. Appendix: Changes from -10to -11 . . . . . . . . . . . . . 22
17.2. Appendix: Changes from -08 to -09 . . . . . . . . . . . . 22 17.2. Appendix: Changes from -09 to -10 . . . . . . . . . . . . 22
17.3. Appendix: Changes from -07 to -08 . . . . . . . . . . . . 22 17.3. Appendix: Changes from -08 to -09 . . . . . . . . . . . . 22
17.4. Appendix: Changes from -06 to -07 . . . . . . . . . . . . 22 17.4. Appendix: Changes from -07 to -08 . . . . . . . . . . . . 22
17.5. Appendix: Changes from -05 to -06 . . . . . . . . . . . . 23 17.5. Appendix: Changes from -06 to -07 . . . . . . . . . . . . 23
17.6. Appendix: Changes from -04 to -05 . . . . . . . . . . . . 23 17.6. Appendix: Changes from -05 to -06 . . . . . . . . . . . . 23
17.7. Appendix: Changes from -03 to -04 . . . . . . . . . . . . 23 17.7. Appendix: Changes from -04 to -05 . . . . . . . . . . . . 23
18. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 23 17.8. Appendix: Changes from -03 to -04 . . . . . . . . . . . . 24
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 18. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 24
19.1. Normative References . . . . . . . . . . . . . . . . . . . 24 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
19.2. Informative References . . . . . . . . . . . . . . . . . . 27 19.1. Normative References . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 19.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Requirements Language 1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction 2. Introduction
This document defines common functionality required from both IPv6 This document defines common functionality required from both IPv6
skipping to change at page 11, line 32 skipping to change at page 11, line 32
5.9. Addressing 5.9. Addressing
5.9.1. IP Version 6 Addressing Architecture - RFC 4291 5.9.1. IP Version 6 Addressing Architecture - RFC 4291
The IPv6 Addressing Architecture [RFC4291] MUST be supported. The IPv6 Addressing Architecture [RFC4291] MUST be supported.
5.9.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 5.9.2. IPv6 Stateless Address Autoconfiguration - RFC 4862
Hosts MUST support IPv6 Stateless Address Autoconfiguration as Hosts MUST support IPv6 Stateless Address Autoconfiguration as
defined in [RFC4862]. Static address may be supported as well. defined in [RFC4862]. Configuration of static address(es) may be
supported as well.
Nodes that are routers MUST be able to generate link local addresses Nodes that are routers MUST be able to generate link local addresses
as described in RFC 4862 [RFC4862]. as described in RFC 4862 [RFC4862].
From 4862: From 4862:
The autoconfiguration process specified in this document applies The autoconfiguration process specified in this document applies
only to hosts and not routers. Since host autoconfiguration uses only to hosts and not routers. Since host autoconfiguration uses
information advertised by routers, routers will need to be information advertised by routers, routers will need to be
configured by some other means. However, it is expected that configured by some other means. However, it is expected that
skipping to change at page 12, line 17 skipping to change at page 12, line 17
whether they are obtained through stateless autoconfiguration, whether they are obtained through stateless autoconfiguration,
DHCPv6, or manual configuration, with the following [exceptions DHCPv6, or manual configuration, with the following [exceptions
noted therein]. noted therein].
"Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429] "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429]
specifies a mechanism to reduce delays associated with generating specifies a mechanism to reduce delays associated with generating
addresses via stateless address autoconfiguration [RFC4862]. RFC addresses via stateless address autoconfiguration [RFC4862]. RFC
4429 was developed in conjunction with Mobile IPv6 in order to reduce 4429 was developed in conjunction with Mobile IPv6 in order to reduce
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 is not transition delays. For general purpose devices, RFC 4429 remains
considered to be necessary at this time. optional at this time.
5.9.3. Privacy Extensions for Address Configuration in IPv6 - RFC 4941 5.9.3. Privacy Extensions for Address Configuration in IPv6 - RFC 4941
Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] Privacy Extensions for Stateless Address Autoconfiguration [RFC4941]
addresses a specific problem involving a client device whose user is addresses a specific problem involving a client device whose user is
concerned about its activity or location being tracked. The problem concerned about its activity or location being tracked. The problem
arises both for a static client and for one that regularly changes arises both for a static client and for one that regularly changes
its point of attachment to the Internet. When using Stateless its point of attachment to the Internet. When using Stateless
Address Autoconfiguration [RFC4862], the Interface Identifier portion Address Autoconfiguration [RFC4862], the Interface Identifier portion
of formed addresses stays constant and is globally unique. Thus, of formed addresses stays constant and is globally unique. Thus,
skipping to change at page 13, line 5 skipping to change at page 13, line 5
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.4. Default Address Selection for IPv6 - RFC 3484 5.9.4. Default Address Selection for IPv6 - RFC 3484
The rules specified in the Default Address Selection for IPv6 The rules specified in the Default Address Selection for IPv6
[RFC3484] document MUST be implemented. IPv6 nodes will need to deal [RFC3484] document MUST be implemented. IPv6 nodes will need to deal
with multiple addresses configured simultaneously. with multiple addresses configured simultaneously.
5.9.5. Stateful Address Autoconfiguration - RFC 3315 5.9.5. 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 address requirements, some of which may require DHCPv6 for 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
skipping to change at page 14, line 48 skipping to change at page 14, line 48
interoperability in such environments hosts would need to implement interoperability in such environments hosts would need to implement
multiple configuration mechanisms to ensure interoperability. multiple configuration mechanisms to ensure interoperability.
Originally in IPv6, configuring information about DNS servers was Originally in IPv6, configuring information about DNS servers was
performed exclusively via DHCP. In 2007, an RA option was defined, performed exclusively via DHCP. In 2007, an RA option was defined,
but was published as Experimental [RFC5006]. In 2010, "IPv6 Router but was published as Experimental [RFC5006]. In 2010, "IPv6 Router
Advertisement Options for DNS Configuration" [RFC6106] was published Advertisement Options for DNS Configuration" [RFC6106] was published
as a Standards Track Document. Consequently, DNS configuration as a Standards Track Document. Consequently, DNS configuration
information can now be learned either through DHCP or through RAs. information can now be learned either through DHCP or through RAs.
Hosts will need to decide which mechanism (or whether both) should be Hosts will need to decide which mechanism (or whether both) should be
implemented. implemented. Specific guidance regarding DNS server discovery is
discussed in Section 7.
7. DNS and DHCP 7. DNS and DHCP
7.1. DNS 7.1. 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 that applications rely on and most nodes will need to capability that applications rely on and most nodes will need to
skipping to change at page 19, line 28 skipping to change at page 19, line 28
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].
12. Router-Specific Functionality 12. 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. specific requirements.
12.1. General 12.1. IPv6 Router Alert Option - RFC 2711
12.1.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 MLD [RFC2710]). The Router Alert option will need to be [RFC2205] or MLD [RFC2710]). The Router Alert option will need to be
implemented whenever protocols that mandate its usage (e.g., MLD) are implemented whenever protocols that mandate its usage (e.g., MLD) are
implemented. See Section 5.9. implemented. See Section 5.9.
12.1.2. Neighbor Discovery for IPv6 - RFC 4861 12.2. Neighbor Discovery for IPv6 - RFC 4861
Sending Router Advertisements and processing Router Solicitation MUST Sending Router Advertisements and processing Router Solicitation MUST
be supported. be supported.
Section 7 of RFC 3775 includes some mobility-specific extensions to Section 7 of RFC 3775 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
A single DHCP server ([RFC3315] or [RFC4862]) can provide
configuration information to devices directly attached to a shared
link, as well as to devices located elsewhere within a site.
Communication between a client and a DHCP server located on different
links requires the use of DHCP relay agents on routers.
In simple deployments, consisting of a single router and either a
single LAN, or multiple LANs attached to the single router, together
with a WAN connection, a DHCP server embedded within the router is
one common deployment scenario (e.g., [RFC6204]). However, there is
no need for relay agents in such scenarios.
In more complex deployment scenarios, such as within enterprise or
service provider networks, the use of DHCP requires some level of
configuration, in order to configure relay agents, DHCP servers, etc.
In such environments, the DHCP server might even be run on a
traditional server, rather than as part of a router.
Because of the wide range of deployment scenarios, support for DHCP
server functionality on routers is optional. However, routers
targeted for deployment within more complex scenarios (as described
above) SHOULD support relay agent functionality. Note that "Basic
Requirements for IPv6 Customer Edge Routers" [RFC6204] requires
implementation of a DHCPv6 server function in IPv6 CE routers.
13. Network Management 13. 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.
13.1. Management Information Base Modules (MIBs) 13.1. Management Information Base Modules (MIBs)
The following two MIB modules SHOULD be supported by nodes that The following two MIB modules SHOULD be supported by nodes that
support an SNMP agent. support an SNMP agent.
skipping to change at page 21, line 42 skipping to change at page 22, line 19
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 One ID version to Another 17. Appendix: Changes from One ID version to Another
RFC Editor: Please remove this section upon publication. RFC Editor: Please remove this section upon publication.
17.1. Appendix: Changes from -09 to -10 17.1. Appendix: Changes from -10to -11
1. Editorial cleanups.
2. Added section on DHCPv6 for servers. SHOULD implement relay
agent functionality, MAY implement servers.
17.2. Appendix: Changes from -09 to -10
1. With changes in requirements for IPsec and Routing Headers, 1. With changes in requirements for IPsec and Routing Headers,
clarified language regarding processing of unknown options, and clarified language regarding processing of unknown options, and
removed paragraph lising which extension headers were required to removed paragraph lising which extension headers were required to
be implemented. be implemented.
2. Removed "RFC4292-bis" from title. 2. Removed "RFC4292-bis" from title.
3. Expanded the text on Jumbograms. 3. Expanded the text on Jumbograms.
4. Changed recommendation of DHCPv6 from MAY to SHOULD. 4. Changed recommendation of DHCPv6 from MAY to SHOULD.
5. Expanded the text on RFC4191, and changed recommendation from MAY 5. Expanded the text on RFC4191, and changed recommendation from MAY
to SHOULD. to SHOULD.
17.2. Appendix: Changes from -08 to -09 17.3. Appendix: Changes from -08 to -09
1. Updated MLD section to include reference to Lightweight MLD 1. Updated MLD section to include reference to Lightweight MLD
[RFC5790] [RFC5790]
17.3. Appendix: Changes from -07 to -08 17.4. Appendix: Changes from -07 to -08
1. Dropped reference to "Transmission of IPv6 over IPv4 Domains 1. Dropped reference to "Transmission of IPv6 over IPv4 Domains
without Explicit Tunnels" [RFC2429] in favor of a reference to without Explicit Tunnels" [RFC2429] in favor of a reference to
tunneling via Basic IPv6 Transition Mechanisms (RFC4313). tunneling via Basic IPv6 Transition Mechanisms (RFC4313).
2. Added reference to "Default Router Preferences and More-Specific 2. Added reference to "Default Router Preferences and More-Specific
Routes" [RFC4191] as a MAY. Routes" [RFC4191] as a MAY.
3. Added reference to "Optimistic Duplicate Address Detection (DAD) 3. Added reference to "Optimistic Duplicate Address Detection (DAD)
for IPv6" (RFC4429). for IPv6" (RFC4429).
4. Added reference to RFC4941 "Reserved IPv6 Interface Identifiers" 4. Added reference to RFC4941 "Reserved IPv6 Interface Identifiers"
5. Added Section on APIs. References are FYI, and none are 5. Added Section on APIs. References are FYI, and none are
required. required.
6. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311] 6. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311]
SHOULD be implemented SHOULD be implemented
7. Added reference to RFC5722 (Overlapping Fragments), made it a 7. Added reference to RFC5722 (Overlapping Fragments), made it a
MUST to implement. MUST to implement.
8. Made "A Recommendation for IPv6 Address Text Representation" 8. Made "A Recommendation for IPv6 Address Text Representation"
skipping to change at page 22, line 33 skipping to change at page 23, line 17
4. Added reference to RFC4941 "Reserved IPv6 Interface Identifiers" 4. Added reference to RFC4941 "Reserved IPv6 Interface Identifiers"
5. Added Section on APIs. References are FYI, and none are 5. Added Section on APIs. References are FYI, and none are
required. required.
6. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311] 6. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311]
SHOULD be implemented SHOULD be implemented
7. Added reference to RFC5722 (Overlapping Fragments), made it a 7. Added reference to RFC5722 (Overlapping Fragments), made it a
MUST to implement. MUST to implement.
8. Made "A Recommendation for IPv6 Address Text Representation" 8. Made "A Recommendation for IPv6 Address Text Representation"
[RFC5952] a SHOULD. [RFC5952] a SHOULD.
17.4. Appendix: Changes from -06 to -07 17.5. Appendix: Changes from -06 to -07
1. Added recommendation that routers implement Section 7.3 and 7.5 1. Added recommendation that routers implement Section 7.3 and 7.5
of RFC 3775. of RFC 3775.
2. "IPv6 Router Advertisement Options for DNS Configuration" (RFC 2. "IPv6 Router Advertisement Options for DNS Configuration" (RFC
6106) has been published. 6106) has been published.
3. Further clarifications to the MLD recommendation. 3. Further clarifications to the MLD recommendation.
4. "Extended ICMP to Support Multi- Part Messages" [RFC4884] added 4. "Extended ICMP to Support Multi- Part Messages" [RFC4884] added
as a MAY. as a MAY.
5. Added pointer to subnet clarification document (RFC 5942). 5. Added pointer to subnet clarification document (RFC 5942).
6. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311] 6. Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311]
SHOULD be implemented SHOULD be implemented
7. Added reference to RFC5722 (Overlapping Fragments), made it a 7. Added reference to RFC5722 (Overlapping Fragments), made it a
MUST to implement. MUST to implement.
8. Made "A Recommendation for IPv6 Address Text Representation" 8. Made "A Recommendation for IPv6 Address Text Representation"
[RFC5952] a SHOULD. [RFC5952] a SHOULD.
17.5. Appendix: Changes from -05 to -06 17.6. Appendix: Changes from -05 to -06
1. Completely revised IPsec/IKEv2 section. Text has been discussed 1. Completely revised IPsec/IKEv2 section. Text has been discussed
by 6man and saag. by 6man and saag.
2. Added text to introduction clarifying that this document applies 2. Added text to introduction clarifying that this document applies
to general nodes and that other profiles may be more specific in to general nodes and that other profiles may be more specific in
their requirements their requirements
3. Editorial cleanups in Neighbor Discovery section in particular. 3. Editorial cleanups in Neighbor Discovery section in particular.
Text made more crisp. Text made more crisp.
4. Moved some of the DHCP text around. Moved stateful address 4. Moved some of the DHCP text around. Moved stateful address
discussion to Section 5.8.5. discussion to Section 5.8.5.
5. Added additional nuance to the redirect requirements w.r.t. 5. Added additional nuance to the redirect requirements w.r.t.
default configuration setting. default configuration setting.
17.6. Appendix: Changes from -04 to -05 17.7. Appendix: Changes from -04 to -05
1. Cleaned up IPsec section, but key questions (MUST vs. SHOULD) 1. Cleaned up IPsec section, but key questions (MUST vs. SHOULD)
still open. still open.
2. Added background section on DHCP vs. RA options. 2. Added background section on DHCP vs. RA options.
3. Added SHOULD recommendation for DNS configuration vi RAs 3. Added SHOULD recommendation for DNS configuration vi RAs
(RFC5006bis). (RFC5006bis).
4. Cleaned up DHCP section, as it was referring to the M&O bits. 4. Cleaned up DHCP section, as it was referring to the M&O bits.
5. Cleaned up the Security Considerations Section. 5. Cleaned up the Security Considerations Section.
17.7. Appendix: Changes from -03 to -04 17.8. Appendix: Changes from -03 to -04
1. Updated the Introduction to indicate document is an applicability 1. Updated the Introduction to indicate document is an applicability
statement statement
2. Updated the section on Mobility protocols 2. Updated the section on Mobility protocols
3. Changed Sub-IP Layer Section to just list relevant RFCs, and 3. Changed Sub-IP Layer Section to just list relevant RFCs, and
added some more RFCs. added some more RFCs.
4. Added Section on SEND (make it a MAY) 4. Added Section on SEND (make it a MAY)
5. Redid Section on Privacy Extensions (RFC4941) to add more nuance 5. Redid Section on Privacy Extensions (RFC4941) to add more nuance
to recommendation to recommendation
6. Redid section on Mobility, and added additional RFCs. 6. Redid section on Mobility, and added additional RFCs.
 End of changes. 24 change blocks. 
43 lines changed or deleted 79 lines changed or added

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