doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

diff --git a/doc/rfc/rfc6434.txt b/doc/rfc/rfc6434.txt
new file mode 100644
index 0000000..4c62ee8
--- /dev/null
+++ b/doc/rfc/rfc6434.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     E. Jankiewicz
+Request for Comments: 6434                       SRI International, Inc.
+Obsoletes: 4294                                              J. Loughney
+Category: Informational                                            Nokia
+ISSN: 2070-1721                                                T. Narten
+                                                         IBM Corporation
+                                                           December 2011
+
+
+                         IPv6 Node Requirements
+
+Abstract
+
+   This document defines requirements for IPv6 nodes.  It is expected
+   that IPv6 will be deployed in a wide range of devices and situations.
+   Specifying the requirements for IPv6 nodes allows IPv6 to function
+   well and interoperate in a large number of situations and
+   deployments.
+
+   This document obsoletes RFC 4294.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6434.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+
+
+
+Jankiewicz, et al.            Informational                     [Page 1]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.1.  Scope of This Document . . . . . . . . . . . . . . . . . .  5
+     1.2.  Description of IPv6 Nodes  . . . . . . . . . . . . . . . .  5
+   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  5
+   3.  Abbreviations Used in This Document  . . . . . . . . . . . . .  5
+   4.  Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   5.  IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+     5.1.  Internet Protocol Version 6 - RFC 2460 . . . . . . . . . .  7
+     5.2.  Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . .  8
+     5.3.  Default Router Preferences and More-Specific Routes -
+           RFC 4191 . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     5.4.  SEcure Neighbor Discovery (SEND) - RFC 3971  . . . . . . .  9
+     5.5.  IPv6 Router Advertisement Flags Option - RFC 5175  . . . .  9
+     5.6.  Path MTU Discovery and Packet Size . . . . . . . . . . . . 10
+       5.6.1.  Path MTU Discovery - RFC 1981  . . . . . . . . . . . . 10
+     5.7.  IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . . 10
+     5.8.  ICMP for the Internet Protocol Version 6 (IPv6) - RFC
+           4443 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     5.9.  Addressing . . . . . . . . . . . . . . . . . . . . . . . . 11
+       5.9.1.  IP Version 6 Addressing Architecture - RFC 4291  . . . 11
+       5.9.2.  IPv6 Stateless Address Autoconfiguration - RFC 4862  . 11
+       5.9.3.  Privacy Extensions for Address Configuration in
+               IPv6 - RFC 4941  . . . . . . . . . . . . . . . . . . . 12
+       5.9.4.  Default Address Selection for IPv6 - RFC 3484  . . . . 12
+       5.9.5.  Stateful Address Autoconfiguration (DHCPv6) - RFC
+               3315 . . . . . . . . . . . . . . . . . . . . . . . . . 12
+     5.10. Multicast Listener Discovery (MLD) for IPv6  . . . . . . . 13
+   6.  DHCP versus Router Advertisement Options for Host
+       Configuration  . . . . . . . . . . . . . . . . . . . . . . . . 13
+   7.  DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 14
+
+
+
+Jankiewicz, et al.            Informational                     [Page 2]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+     7.1.  DNS  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+     7.2.  Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+           - RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 15
+       7.2.1.  Other Configuration Information  . . . . . . . . . . . 15
+       7.2.2.  Use of Router Advertisements in Managed
+               Environments . . . . . . . . . . . . . . . . . . . . . 15
+     7.3.  IPv6 Router Advertisement Options for DNS
+           Configuration - RFC 6106 . . . . . . . . . . . . . . . . . 15
+   8.  IPv4 Support and Transition  . . . . . . . . . . . . . . . . . 16
+     8.1.  Transition Mechanisms  . . . . . . . . . . . . . . . . . . 16
+       8.1.1.  Basic Transition Mechanisms for IPv6 Hosts and
+               Routers - RFC 4213 . . . . . . . . . . . . . . . . . . 16
+   9.  Application Support  . . . . . . . . . . . . . . . . . . . . . 16
+     9.1.  Textual Representation of IPv6 Addresses - RFC 5952  . . . 16
+     9.2.  Application Programming Interfaces (APIs)  . . . . . . . . 16
+   10. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+   11. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+     11.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18
+     11.2. Transforms and Algorithms  . . . . . . . . . . . . . . . . 19
+   12. Router-Specific Functionality  . . . . . . . . . . . . . . . . 19
+     12.1. IPv6 Router Alert Option - RFC 2711  . . . . . . . . . . . 19
+     12.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 19
+     12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . . 19
+   13. Network Management . . . . . . . . . . . . . . . . . . . . . . 20
+     13.1. Management Information Base (MIB) Modules  . . . . . . . . 20
+       13.1.1. IP Forwarding Table MIB  . . . . . . . . . . . . . . . 20
+       13.1.2. Management Information Base for the Internet
+               Protocol (IP)  . . . . . . . . . . . . . . . . . . . . 20
+   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
+   15. Authors and Acknowledgments  . . . . . . . . . . . . . . . . . 21
+     15.1. Authors and Acknowledgments (Current Document) . . . . . . 21
+     15.2. Authors and Acknowledgments from RFC 4279  . . . . . . . . 21
+   16. Appendix: Changes from RFC 4294  . . . . . . . . . . . . . . . 22
+   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+     17.1. Normative References . . . . . . . . . . . . . . . . . . . 23
+     17.2. Informative References . . . . . . . . . . . . . . . . . . 26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                     [Page 3]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+1.  Introduction
+
+   This document defines common functionality required from both IPv6
+   hosts and routers.  Many IPv6 nodes will implement optional or
+   additional features, but this document collects and summarizes
+   requirements from other published Standards Track documents in one
+   place.
+
+   This document tries to avoid discussion of protocol details and
+   references RFCs for this purpose.  This document is intended to be an
+   applicability statement and to provide guidance as to which IPv6
+   specifications should be implemented in the general case and which
+   specifications may be of interest to specific deployment scenarios.
+   This document does not update any individual protocol document RFCs.
+
+   Although this document points to different specifications, it should
+   be noted that in many cases, the granularity of a particular
+   requirement will be smaller than a single specification, as many
+   specifications define multiple, independent pieces, some of which may
+   not be mandatory.  In addition, most specifications define both
+   client and server behavior in the same specification, while many
+   implementations will be focused on only one of those roles.
+
+   This document defines a minimal level of requirement needed for a
+   device to provide useful internet service and considers a broad range
+   of device types and deployment scenarios.  Because of the wide range
+   of deployment scenarios, the minimal requirements specified in this
+   document may not be sufficient for all deployment scenarios.  It is
+   perfectly reasonable (and indeed expected) for other profiles to
+   define additional or stricter requirements appropriate for specific
+   usage and deployment environments.  For example, this document does
+   not mandate that all clients support DHCP, but some deployment
+   scenarios may deem it appropriate to make such a requirement.  For
+   example, government agencies in the USA have defined profiles for
+   specialized requirements for IPv6 in target environments (see [DODv6]
+   and [USGv6]).
+
+   As it is not always possible for an implementer to know the exact
+   usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
+   that they should adhere to Jon Postel's Robustness Principle: "Be
+   conservative in what you do, be liberal in what you accept from
+   others" [RFC0793].
+
+
+
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                     [Page 4]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+1.1.  Scope of This Document
+
+   IPv6 covers many specifications.  It is intended that IPv6 will be
+   deployed in many different situations and environments.  Therefore,
+   it is important to develop requirements for IPv6 nodes to ensure
+   interoperability.
+
+   This document assumes that all IPv6 nodes meet the minimum
+   requirements specified here.
+
+1.2.  Description of IPv6 Nodes
+
+   From the Internet Protocol, Version 6 (IPv6) Specification [RFC2460],
+   we have the following definitions:
+
+   IPv6 node   - a device that implements IPv6.
+
+   IPv6 router - a node that forwards IPv6 packets not explicitly
+                 addressed to itself.
+
+   IPv6 host   - any node that is not a router.
+
+2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+3.  Abbreviations Used in This Document
+
+   ATM   Asynchronous Transfer Mode
+
+   AH    Authentication Header
+
+   DAD   Duplicate Address Detection
+
+   ESP   Encapsulating Security Payload
+
+   ICMP  Internet Control Message Protocol
+
+   IKE   Internet Key Exchange
+
+   MIB   Management Information Base
+
+   MLD   Multicast Listener Discovery
+
+   MTU   Maximum Transmission Unit
+
+
+
+
+Jankiewicz, et al.            Informational                     [Page 5]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   NA    Neighbor Advertisement
+
+   NBMA  Non-Broadcast Multiple Access
+
+   ND    Neighbor Discovery
+
+   NS    Neighbor Solicitation
+
+   NUD   Neighbor Unreachability Detection
+
+   PPP   Point-to-Point Protocol
+
+4.  Sub-IP Layer
+
+   An IPv6 node must include support for one or more IPv6 link-layer
+   specifications.  Which link-layer specifications an implementation
+   should include will depend upon what link-layers are supported by the
+   hardware available on the system.  It is possible for a conformant
+   IPv6 node to support IPv6 on some of its interfaces and not on
+   others.
+
+   As IPv6 is run over new layer 2 technologies, it is expected that new
+   specifications will be issued.  In the following, we list some of the
+   layer 2 technologies for which an IPv6 specification has been
+   developed.  It is provided for informational purposes only and may
+   not be complete.
+
+   -  Transmission of IPv6 Packets over Ethernet Networks [RFC2464]
+
+   -  IPv6 over ATM Networks [RFC2492]
+
+   -  Transmission of IPv6 Packets over Frame Relay Networks
+      Specification [RFC2590]
+
+   -  Transmission of IPv6 Packets over IEEE 1394 Networks [RFC3146]
+
+   -  Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP)
+      Packets over Fibre Channel [RFC4338]
+
+   -  Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944]
+
+   -  Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE
+      802.16 Networks [RFC5121]
+
+   -  IP version 6 over PPP [RFC5072]
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                     [Page 6]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   In addition to traditional physical link-layers, it is also possible
+   to tunnel IPv6 over other protocols.  Examples include:
+
+   -  Teredo: Tunneling IPv6 over UDP through Network Address
+      Translations (NATs) [RFC4380]
+
+   -  Section 3 of "Basic Transition Mechanisms for IPv6 Hosts and
+      Routers" [RFC4213]
+
+5.  IP Layer
+
+5.1.  Internet Protocol Version 6 - RFC 2460
+
+   The Internet Protocol Version 6 is specified in [RFC2460].  This
+   specification MUST be supported.
+
+   Any unrecognized extension headers or options MUST be processed as
+   described 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
+   headers.  All conformant IPv6 implementations MUST be capable of
+   sending and receiving IPv6 packets; the forwarding functionality MAY
+   be supported.  Overlapping fragments MUST be handled as described in
+   [RFC5722].
+
+   RFC 2460 specifies extension headers and the processing for these
+   headers.
+
+   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
+   security concerns and which MUST be treated as an unrecognized
+   routing type.
+
+   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.
+
+
+
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                     [Page 7]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+5.2.  Neighbor Discovery for IPv6 - RFC 4861
+
+   Neighbor Discovery is defined in [RFC4861]; the definition was
+   updated by [RFC5942].  Neighbor Discovery SHOULD be supported.  RFC
+   4861 states:
+
+      Unless specified otherwise (in a document that covers operating IP
+      over a particular link type) this document applies to all link
+      types.  However, because ND uses link-layer multicast for some of
+      its services, it is possible that on some link types (e.g., Non-
+      Broadcast Multi-Access (NBMA) links), alternative protocols or
+      mechanisms to implement those services will be specified (in the
+      appropriate document covering the operation of IP over a
+      particular link type).  The services described in this document
+      that are not directly dependent on multicast, such as Redirects,
+      next-hop determination, Neighbor Unreachability Detection, etc.,
+      are expected to be provided as specified in this document.  The
+      details of how one uses ND on NBMA links are addressed in
+      [RFC2491].
+
+   Some detailed analysis of Neighbor Discovery follows:
+
+   Router Discovery is how hosts locate routers that reside on an
+   attached link.  Hosts MUST support Router Discovery functionality.
+
+   Prefix Discovery is how hosts discover the set of address prefixes
+   that define which destinations are on-link for an attached link.
+   Hosts MUST support Prefix Discovery.
+
+   Hosts MUST also implement Neighbor Unreachability Detection (NUD) for
+   all paths between hosts and neighboring nodes.  NUD is not required
+   for paths between routers.  However, all nodes MUST respond to
+   unicast Neighbor Solicitation (NS) messages.
+
+   Hosts MUST support the sending of Router Solicitations and the
+   receiving of Router Advertisements.  The ability to understand
+   individual Router Advertisement options is dependent on supporting
+   the functionality making use of the particular option.
+
+   All nodes MUST support the sending and receiving of Neighbor
+   Solicitation (NS) and Neighbor Advertisement (NA) messages.  NS and
+   NA messages are required for Duplicate Address Detection (DAD).
+
+   Hosts SHOULD support the processing of Redirect functionality.
+   Routers MUST support the sending of Redirects, though not necessarily
+   for every individual packet (e.g., due to rate limiting).  Redirects
+   are only useful on networks supporting hosts.  In core networks
+   dominated by routers, Redirects are typically disabled.  The sending
+
+
+
+Jankiewicz, et al.            Informational                     [Page 8]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   of Redirects SHOULD be disabled by default on backbone routers.  They
+   MAY be enabled by default on routers intended to support hosts on
+   edge networks.
+
+   "IPv6 Host-to-Router Load Sharing" [RFC4311] includes additional
+   recommendations on how to select from a set of available routers.
+   [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 [RFC6204] 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
+
+   SEND [RFC3971] and Cryptographically Generated Address (CGA)
+   [RFC3972] provide a way to secure the message exchanges of Neighbor
+   Discovery.  SEND is a new technology in that it has no IPv4
+   counterpart, but it has significant potential to address certain
+   classes of spoofing attacks.  While there have been some
+   implementations of SEND, there has been only limited deployment
+   experience to date in using the technology.  In addition, the IETF
+   working group Cga & Send maIntenance (csi) is currently working on
+   additional extensions intended to make SEND more attractive for
+   deployment.
+
+   At this time, SEND is considered optional, and IPv6 nodes MAY provide
+   SEND functionality.
+
+5.5.  IPv6 Router Advertisement Flags Option - RFC 5175
+
+   Router Advertisements include an 8-bit field of single-bit Router
+   Advertisement flags.  The Router Advertisement Flags Option extends
+   the number of available flag bits by 48 bits.  At the time of this
+   writing, 6 of the original 8 single-bit flags have been assigned,
+   while 2 remain available for future assignment.  No flags have been
+   defined that make use of the new option, and thus, strictly speaking,
+   there is no requirement to implement the option today.  However,
+
+
+
+Jankiewicz, et al.            Informational                     [Page 9]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   implementations that are able to pass unrecognized options to a
+   higher-level entity that may be able to understand them (e.g., a
+   user-level process using a "raw socket" facility) MAY take steps to
+   handle the option in anticipation of a future usage.
+
+5.6.  Path MTU Discovery and Packet Size
+
+5.6.1.  Path MTU Discovery - RFC 1981
+
+   "Path MTU Discovery for IP version 6" [RFC1981] SHOULD be supported.
+   From [RFC2460]:
+
+      It is strongly recommended that IPv6 nodes implement Path MTU
+      Discovery [RFC1981], in order to discover and take advantage of
+      path MTUs greater than 1280 octets.  However, a minimal IPv6
+      implementation (e.g., in a boot ROM) may simply restrict itself to
+      sending packets no larger than 1280 octets, and omit
+      implementation of Path MTU Discovery.
+
+   The rules in [RFC2460] and [RFC5722] MUST be followed for packet
+   fragmentation and reassembly.
+
+   One operational issue with Path MTU Discovery occurs when firewalls
+   block ICMP Packet Too Big messages.  Path MTU Discovery relies on
+   such messages to determine what size messages can be successfully
+   sent.  "Packetization Layer Path MTU Discovery" [RFC4821] avoids
+   having a dependency on Packet Too Big messages.
+
+5.7.  IPv6 Jumbograms - RFC 2675
+
+   IPv6 Jumbograms [RFC2675] are an optional extension that allow the
+   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
+   which every hop and link are capable of supporting Jumbograms (e.g.,
+   within a campus or datacenter).  To date, few implementations exist,
+   and there is essentially no reported experience from usage.
+
+   Consequently, IPv6 Jumbograms [RFC2675] remain optional at this time.
+
+5.8.  ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443
+
+   ICMPv6 [RFC4443] MUST be supported.  "Extended ICMP to Support Multi-
+   Part Messages" [RFC4884] MAY be supported.
+
+
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 10]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+5.9.  Addressing
+
+5.9.1.  IP Version 6 Addressing Architecture - RFC 4291
+
+   The IPv6 Addressing Architecture [RFC4291] MUST be supported.
+
+5.9.2.  IPv6 Stateless Address Autoconfiguration - RFC 4862
+
+   Hosts MUST support IPv6 Stateless Address Autoconfiguration as
+   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
+   as described in [RFC4862].
+
+   From RFC 4862:
+
+      The autoconfiguration process specified in this document applies
+      only to hosts and not routers.  Since host autoconfiguration uses
+      information advertised by routers, routers will need to be
+      configured by some other means.  However, it is expected that
+      routers will generate link-local addresses using the mechanism
+      described in this document.  In addition, routers are expected to
+      successfully pass the Duplicate Address Detection procedure
+      described in this document on all addresses prior to assigning
+      them to an interface.
+
+   All nodes MUST implement Duplicate Address Detection.  Quoting from
+   Section 5.4 of RFC 4862:
+
+      Duplicate Address Detection MUST be performed on all unicast
+      addresses prior to assigning them to an interface, regardless of
+      whether they are obtained through stateless autoconfiguration,
+      DHCPv6, or manual configuration, with the following [exceptions
+      noted therein].
+
+   "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429]
+   specifies a mechanism to reduce delays associated with generating
+   addresses via Stateless Address Autoconfiguration [RFC4862].  RFC
+   4429 was developed in conjunction with Mobile IPv6 in order to reduce
+   the time needed to acquire and configure addresses as devices quickly
+   move from one network to another, and it is desirable to minimize
+   transition delays.  For general purpose devices, RFC 4429 remains
+   optional at this time.
+
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 11]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+5.9.3.  Privacy Extensions for Address Configuration in IPv6 - RFC 4941
+
+   Privacy Extensions for Stateless Address Autoconfiguration [RFC4941]
+   addresses a specific problem involving a client device whose user is
+   concerned about its activity or location being tracked.  The problem
+   arises both for a static client and for one that regularly changes
+   its point of attachment to the Internet.  When using Stateless
+   Address Autoconfiguration [RFC4862], the Interface Identifier portion
+   of formed addresses stays constant and is globally unique.  Thus,
+   although a node's global IPv6 address will change if it changes its
+   point of attachment, the Interface Identifier portion of those
+   addresses remains the same, making it possible for servers to track
+   the location of an individual device as it moves around or its
+   pattern of activity if it remains in one place.  This may raise
+   privacy concerns as described in [RFC4862].
+
+   In such situations, RFC 4941 SHOULD be implemented.  In other cases,
+   such as with dedicated servers in a data center, RFC 4941 provides
+   limited or no benefit.
+
+   Implementers of RFC 4941 should be aware that certain addresses are
+   reserved and should not be chosen for use as temporary addresses.
+   Consult "Reserved IPv6 Interface Identifiers" [RFC5453] for more
+   details.
+
+5.9.4.  Default Address Selection for IPv6 - RFC 3484
+
+   The rules specified in the Default Address Selection for IPv6
+   [RFC3484] document MUST be implemented.  IPv6 nodes will need to deal
+   with multiple addresses configured simultaneously.
+
+5.9.5.  Stateful Address Autoconfiguration (DHCPv6) - RFC 3315
+
+   DHCPv6 [RFC3315] can be used to obtain and configure addresses.  In
+   general, a network may provide for the configuration of addresses
+   through Router Advertisements, DHCPv6, or both.  There will be a wide
+   range of IPv6 deployment models and differences in address assignment
+   requirements, some of which may require DHCPv6 for address
+   assignment.  Consequently, all hosts SHOULD implement address
+   configuration via DHCPv6.
+
+   In the absence of a router, IPv6 nodes using DHCP for address
+   assignment MAY initiate DHCP to obtain IPv6 addresses and other
+   configuration information, as described in Section 5.5.2 of
+   [RFC4862].
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 12]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+5.10.  Multicast Listener Discovery (MLD) for IPv6
+
+   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 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
+
+   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
+
+
+
+Jankiewicz, et al.            Informational                    [Page 13]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   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.
+
+   Originally, in IPv6, configuring information about DNS servers was
+   performed exclusively via DHCP.  In 2007, an RA option was defined
+   but was published as Experimental [RFC5006].  In 2010, "IPv6 Router
+   Advertisement Options for DNS Configuration" [RFC6106] was published
+   as a Standards Track document.  Consequently, DNS configuration
+   information can now be learned either through DHCP or through RAs.
+   Hosts will need to decide which mechanism (or whether both) should be
+   implemented.  Specific guidance regarding DNS server discovery is
+   discussed in Section 7.
+
+7.  DNS and DHCP
+
+7.1.  DNS
+
+   DNS is described in [RFC1034], [RFC1035], [RFC3363], and [RFC3596].
+   Not all nodes will need to resolve names; those that will never need
+   to resolve DNS names do not need to implement resolver functionality.
+   However, the ability to resolve names is a basic infrastructure
+   capability on which applications rely, and most nodes will need to
+   provide support.  All nodes SHOULD implement stub-resolver [RFC1034]
+   functionality, as in [RFC1034], Section 5.3.1, with support for:
+
+   -  AAAA type Resource Records [RFC3596];
+
+   -  reverse addressing in ip6.arpa using PTR records [RFC3596];
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 14]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   -  Extension Mechanisms for DNS (EDNS0) [RFC2671] to allow for DNS
+      packet sizes larger than 512 octets.
+
+   Those nodes are RECOMMENDED to support DNS security extensions
+   [RFC4033] [RFC4034] [RFC4035].
+
+   Those nodes are NOT RECOMMENDED to support the experimental A6
+   Resource Records [RFC3363].
+
+7.2.  Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315
+
+7.2.1.  Other Configuration Information
+
+   IPv6 nodes use DHCP [RFC3315] to obtain address configuration
+   information (see Section 5.9.5) and to obtain additional (non-
+   address) configuration.  If a host implementation supports
+   applications or other protocols that require configuration that is
+   only available via DHCP, hosts SHOULD implement DHCP.  For
+   specialized devices on which no such configuration need is present,
+   DHCP may not be necessary.
+
+   An IPv6 node can use the subset of DHCP (described in [RFC3736]) to
+   obtain other configuration information.
+
+7.2.2.  Use of Router Advertisements in Managed Environments
+
+   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+   are expected to determine their default router information and on-
+   link prefix information from received Router Advertisements.
+
+7.3.  IPv6 Router Advertisement Options for DNS Configuration - RFC 6106
+
+   Router Advertisements have historically limited options to those that
+   are critical to basic IPv6 functioning.  Originally, DNS
+   configuration was not included as an RA option, and DHCP was the
+   recommended way to obtain DNS configuration information.  Over time,
+   the thinking surrounding such an option has evolved.  It is now
+   generally recognized that few nodes can function adequately without
+   having access to a working DNS resolver.  [RFC5006] was published as
+   an Experimental document in 2007, and recently, a revised version was
+   placed on the Standards Track [RFC6106].
+
+   Implementations SHOULD implement the DNS RA option [RFC6106].
+
+
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 15]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+8.  IPv4 Support and Transition
+
+   IPv6 nodes MAY support IPv4.
+
+8.1.  Transition Mechanisms
+
+8.1.1.  Basic Transition Mechanisms for IPv6 Hosts and Routers - RFC
+        4213
+
+   If an IPv6 node implements dual stack and tunneling, then [RFC4213]
+   MUST be supported.
+
+9.  Application Support
+
+9.1.  Textual Representation of IPv6 Addresses - RFC 5952
+
+   Software that allows users and operators to input IPv6 addresses in
+   text form SHOULD support "A Recommendation for IPv6 Address Text
+   Representation" [RFC5952].
+
+9.2.  Application Programming Interfaces (APIs)
+
+   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
+   relate to on-the-wire behavior of protocols.  Implementers, however,
+   would be advised to consider providing a common API or reviewing
+   existing APIs for the type of functionality they provide to
+   applications.
+
+   "Basic Socket Interface Extensions for IPv6" [RFC3493] provides IPv6
+   functionality used by typical applications.  Implementers should note
+   that RFC3493 has been picked up and further standardized by the
+   Portable Operating System Interface (POSIX) [POSIX].
+
+   "Advanced Sockets Application Program Interface (API) for IPv6"
+   [RFC3542] provides access to advanced IPv6 features needed by
+   diagnostic and other more specialized applications.
+
+   "IPv6 Socket API for Source Address Selection" [RFC5014] provides
+   facilities that allow an application to override the default Source
+   Address Selection rules of [RFC3484].
+
+   "Socket Interface Extensions for Multicast Source Filters" [RFC3678]
+   provides support for expressing source filters on multicast group
+   memberships.
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 16]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   "Extension to Sockets API for Mobile IPv6" [RFC4584] provides
+   application support for accessing and enabling Mobile IPv6 [RFC6275]
+   features.
+
+10.  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.
+
+11.  Security
+
+   This section describes the specification for security for IPv6 nodes.
+
+   Achieving security in practice is a complex undertaking.  Operational
+   procedures, protocols, key distribution mechanisms, certificate
+   management approaches, etc., are all components that impact the level
+   of security actually achieved in practice.  More importantly,
+   deficiencies or a poor fit in any one individual component can
+   significantly reduce the overall effectiveness of a particular
+   security approach.
+
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 17]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   IPsec provides channel security at the Internet layer, making it
+   possible to provide secure communication for all (or a subset of)
+   communication flows at the IP layer between pairs of internet nodes.
+   IPsec provides sufficient flexibility and granularity that individual
+   TCP connections can (selectively) be protected, etc.
+
+   Although IPsec can be used with manual keying in some cases, such
+   usage has limited applicability and is not recommended.
+
+   A range of security technologies and approaches proliferate today
+   (e.g., IPsec, Transport Layer Security (TLS), Secure SHell (SSH),
+   etc.)  No one approach has emerged as an ideal technology for all
+   needs and environments.  Moreover, IPsec is not viewed as the ideal
+   security technology in all cases and is unlikely to displace the
+   others.
+
+   Previously, IPv6 mandated implementation of IPsec and recommended the
+   key management approach of IKE.  This document updates that
+   recommendation by making support of the IPsec Architecture [RFC4301]
+   a SHOULD for all IPv6 nodes.  Note that the IPsec Architecture
+   requires (e.g., Section 4.5 of RFC 4301) the implementation of both
+   manual and automatic key management.  Currently, the default
+   automated key management protocol to implement is IKEv2 [RFC5996].
+
+   This document recognizes that there exists a range of device types
+   and environments where approaches to security other than IPsec can be
+   justified.  For example, special-purpose devices may support only a
+   very limited number or type of applications, and an application-
+   specific security approach may be sufficient for limited management
+   or configuration capabilities.  Alternatively, some devices may run
+   on extremely constrained hardware (e.g., sensors) where the full
+   IPsec Architecture is not justified.
+
+11.1.  Requirements
+
+   "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be
+   supported by all IPv6 nodes.  Note that the IPsec Architecture
+   requires (e.g., Section 4.5 of [RFC4301]) the implementation of both
+   manual and automatic key management.  Currently, the default
+   automated key management protocol to implement is IKEv2.  As required
+   in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST
+   implement ESP [RFC4303] and MAY implement AH [RFC4302].
+
+
+
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 18]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+11.2.  Transforms and Algorithms
+
+   The current set of mandatory-to-implement algorithms for the IPsec
+   Architecture are defined in "Cryptographic Algorithm Implementation
+   Requirements For ESP and AH" [RFC4835].  IPv6 nodes implementing the
+   IPsec Architecture MUST conform to the requirements in [RFC4835].
+   Preferred cryptographic algorithms often change more frequently than
+   security protocols.  Therefore, implementations MUST allow for
+   migration to new algorithms, as RFC 4835 is replaced or updated in
+   the future.
+
+   The current set of mandatory-to-implement algorithms for IKEv2 are
+   defined in "Cryptographic Algorithms for Use in the Internet Key
+   Exchange Version 2 (IKEv2)" [RFC4307].  IPv6 nodes implementing IKEv2
+   MUST conform to the requirements in [RFC4307] and/or any future
+   updates or replacements to [RFC4307].
+
+12.  Router-Specific Functionality
+
+   This section defines general host considerations for IPv6 nodes that
+   act as routers.  Currently, this section does not discuss routing-
+   specific requirements.
+
+12.1.  IPv6 Router Alert Option - RFC 2711
+
+   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
+   [RFC2205] or Multicast Listener Discovery (MLD) [RFC2710]).  The
+   Router Alert option will need to be implemented whenever protocols
+   that mandate its usage (e.g., MLD) are implemented.  See
+   Section 5.10.
+
+12.2.  Neighbor Discovery for IPv6 - RFC 4861
+
+   Sending Router Advertisements and processing Router Solicitations
+   MUST be supported.
+
+   Section 7 of [RFC6275] includes some mobility-specific extensions to
+   Neighbor Discovery.  Routers SHOULD implement Sections 7.3 and 7.5,
+   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.
+
+
+
+Jankiewicz, et al.            Informational                    [Page 19]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   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 Customer Edge (CE)
+   routers.
+
+13.  Network Management
+
+   Network management MAY be supported by IPv6 nodes.  However, for IPv6
+   nodes that are embedded devices, network management may be the only
+   possible way of controlling these nodes.
+
+13.1.  Management Information Base (MIB) Modules
+
+   The following two MIB modules SHOULD be supported by nodes that
+   support a Simple Network Management Protocol (SNMP) agent.
+
+13.1.1.  IP Forwarding Table MIB
+
+   The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes
+   that support an SNMP agent.
+
+13.1.2.  Management Information Base for the Internet Protocol (IP)
+
+   The IP MIB [RFC4293] SHOULD be supported by nodes that support an
+   SNMP agent.
+
+14.  Security Considerations
+
+   This document does not directly affect the security of the Internet,
+   beyond the security considerations associated with the individual
+   protocols.
+
+   Security is also discussed in Section 11 above.
+
+
+
+Jankiewicz, et al.            Informational                    [Page 20]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+15.  Authors and Acknowledgments
+
+15.1.  Authors and Acknowledgments (Current Document)
+
+   For this version of the IPv6 Node Requirements document, the authors
+   would like to thank Hitoshi Asaeda, Brian Carpenter, Tim Chown, Ralph
+   Droms, Sheila Frankel, Sam Hartman, Bob Hinden, Paul Hoffman, Pekka
+   Savola, Yaron Sheffer, and Dave Thaler for their comments.
+
+15.2.  Authors and Acknowledgments from RFC 4279
+
+   The original version of this document (RFC 4279) was written by the
+   IPv6 Node Requirements design team:
+
+      Jari Arkko
+      jari.arkko@ericsson.com
+
+      Marc Blanchet
+      marc.blanchet@viagenie.qc.ca
+
+      Samita Chakrabarti
+      samita.chakrabarti@eng.sun.com
+
+      Alain Durand
+      alain.durand@sun.com
+
+      Gerard Gastaud
+      gerard.gastaud@alcatel.fr
+
+      Jun-ichiro Itojun Hagino
+      itojun@iijlab.net
+
+      Atsushi Inoue
+      inoue@isl.rdc.toshiba.co.jp
+
+      Masahiro Ishiyama
+      masahiro@isl.rdc.toshiba.co.jp
+
+      John Loughney
+      john.loughney@nokia.com
+
+      Rajiv Raghunarayan
+      raraghun@cisco.com
+
+      Shoichi Sakane
+      shouichi.sakane@jp.yokogawa.com
+
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 21]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+      Dave Thaler
+      dthaler@windows.microsoft.com
+
+      Juha Wiljakka
+      juha.wiljakka@Nokia.com
+
+   The authors would like to thank Ran Atkinson, Jim Bound, Brian
+   Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas
+   Narten, Juha Ollila, and Pekka Savola for their comments.  Thanks to
+   Mark Andrews for comments and corrections on DNS text.  Thanks to
+   Alfred Hoenes for tracking the updates to various RFCs.
+
+16.  Appendix: Changes from RFC 4294
+
+   There have been many editorial clarifications as well as significant
+   additions and updates.  While this section highlights some of the
+   changes, readers should not rely on this section for a comprehensive
+   list of all changes.
+
+   1.   Updated the Introduction to indicate that this document is an
+        applicability statement and is aimed at general nodes.
+
+   2.   Significantly updated the section on Mobility protocols, adding
+        references and downgrading previous SHOULDs to MAYs.
+
+   3.   Changed Sub-IP Layer section to just list relevant RFCs, and
+        added some more RFCs.
+
+   4.   Added section on SEND (it is a MAY).
+
+   5.   Revised section on Privacy Extensions [RFC4941] to add more
+        nuance to recommendation.
+
+   6.   Completely revised IPsec/IKEv2 section, downgrading overall
+        recommendation to a SHOULD.
+
+   7.   Upgraded recommendation of DHCPv6 to SHOULD.
+
+   8.   Added background section on DHCP versus RA options, added SHOULD
+        recommendation for DNS configuration via RAs [RFC6106], and
+        cleaned up DHCP recommendations.
+
+   9.   Added recommendation that routers implement Sections 7.3 and 7.5
+        of [RFC6275].
+
+   10.  Added pointer to subnet clarification document [RFC5942].
+
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 22]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   11.  Added text that "IPv6 Host-to-Router Load Sharing" [RFC4311]
+        SHOULD be implemented.
+
+   12.  Added reference to [RFC5722] (Overlapping Fragments), and made
+        it a MUST to implement.
+
+   13.  Made "A Recommendation for IPv6 Address Text Representation"
+        [RFC5952] a SHOULD.
+
+   14.  Removed mention of "DNAME" from the discussion about [RFC3363].
+
+   15.  Numerous updates to reflect newer versions of IPv6 documents,
+        including [RFC4443], [RFC4291], [RFC3596], and [RFC4213].
+
+   16.  Removed discussion of "Managed" and "Other" flags in RAs.  There
+        is no consensus at present on how to process these flags, and
+        discussion of their semantics was removed in the most recent
+        update of Stateless Address Autoconfiguration [RFC4862].
+
+   17.  Added many more references to optional IPv6 documents.
+
+   18.  Made "A Recommendation for IPv6 Address Text Representation"
+        [RFC5952] a SHOULD.
+
+   19.  Added reference to [RFC5722] (Overlapping Fragments), and made
+        it a MUST to implement.
+
+   20.  Updated MLD section to include reference to Lightweight MLD
+        [RFC5790].
+
+   21.  Added SHOULD recommendation for "Default Router Preferences and
+        More-Specific Routes" [RFC4191].
+
+   22.  Made "IPv6 Flow Label Specification" [RFC6437] a SHOULD.
+
+17.  References
+
+17.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
+              for IP version 6", RFC 1981, August 1996.
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 23]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+              RFC 2671, August 1999.
+
+   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
+              Listener Discovery (MLD) for IPv6", RFC 2710,
+              October 1999.
+
+   [RFC2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
+              RFC 2711, October 1999.
+
+   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+              and M. Carney, "Dynamic Host Configuration Protocol for
+              IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3484]  Draves, R., "Default Address Selection for Internet
+              Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [RFC3590]  Haberman, B., "Source Address Selection for the Multicast
+              Listener Discovery (MLD) Protocol", RFC 3590,
+              September 2003.
+
+   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+              "DNS Extensions to Support IP Version 6", RFC 3596,
+              October 2003.
+
+   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
+              (DHCP) Service for IPv6", RFC 3736, April 2004.
+
+   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
+              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+
+
+Jankiewicz, et al.            Informational                    [Page 24]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+              for IPv6 Hosts and Routers", RFC 4213, October 2005.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+   [RFC4292]  Haberman, B., "IP Forwarding Table MIB", RFC 4292,
+              April 2006.
+
+   [RFC4293]  Routhier, S., "Management Information Base for the
+              Internet Protocol (IP)", RFC 4293, April 2006.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
+              RFC 4303, December 2005.
+
+   [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the
+              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
+              December 2005.
+
+   [RFC4311]  Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
+              Sharing", RFC 4311, November 2005.
+
+   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
+              Message Protocol (ICMPv6) for the Internet Protocol
+              Version 6 (IPv6) Specification", RFC 4443, March 2006.
+
+   [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, August 2006.
+
+   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
+              IP", RFC 4607, August 2006.
+
+   [RFC4835]  Manral, V., "Cryptographic Algorithm Implementation
+              Requirements for Encapsulating Security Payload (ESP) and
+              Authentication Header (AH)", RFC 4835, April 2007.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              September 2007.
+
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862, September 2007.
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 25]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
+              Extensions for Stateless Address Autoconfiguration in
+              IPv6", RFC 4941, September 2007.
+
+   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
+              of Type 0 Routing Headers in IPv6", RFC 5095,
+              December 2007.
+
+   [RFC5453]  Krishnan, S., "Reserved IPv6 Interface Identifiers",
+              RFC 5453, February 2009.
+
+   [RFC5722]  Krishnan, S., "Handling of Overlapping IPv6 Fragments",
+              RFC 5722, December 2009.
+
+   [RFC5790]  Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
+              Group Management Protocol Version 3 (IGMPv3) and Multicast
+              Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
+              February 2010.
+
+   [RFC5942]  Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
+              Model: The Relationship between Links and Subnet
+              Prefixes", RFC 5942, July 2010.
+
+   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
+              Address Text Representation", RFC 5952, August 2010.
+
+   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
+              "Internet Key Exchange Protocol Version 2 (IKEv2)",
+              RFC 5996, September 2010.
+
+   [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
+              "IPv6 Router Advertisement Options for DNS Configuration",
+              RFC 6106, November 2010.
+
+   [RFC6204]  Singh, H., Beebee, W., Donley, C., Stark, B., and O.
+              Troan, "Basic Requirements for IPv6 Customer Edge
+              Routers", RFC 6204, April 2011.
+
+   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
+              "IPv6 Flow Label Specification", RFC 6437, November 2011.
+
+17.2.  Informative References
+
+   [DODv6]    DISR IPv6 Standards Technical Working Group, "DoD IPv6
+              Standard Profiles For IPv6 Capable Products Version 5.0",
+              July 2010,
+              <http://jitc.fhu.disa.mil/apl/ipv6/pdf/disr_ipv6_50.pdf>.
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 26]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   [POSIX]    IEEE, "IEEE Std. 1003.1-2008 Standard for Information
+              Technology -- Portable Operating System Interface (POSIX),
+              ISO/IEC 9945:2009", <http://www.ieee.org>.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, September 1981.
+
+   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, September 1997.
+
+   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
+              Networks", RFC 2464, December 1998.
+
+   [RFC2491]  Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
+              over Non-Broadcast Multiple Access (NBMA) networks",
+              RFC 2491, January 1999.
+
+   [RFC2492]  Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM
+              Networks", RFC 2492, January 1999.
+
+   [RFC2590]  Conta, A., Malis, A., and M. Mueller, "Transmission of
+              IPv6 Packets over Frame Relay Networks Specification",
+              RFC 2590, May 1999.
+
+   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
+              RFC 2675, August 1999.
+
+   [RFC3146]  Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets
+              over IEEE 1394 Networks", RFC 3146, October 2001.
+
+   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+              Hain, "Representing Internet Protocol version 6 (IPv6)
+              Addresses in the Domain Name System (DNS)", RFC 3363,
+              August 2002.
+
+   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
+              Stevens, "Basic Socket Interface Extensions for IPv6",
+              RFC 3493, February 2003.
+
+   [RFC3542]  Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
+              "Advanced Sockets Application Program Interface (API) for
+              IPv6", RFC 3542, May 2003.
+
+   [RFC3678]  Thaler, D., Fenner, B., and B. Quinn, "Socket Interface
+              Extensions for Multicast Source Filters", RFC 3678,
+              January 2004.
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 27]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   [RFC3776]  Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
+              Protect Mobile IPv6 Signaling Between Mobile Nodes and
+              Home Agents", RFC 3776, June 2004.
+
+   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
+              Neighbor Discovery (SEND)", RFC 3971, March 2005.
+
+   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
+              RFC 3972, March 2005.
+
+   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
+              More-Specific Routes", RFC 4191, November 2005.
+
+   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
+              December 2005.
+
+   [RFC4338]  DeSanti, C., Carlson, C., and R. Nixon, "Transmission of
+              IPv6, IPv4, and Address Resolution Protocol (ARP) Packets
+              over Fibre Channel", RFC 4338, January 2006.
+
+   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+              Network Address Translations (NATs)", RFC 4380,
+              February 2006.
+
+   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
+              for IPv6", RFC 4429, April 2006.
+
+   [RFC4584]  Chakrabarti, S. and E. Nordmark, "Extension to Sockets API
+              for Mobile IPv6", RFC 4584, July 2006.
+
+   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+              Discovery", RFC 4821, March 2007.
+
+   [RFC4877]  Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
+              IKEv2 and the Revised IPsec Architecture", RFC 4877,
+              April 2007.
+
+   [RFC4884]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
+              "Extended ICMP to Support Multi-Part Messages", RFC 4884,
+              April 2007.
+
+   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
+              "Transmission of IPv6 Packets over IEEE 802.15.4
+              Networks", RFC 4944, September 2007.
+
+   [RFC5006]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
+              "IPv6 Router Advertisement Option for DNS Configuration",
+              RFC 5006, September 2007.
+
+
+
+Jankiewicz, et al.            Informational                    [Page 28]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+   [RFC5014]  Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
+              Socket API for Source Address Selection", RFC 5014,
+              September 2007.
+
+   [RFC5072]  S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
+              PPP", RFC 5072, September 2007.
+
+   [RFC5121]  Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
+              Madanapalli, "Transmission of IPv6 via the IPv6
+              Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
+              February 2008.
+
+   [RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
+              Routers", RFC 5555, June 2009.
+
+   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
+              in IPv6", RFC 6275, July 2011.
+
+   [USGv6]    National Institute of Standards and Technology, "A Profile
+              for IPv6 in the U.S. Government - Version 1.0", July 2008,
+              <http://www.antd.nist.gov/usgv6/usgv6-v1.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 29]
+
+RFC 6434                 IPv6 Node Requirements            December 2011
+
+
+Authors' Addresses
+
+   Ed Jankiewicz
+   SRI International, Inc.
+   333 Ravenswood Ave.
+   Menlo Park, CA  94025
+   USA
+
+   Phone: +1 443 502 5815
+   EMail: edward.jankiewicz@sri.com
+
+
+   John Loughney
+   Nokia
+   200 South Mathilda Ave.
+   Sunnyvale, CA  94086
+   USA
+
+   Phone: +1 650 283 8068
+   EMail: john.loughney@nokia.com
+
+
+   Thomas Narten
+   IBM Corporation
+   3039 Cornwallis Ave.
+   PO Box 12195
+   Research Triangle Park, NC  27709-2195
+   USA
+
+   Phone: +1 919 254 7798
+   EMail: narten@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jankiewicz, et al.            Informational                    [Page 30]
+