--- 1/draft-ietf-6man-node-req-bis-05.txt 2010-10-26 03:16:25.000000000 +0200 +++ 2/draft-ietf-6man-node-req-bis-06.txt 2010-10-26 03:16:25.000000000 +0200 @@ -1,21 +1,21 @@ Internet Engineering Task Force E. Jankiewicz Internet-Draft SRI International Intended status: Informational J. Loughney -Expires: January 13, 2011 Nokia +Expires: April 29, 2011 Nokia T. Narten IBM Corporation - July 12, 2010 + October 26, 2010 IPv6 Node Requirements RFC 4294-bis - draft-ietf-6man-node-req-bis-05.txt + draft-ietf-6man-node-req-bis-06.txt 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. Status of this Memo @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 13, 2011. + This Internet-Draft will expire on April 29, 2011. Copyright Notice Copyright (c) 2010 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 @@ -59,110 +59,125 @@ 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Scope of This Document . . . . . . . . . . . . . . . . . . 4 - 2.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 4 + 2.1. Scope of This Document . . . . . . . . . . . . . . . . . . 5 + 2.2. Description of IPv6 Nodes . . . . . . . . . . . . . . . . 5 3. Abbreviations Used in This Document . . . . . . . . . . . . . 5 - 4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Sub-IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IP Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5.1. Internet Protocol Version 6 - RFC 2460 . . . . . . . . . . 6 + 5.1. Internet Protocol Version 6 - RFC 2460 . . . . . . . . . . 7 5.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . . 7 5.3. SEcure Neighbor Discovery (SEND) - RFC 3971 . . . . . . . 8 - 5.4. IPv6 Router Advertisement Flags Option - RFC 5175 . . . . 8 - 5.5. Path MTU Discovery and Packet Size . . . . . . . . . . . . 8 - 5.5.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 8 + 5.4. IPv6 Router Advertisement Flags Option - RFC 5175 . . . . 9 + 5.5. Path MTU Discovery and Packet Size . . . . . . . . . . . . 9 + 5.5.1. Path MTU Discovery - RFC 1981 . . . . . . . . . . . . 9 5.6. IPv6 Jumbograms - RFC 2675 . . . . . . . . . . . . . . . . 9 5.7. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.8. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 9 5.8.1. IP Version 6 Addressing Architecture - RFC 4291 . . . 9 5.8.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 . 9 5.8.3. Privacy Extensions for Address Configuration in - IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . 9 + IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . 10 5.8.4. Default Address Selection for IPv6 - RFC 3484 . . . . 10 - 5.8.5. Stateful Address Autoconfiguration . . . . . . . . . . 10 - 5.9. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 . . 10 + 5.8.5. Stateful Address Autoconfiguration . . . . . . . . . . 11 + 5.9. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 . . 11 6. DHCP vs. Router Advertisement Options for Host Configuration . . . . . . . . . . . . . . . . . . . . . . . . 11 7. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - - RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 12 - 7.2.1. Managed Address Configuration . . . . . . . . . . . . 12 - 7.2.2. Other Configuration Information . . . . . . . . . . . 12 - 7.2.3. Use of Router Advertisements in Managed + - RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.2.1. Other Configuration Information . . . . . . . . . . . 13 + 7.2.2. Use of Router Advertisements in Managed Environments . . . . . . . . . . . . . . . . . . . . . 13 7.3. IPv6 Router Advertisement Options for DNS Configuration - RFC XXXX . . . . . . . . . . . . . . . . . 13 8. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 13 - 8.1. Transition Mechanisms . . . . . . . . . . . . . . . . . . 13 + 8.1. Transition Mechanisms . . . . . . . . . . . . . . . . . . 14 8.1.1. Basic Transition Mechanisms for IPv6 Hosts and - Routers - RFC 4213 . . . . . . . . . . . . . . . . . . 13 - 9. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + Routers - RFC 4213 . . . . . . . . . . . . . . . . . . 14 + 9. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 10.1. Basic Architecture . . . . . . . . . . . . . . . . . . . . 14 - 10.2. Security Protocols . . . . . . . . . . . . . . . . . . . . 14 - 10.3. Transforms and Algorithms . . . . . . . . . . . . . . . . 14 - 10.4. Key Management Methods . . . . . . . . . . . . . . . . . . 15 - 11. Router-Specific Functionality . . . . . . . . . . . . . . . . 15 - 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 11.1.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . 15 - 11.1.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . 15 - 12. Network Management . . . . . . . . . . . . . . . . . . . . . . 15 + 10.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 15 + 10.2. Transforms and Algorithms . . . . . . . . . . . . . . . . 15 + 11. Router-Specific Functionality . . . . . . . . . . . . . . . . 16 + 11.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 11.1.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . 16 + 11.1.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . 16 + 12. Network Management . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Management Information Base Modules (MIBs) . . . . . . . . 16 12.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . . 16 12.1.2. Management Information Base for the Internet Protocol (IP) . . . . . . . . . . . . . . . . . . . . 16 - 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 14. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 15. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 16 - 15.1. Authors and Acknowledgments (Current Document) . . . . . . 16 - 15.2. Authors and Acknowledgments From RFC 4279 . . . . . . . . 16 - 16. Appendix: Changes from -04 to -05 . . . . . . . . . . . . . . 17 - 17. Appendix: Changes from -03 to -04 . . . . . . . . . . . . . . 18 - 18. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 18 - 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 19.1. Normative References . . . . . . . . . . . . . . . . . . . 18 - 19.2. Informative References . . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 + 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 15. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 17 + 15.1. Authors and Acknowledgments (Current Document) . . . . . . 17 + 15.2. Authors and Acknowledgments From RFC 4279 . . . . . . . . 17 + 16. Appendix: Changes from -05 to -06 . . . . . . . . . . . . . . 18 + 17. Appendix: Changes from -04 to -05 . . . . . . . . . . . . . . 18 + 18. Appendix: Changes from -03 to -04 . . . . . . . . . . . . . . 19 + 19. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 19 + 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 20.1. Normative References . . . . . . . . . . . . . . . . . . . 19 + 20.2. Informative References . . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 1. 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]. 2. Introduction The goal of this document is to define the 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 provide guidance as to which IPv6 - specifications should be implemented in the general case. This - document does not update any individual protocol document RFCs. + specifications should be implemented in the general case, and which + specification may be of interest to specific deployment scenarios. + This document does not update any individual protocol document RFCs. Although the document points to different specifications, it should - be noted that in most cases, the granularity of requirements are - smaller than a single specification, as many specifications define - multiple, independent pieces, some of which may not be mandatory. + 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 some deployment + scenarios may deem it appropriate to make such a requirement. As one + specific example, the USGv6 [USGv6] profile includes speciallized + requirements for its target environment. 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]. 2.1. Scope of This Document @@ -208,24 +223,25 @@ ND Neighbor Discovery NS Neighbor Solicitation NUD Neighbor Unreachability Detection PPP Point-to-Point Protocol PVC Permanent Virtual Circuit SVC Switched Virtual Circuit 4. Sub-IP Layer An IPv6 node must include support for one or more IPv6 link-layer - specifications. Which link-layer specifications are included 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. + 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 link-layers for which an IPv6 specification has been developed. It is provided for information 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] @@ -288,49 +303,48 @@ 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 is an area for further study. Some detailed analysis of Neighbor Discovery follows: Router Discovery is how hosts locate routers that reside on an - attached link. Router Discovery MUST be supported for - implementations. + 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. - Prefix discovery MUST be supported for implementations. Neighbor - Unreachability Detection (NUD) MUST be supported for all paths - between hosts and neighboring nodes. It is not required for paths - between routers. However, when a node receives a unicast Neighbor - Solicitation (NS) message (that may be a NUD's NS), the node MUST - respond to it (i.e., send a unicast Neighbor Advertisement). - - Duplicate Address Detection MUST be supported on all links supporting - link-layer multicast (RFC 4862, Section 5.4, specifies DAD MUST take - place on all unicast addresses). + Hosts MUST support Prefix discovery. - A host implementation MUST support sending Router Solicitations. + 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. - Receiving and processing Router Advertisements MUST be supported for - host implementations. The ability to understand specific Router - Advertisement options is dependent on supporting the specification - where the RA is specified. + Hosts MUST support the sending of Router Solicitations and the + recieving of Router Advertisements. The ability to understand + individual Router Advertisement options is dependent on supporting + the functionality making use of the particular option. - Sending and Receiving Neighbor Solicitation (NS) and Neighbor - Advertisement (NA) MUST be supported. NS and NA messages are - required for Duplicate Address Detection (DAD). + 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). - Redirect functionality SHOULD be supported. If the node is a router, - Redirect functionality MUST be supported. + 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 + 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. 5.3. 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 @@ -380,40 +394,45 @@ ICMPv6 [RFC4443] MUST be supported. 5.8. Addressing 5.8.1. IP Version 6 Addressing Architecture - RFC 4291 The IPv6 Addressing Architecture [RFC4291] MUST be supported. 5.8.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 - IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. - This specification MUST be supported for nodes that are hosts. - Static address can be supported as well. + Hosts MUST support IPv6 Stateless Address Autoconfiguration as + defined in [RFC4862]. Static address may be supported as well. Nodes that are routers MUST be able to generate link local addresses as described in RFC 4862 [RFC4862]. From 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. - Duplicate Address Detection (DAD) MUST be supported. + 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: 5.8.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, @@ -424,39 +443,39 @@ pattern of activity if it remains in one place. This may raise privacy concerns as described in [RFC4862]. In such situations, RFC4941 SHOULD be implemented. In other cases, such as with dedicated servers in a data center, RFC4941 provides limited or no benefit. 5.8.4. Default Address Selection for IPv6 - RFC 3484 The rules specified in the Default Address Selection for IPv6 - [RFC3484] document MUST be implemented. It is expected that IPv6 - nodes will need to deal with multiple addresses. + [RFC3484] document MUST be implemented. IPv6 nodes will need to deal + with multiple addresses configured simultaneously, . 5.8.5. Stateful Address Autoconfiguration - Stateful Address Autoconfiguration MAY be supported. DHCPv6 - [RFC3315] is the standard stateful address configuration protocol; - see Section 6.2 for DHCPv6 support. + DHCP can be used to obtain and configure addresses. In general, a + network may provide for the configuration of addresses through Router + Advertisements, DHCP or both. At the present time, the configuration + of stateless address autoconfiguraiton is more widely implemented in + hosts than address configuration through DHCP. However, some + environments may require the use of DHCP and may not support the + configuration of addresses via RAs. Implementations should be aware + of what operating environment their devices will be deployed. Hosts + MAY implement address configuration via DHCP. - Nodes which do not support Stateful Address Autoconfiguration may be - unable to obtain any IPv6 addresses, aside from link-local addresses, - when it receives a router advertisement with the 'M' flag (Managed - address configuration) set and that contains no prefixes advertised - for Stateless Address Autoconfiguration (see Section 4.5.2). - Additionally, such nodes will be unable to obtain other configuration - information, such as the addresses of DNS servers when it is - connected to a link over which the node receives a router - advertisement in which the 'O' flag (Other stateful configuration) is - set. + 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]. 5.9. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 Nodes that need to join multicast groups MUST support MLDv1 [RFC3590]. 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. Nodes that need to join multicast groups SHOULD implement MLDv2 @@ -476,22 +495,22 @@ 6. DHCP vs. Router Advertisement Options for Host Configuration In IPv6, there are two main protocol mechanisms for propagating configuration information to hosts: Router Advertisements and DHCP. Historically, RA options have been restricted to those deemed essential for basic network functioning and for which all nodes are configured with exactly the same information. Examples include the Prefix Information Options, the MTU option, etc. On the other hand, DHCP has generally been preferred for configuration of more general parameters and for parameters that may be client-specific. That - said, identifying the exact line on when whether a particular option - should be configured via DHCP vs an RA option has not always been + said, identifying the exact line on whether a particular option + should be configured via DHCP vs. 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 configurating the same information. One issue with having multiple ways of configuring the same information is that if a host choses one mechanism, but the network operator chooses a different mechanism, interoperability suffers. For "closed" environments, where the network operator has significant influence over what devices connect to the network and thus what @@ -529,49 +548,33 @@ octets. Those nodes are RECOMMENDED to support DNS security extensions [RFC4033], [RFC4034], and [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. Managed Address Configuration - - DHCP can be used to obtain and configure addresses. In general, a - network may provide for the configuration of addresses through RAs, - DHCP or both. At the present time, the configuration of stateless - address autoconfiguraiton is more widely implemented in hosts than - address configuration through DHCP. However, some environments may - require the use of DHCP and may not support the configuration of - addresses via RAs. Implementations should be aware of what operating - environment their devices will be deployed. Hosts MAY implement - address configuration via DHCP. - - 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]. - -7.2.2. Other Configuration Information +7.2.1. Other Configuration Information - IPv6 nodes use DHCP to obtain additional (non-address) configuration. - If a host implementation will support applications or other protocols + IPv6 nodes use DHCP to obtain address configuration information (See + Section 5.8.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 is not necessary. + 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.3. Use of Router Advertisements in Managed Environments +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 XXXX 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 @@ -616,79 +619,96 @@ 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 one can be recommended for broad implementation in all hosts and routers. Consequently, [RFC3775], [RFC5555], and associated standards such as [RFC4877] are considered a MAY at this time. 10. Security - This section describes the specification of IPsec for the IPv6 node. - - Note: This section needs a rethink. According to RFC4301, IKEv2 MUST - be supported. This section cites RFC 4301 as a MUST, yet the - remainder of this section only makes IKEv2 a SHOULD. The IPv6 WG has - discussed the topic of mandating key management in the past, but has - not been willing to make IKE (v1 or v2) a MUST. Is it time to - revisit this recommendation? Does it make sense to leave key - management as a SHOULD? And what about how that contradicts RFC - 4301? - -10.1. Basic Architecture + This section describes the specification for security for IPv6 nodes. - Security Architecture for the Internet Protocol [RFC4301] MUST be - supported. + 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. -10.2. Security Protocols + 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. - ESP [RFC4303] MUST be supported. AH [RFC4302] MAY be supported. + Although IPsec can be used with manual keying in some cases, such + usage has limited applicability and is not recommended. -10.3. Transforms and Algorithms + A range of security technologies and approaches proliferate today + (e.g., IPsec, TLS, 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. - The current set of mandatory-to-implement algorithms for ESP and AH - are defined in 'Cryptographic Algorithm Implementation Requirements - For ESP and AH' [RFC4835]. IPv6 nodes SHOULD conform to the - requirements in [RFC4835]. + Previously, IPv6 mandated implementation of IPsec and recommended the + key management approach of IKE. This document updates that + recommendation by making support of the IP Security Architecture [RFC + 4301] a SHOULD for all IPv6 nodes. Note that the IPsec Architecture + requires (e.g., Sec. 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. -10.4. Key Management Methods + This document recognizes that there exists a range of device types + and environments where other approaches to security 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 my run on + extremely constrained hardware (e.g., sensors) where the full IP + Security Architecture is not justified. - An implementation MUST support the manual configuration of the - security key and SPI. The SPI configuration is needed in order to - delineate between multiple keys. +10.1. Requirements - Key management SHOULD be supported. Examples of key management - systems include IKEv2 [RFC4306] and Kerberos; S/MIME and TLS include - key management functions. + "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be + supported by all IPv6 nodes. Note that the IPsec Architecture + requires (e.g., Sec. 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. - Where key refresh, anti-replay features of AH and ESP, or on-demand - creation of Security Associations (SAs) is required, automated keying - MUST be supported. +10.2. Transforms and Algorithms - Key management methods for multicast traffic are also being worked on - by the MSEC WG. + The current set of mandatory-to-implement algorithms for the IP + Security Architcture are defined in 'Cryptographic Algorithm + Implementation Requirements For ESP and AH' [RFC4835]. IPv6 nodes + implementing the IP Security Architecture MUST conform to the + requirements in [RFC4835]. Preferred cryptographic algorithms often + change more frequently than security protocols. Therefore + implementations MUST allow for migration in new algorithms, as + RFC4835 is replaced or updated in the future. 11. 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. 11.1. General 11.1.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 MLD [RFC2710]). The Router Alert option will need to be implemented whenever protocols that mandate its usage are - implemented. See Section 4.6. + implemented. See Section 5.8.5. 11.1.2. Neighbor Discovery for IPv6 - RFC 4861 Sending Router Advertisements and processing Router Solicitation MUST be supported. 12. Network Management Network Management MAY be supported by IPv6 nodes. However, for IPv6 nodes that are embedded devices, network management may be the only @@ -704,32 +724,29 @@ IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes that support an SNMP agent. 12.1.2. Management Information Base for the Internet Protocol (IP) IP MIB [RFC4293] SHOULD be supported by nodes that support an SNMP agent. 13. Open Issues - 1. The recommendations regarding when to invoke DHCP are - problematical with out being able to reference the M&0 bits. - 2. Security Recommendations needs updating. See note in that - Section. + 1. None? 14. Security Considerations This document does not directly affect the security of the Internet, - but implementations of IPv6 are expected to support a minimum set of - security features to ensure security on the Internet. + beyond the security considerations associated with the individual + protocols. - Security is also discussed in Section XXX above. + Security is also discussed in Section 10 above. 15. Authors and Acknowledgments 15.1. Authors and Acknowledgments (Current Document) 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: @@ -759,52 +776,70 @@ 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 -04 to -05 +16. Appendix: Changes from -05 to -06 + + 1. Completely revised IPsec/IKEv2 section. Text has been discussed + by 6man and saag. + + 2. Added text to introduction clarifying that this document applies + to general nodes and that other profiles may be more specific in + their requirements + + 3. Editorial cleanups in Neighbor Discovery section in particular. + Text made more crisp. + + 4. Moved some of the DHCP text around. Moved stateful address + discussion to Section 5.8.5. + + 5. Added additional nuance to the redirect requirements w.r.t. + default configuration setting. + +17. Appendix: Changes from -04 to -05 1. Cleaned up IPsec section, but key questions (MUST vs. SHOULD) still open. 2. Added background section on DHCP vs. RA options. - 3. Added SHOULD recomendation for DNS configuration vi RAs + 3. Added SHOULD recommendation for DNS configuration vi RAs (RFC5006bis). 4. Cleaned up DHCP section, as it was referring to the M&O bits. 5. Cleaned up the Security Considerations Section. -17. Appendix: Changes from -03 to -04 +18. Appendix: Changes from -03 to -04 1. Updated the Introduction to indicate document is an applicabity statement 2. Updated the section on Mobility protocols 3. Changed Sub-IP Layer Section to just list relevant RFCs, and added some more RFCs. 4. Added Section on SEND (make it a MAY) 5. Redid Section on Privacy Extensions (RFC4941) to add more nuance to recommendation 6. Redid section on Mobility, and added additional RFCs [ -18. Appendix: Changes from RFC 4294 +19. Appendix: Changes from RFC 4294 This appendix keeps track of the chances from RFC 4294 1. Section 5.1, removed "and DNAME" from the discussion about RFC- 3363. 2. RFC 2463 references updated to RFC 4443. 3. RFC 3513 references updated to RFC 4291. @@ -813,23 +848,23 @@ 5. RFC 2893 references updated to RFC 4213. 6. AH [RFC4302] support chanced from MUST to MAY. 7. The reference for RFC 3152 has been deleted, as the RFC has been obsoleted, and has been incorporated into RFC 3596. 8. The reference for RFC 3879 has been removed as the material from RFC 3879 has been incorporated into RFC 4291. -19. References +20. References -19.1. Normative References +20.1. Normative References [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -884,23 +919,20 @@ [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. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. - [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", - RFC 4303, December 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. [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. @@ -920,21 +952,21 @@ "IPv6 Router Advertisement Option for DNS Configuration", RFC 5006, September 2007. [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007. [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007. -19.2. Informative References +20.2. Informative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. @@ -978,23 +1011,20 @@ 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. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. - [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", - RFC 4306, 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. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877,