--- 1/draft-ietf-6man-rfc6434-bis-03.txt 2018-02-22 15:13:15.858558878 -0800 +++ 2/draft-ietf-6man-rfc6434-bis-04.txt 2018-02-22 15:13:15.934560700 -0800 @@ -1,21 +1,21 @@ Internet Engineering Task Force T. Chown Internet-Draft Jisc Obsoletes: 6434 (if approved) J. Loughney Intended status: Best Current Practice Intel -Expires: August 10, 2018 T. Winters +Expires: August 26, 2018 T. Winters UNH-IOL - February 6, 2018 + February 22, 2018 IPv6 Node Requirements - draft-ietf-6man-rfc6434-bis-03 + draft-ietf-6man-rfc6434-bis-04 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 6434, and in turn RFC 4294. @@ -28,21 +28,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 https://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 August 10, 2018. + This Internet-Draft will expire on August 26, 2018. Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -87,53 +87,53 @@ 6.6. Default Address Selection for IPv6 - RFC 6724 . . . . . . 15 7. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Configuring Non-Address Information . . . . . . . . . . . . . 16 8.1. DHCP for Other Configuration Information . . . . . . . . 16 8.2. Router Advertisements and Default Gateway . . . . . . . . 16 8.3. IPv6 Router Advertisement Options for DNS Configuration - RFC 8106 . . . . . . . . . . . . . . . . 16 8.4. DHCP Options versus Router Advertisement Options for Host Configuration . . . . . . . . . . . . . . . . . . . . . . 17 9. Service Discovery Protocols . . . . . . . . . . . . . . . . . 17 - 10. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 17 + 10. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 18 10.1. Transition Mechanisms . . . . . . . . . . . . . . . . . 18 10.1.1. Basic Transition Mechanisms for IPv6 Hosts and Routers - RFC 4213 . . . . . . . . . . . . . . . . . 18 11. Application Support . . . . . . . . . . . . . . . . . . . . . 18 11.1. Textual Representation of IPv6 Addresses - RFC 5952 . . 18 11.2. Application Programming Interfaces (APIs) . . . . . . . 18 12. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 13.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 20 + 13.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 21 13.2. Transforms and Algorithms . . . . . . . . . . . . . . . 21 14. Router-Specific Functionality . . . . . . . . . . . . . . . . 21 14.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . . 21 - 14.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 21 + 14.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 22 14.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 22 14.4. IPv6 Prefix Length Recommendation for Forwarding - BCP 198 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 15. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 22 16. Network Management . . . . . . . . . . . . . . . . . . . . . 23 16.1. Management Information Base (MIB) Modules . . . . . . . 23 16.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . 23 16.1.2. Management Information Base for the Internet Protocol (IP) . . . . . . . . . . . . . . . . . . . 23 - 16.2. YANG Data Models . . . . . . . . . . . . . . . . . . . . 23 - 16.2.1. IP Management YANG Model . . . . . . . . . . . . . . 23 - 16.2.2. System Management YANG Model . . . . . . . . . . . . 24 - 16.2.3. System Management YANG Model . . . . . . . . . . . . 24 + 16.1.3. Interface MIB . . . . . . . . . . . . . . . . . . . 24 + 16.2. YANG Data Models . . . . . . . . . . . . . . . . . . . . 24 + 16.2.1. IP Management YANG Model . . . . . . . . . . . . . . 24 + 16.2.2. Interface Management YANG Model . . . . . . . . . . 24 17. Security Considerations . . . . . . . . . . . . . . . . . . . 24 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 19. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 24 19.1. Authors and Acknowledgments (Current Document) . . . . . 24 19.2. Authors and Acknowledgments from RFC 6434 . . . . . . . 24 - 19.3. Authors and Acknowledgments from RFC 4294 . . . . . . . 24 + 19.3. Authors and Acknowledgments from RFC 4294 . . . . . . . 25 20. Appendix: Changes from RFC 6434 . . . . . . . . . . . . . . . 26 21. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 27 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 22.1. Normative References . . . . . . . . . . . . . . . . . . 29 22.2. Informative References . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 1. Introduction This document defines common functionality required by both IPv6 @@ -336,24 +336,23 @@ headers, destination options, and hop-by-hop options in a packet. Given that the only limit on the number and size of extension headers is the MTU, the processing of received packets could be considerable. It is also conceivable that a long chain of extension headers might be used as a form of denial-of-service attack. Accordingly, a host may place limits on the number and sizes of extension headers and options it is willing to process. A host MAY limit the number of consecutive PAD1 options in destination options or hop-by-hop options to seven. In this case, if - the more than seven consecutive PAD1 options are present the the - packet should be silently discarded. The rationale is that if - padding of eight or more bytes is required than the PADN option - should be used. + the more than seven consecutive PAD1 options are present the packet + should be silently discarded. The rationale is that if padding of + eight or more bytes is required than the PADN option should be used. A host MAY limit number of bytes in a PADN option to be less than eight. In such a case, if a PADN option is present that has a length greater than seven then the packet should be silently discarded. The rationale for this guideline is that the purpose of padding is for alignment and eight bytes is the maximum alignment used in IPv6. A host MAY disallow unknown options in destination options or hop-by- hop options. This should be configurable where the default is to accept unknown options and process them per [RFC8200]. If a packet @@ -562,28 +561,31 @@ 6. Addressing and Address Configuration 6.1. IP Version 6 Addressing Architecture - RFC 4291 The IPv6 Addressing Architecture [RFC4291] MUST be supported. The current IPv6 Address Architecture is based on a 64-bit boundary for subnet prefixes. The reasoning behind this decision is documented in [RFC7421]. + Implementations MUST also support the Multicast flag updates + documented in [RFC7371] + 6.2. Host Address Availability Recommendations Hosts may be configured with addresses through a variety of methods, including SLAAC, DHCPv6, or manual configuration. [RFC7934] recommends that networks provide general-purpose end hosts with multiple global IPv6 addresses when they attach, and it - describes the benefits of and the options for doing so. Router + describes the benefits of and the options for doing so. Routers SHOULD support [RFC7934] for assigning multiple address to a host. Host SHOULD support assigning multiple addresses as described in [RFC7934]. Nodes SHOULD support the capability to be assigned a prefix per host as documented in [RFC8273]. Such an approach can offer improved host isolation and enhanced subscriber management on shared network segments. 6.3. IPv6 Stateless Address Autoconfiguration - RFC 4862 @@ -727,21 +729,22 @@ (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. If an IPv6 node implements DHCP it MUST implement the DNS options - [RFC3646] as most deployments will expect this options are available. + [RFC3646] as most deployments will expect this options are + available. 8.2. Router Advertisements and Default Gateway There is no defined DHCPv6 Gateway option. Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) are thus expected to determine their default router information and on-link prefix information from received Router Advertisements. 8.3. IPv6 Router Advertisement Options for DNS Configuration - RFC 8106 @@ -1048,57 +1051,58 @@ If an IPv6 node is concerned about the impact of IPv6 message power consumption, it SHOULD want to implement the recommendations in [RFC7772]. 16. 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. - A node supporting network management SHOULD support NETCONF [RFC6241] - and SNMP configuration [RFC3411]. + Existing network management protocols include SNMP [RFC3411], NETCONF + [RFC6241] and RESTCONF [RFC8040]. 16.1. Management Information Base (MIB) Modules IPv6 MIBs have been updated since the last release of the document; - [RFC8096] obseletes several MIBs, which nodes need no longer support. + [RFC8096] obseletes several MIBs, which nodes need no longer + support. The following two MIB modules SHOULD be supported by nodes that support a Simple Network Management Protocol (SNMP) agent. 16.1.1. IP Forwarding Table MIB The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes that support an SNMP agent. 16.1.2. Management Information Base for the Internet Protocol (IP) The IP MIB [RFC4293] SHOULD be supported by nodes that support an SNMP agent. +16.1.3. Interface MIB + + The Interface MIB [RFC2863] SHOULD be supported by nodes the support + an SNMP agent. + 16.2. YANG Data Models The following YANG data models SHOULD be supported by nodes that support a NETCONF agent. 16.2.1. IP Management YANG Model The IP Management YANG Model [RFC7277] SHOULD be supported by nodes that support NETCONF. -16.2.2. System Management YANG Model - - The System Management YANG Model [RFC7317] SHOULD be supported by - nodes that support NETCONF. - -16.2.3. System Management YANG Model +16.2.2. Interface Management YANG Model The Interface Management YANG Model [RFC7223] SHOULD be supported by nodes that support NETCONF. 17. Security Considerations This document does not directly affect the security of the Internet, beyond the security considerations associated with the individual protocols. @@ -1190,69 +1194,72 @@ 3. Removed DOD IPv6 Profile as it hasn't been updated. 4. Updated to MLDv2 support to a MUST since nodes are restricted if MLDv1 is used. 5. Require DNS RA Options so SLAAC-only devices can get DNS, RFC8106 is a MUST. 6. Require RFC3646 DNS Options for DHCPv6 implementations. - 7. Added section on constrained devices. + 7. Added RESTCONF and NETCONF as possible options to Network + management. - 8. Added text on RFC7934, address availability to hosts (SHOULD). + 8. Added section on constrained devices. - 9. Added text on RFC7844, anonymity profiles for DHCPv6 clients. + 9. Added text on RFC7934, address availability to hosts (SHOULD). - 10. mDNS and DNS-SD added as updated service discovery. + 10. Added text on RFC7844, anonymity profiles for DHCPv6 clients. - 11. Added RFC8028 as a SHOULD as a method for solving multi-prefix + 11. mDNS and DNS-SD added as updated service discovery. + + 12. Added RFC8028 as a SHOULD as a method for solving multi-prefix network - 12. Added ECN RFC3168 as a SHOULD, since recent reports have shown + 13. Added ECN RFC3168 as a SHOULD, since recent reports have shown this as useful, and added a note on RFC8311, which is related. - 13. Added reference to RFC7123 for Security over IPv4-only networks + 14. Added reference to RFC7123 for Security over IPv4-only networks - 14. Removed Jumbograms RFC2675 as they aren't deployed. + 15. Removed Jumbograms RFC2675 as they aren't deployed. - 15. Updated Obseleted RFCs to the new version of the RFC including + 16. Updated Obseleted RFCs to the new version of the RFC including 2460, 1981, 7321, 4307 - 16. Added RFC7772 for power comsumptions considerations + 17. Added RFC7772 for power comsumptions considerations - 17. Added why /64 boundries for more detail - RFC 7421 + 18. Added why /64 boundries for more detail - RFC 7421 - 18. Added a Unique IPv6 Prefix per Host to support currently + 19. Added a Unique IPv6 Prefix per Host to support currently deployed IPv6 networks - 19. Clarified RFC7066 was snapshot for 3GPP + 20. Clarified RFC7066 was snapshot for 3GPP - 20. Updated 4191 as a MUST, SHOULD for Type C Host as it helps solve + 21. Updated 4191 as a MUST, SHOULD for Type C Host as it helps solve multi-prefix problem - 21. Removed IPv6 over ATM since there aren't many deployments + 22. Removed IPv6 over ATM since there aren't many deployments - 22. Added a note in Section 6.6 for RFC6724 Section 5.5/ + 23. Added a note in Section 6.6 for RFC6724 Section 5.5/ - 23. Added MUST for BCP 198 for forwarding IPv6 packets + 24. Added MUST for BCP 198 for forwarding IPv6 packets - 24. Added reference to draft-ietf-v6ops-ipv6rtr-reqs as it has more + 25. Added reference to draft-ietf-v6ops-ipv6rtr-reqs as it has more recommendations for a Router - 25. Added reference to RFC8064 for stable address creation. + 26. Added reference to RFC8064 for stable address creation. - 26. Added text on protection from excessive EH options + 27. Added text on protection from excessive EH options - 27. Added text on dangers of 1280 MTU UDP, esp. wrt DNS traffic + 28. Added text on dangers of 1280 MTU UDP, esp. wrt DNS traffic - 28. Added text to clarify RFC8200 behaviour for unrecognized EHs or + 29. Added text to clarify RFC8200 behaviour for unrecognized EHs or unrecognized ULPs 21. 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 @@ -1337,20 +1344,24 @@ [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, . [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, DOI 10.17487/RFC2711, October 1999, . + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group + MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, + . + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . @@ -1547,24 +1558,20 @@ [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 7277, DOI 10.17487/RFC7277, June 2014, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . - [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for - System Management", RFC 7317, DOI 10.17487/RFC7317, August - 2014, . - [RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., and W. George, "Enhanced Duplicate Address Detection", RFC 7527, DOI 10.17487/RFC7527, April 2015, . [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss Resiliency for Router Solicitations", RFC 7559, DOI 10.17487/RFC7559, May 2015, . @@ -1580,20 +1587,24 @@ [RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6 Atomic Fragments Considered Harmful", RFC 8021, DOI 10.17487/RFC8021, January 2017, . [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, . + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . + [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, . [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, . @@ -1795,20 +1806,25 @@ [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on IPv4 Networks", RFC 7123, DOI 10.17487/RFC7123, February 2014, . [RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link", RFC 7278, DOI 10.17487/RFC7278, June 2014, . + [RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6 + Multicast Addressing Architecture", RFC 7371, + DOI 10.17487/RFC7371, September 2014, + . + [RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S., Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit Boundary in IPv6 Addressing", RFC 7421, DOI 10.17487/RFC7421, January 2015, . [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, .