--- 1/draft-ietf-6man-node-req-bis-01.txt 2008-11-03 11:12:03.000000000 +0100 +++ 2/draft-ietf-6man-node-req-bis-02.txt 2008-11-03 11:12:03.000000000 +0100 @@ -1,18 +1,18 @@ Internet Engineering Task Force J. Loughney Internet-Draft Nokia -Intended status: Standards Track February 24, 2008 -Expires: August 27, 2008 +Intended status: Informational November 3, 2008 +Expires: May 7, 2009 IPv6 Node Requirements RFC 4294-bis - draft-ietf-6man-node-req-bis-01.txt + draft-ietf-6man-node-req-bis-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -23,25 +23,21 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 27, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2008). + This Internet-Draft will expire on May 7, 2009. 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. Table of Contents @@ -70,50 +66,50 @@ 5.6.3. Privacy Extensions for Address Configuration in IPv6 - RFC 4941 . . . . . . . . . . . . . . . . . . . 9 5.6.4. Default Address Selection for IPv6 - RFC 3484 . . . . 9 5.6.5. Stateful Address Autoconfiguration . . . . . . . . . . 9 5.7. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 . . 9 6. DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315 . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2.1. 5.2.1. Managed Address Configuration . . . . . . . . 10 - 6.2.2. Other Configuration Information . . . . . . . . . . . 10 + 6.2.2. Other Configuration Information . . . . . . . . . . . 11 6.2.3. Use of Router Advertisements in Managed Environments . . . . . . . . . . . . . . . . . . . . . 11 7. IPv4 Support and Transition . . . . . . . . . . . . . . . . . 11 7.1. Transition Mechanisms . . . . . . . . . . . . . . . . . . 11 7.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893 . . . . . . . . . . . . . . . . . . . . . . . 11 8. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Basic Architecture . . . . . . . . . . . . . . . . . . . . 12 9.2. Security Protocols . . . . . . . . . . . . . . . . . . . . 12 9.3. Transforms and Algorithms . . . . . . . . . . . . . . . . 12 9.4. Key Management Methods . . . . . . . . . . . . . . . . . . 13 10. Router-Specific Functionality . . . . . . . . . . . . . . . . 13 10.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 10.1.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . 13 - 10.1.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . 13 - 11. Network Management . . . . . . . . . . . . . . . . . . . . . . 13 + 10.1.1. IPv6 Router Alert Option - RFC 2711 . . . . . . . . . 14 + 10.1.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . 14 + 11. Network Management . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Management Information Base Modules (MIBs) . . . . . . . . 14 11.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . . 14 11.1.2. Management Information Base for the Internet Protocol (IP) . . . . . . . . . . . . . . . . . . . . 14 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 13. Authors and Acknowledgements . . . . . . . . . . . . . . . . . 14 + 13. Authors and Acknowledgements . . . . . . . . . . . . . . . . . 15 14. Appendix: Changes from RFC 4294 . . . . . . . . . . . . . . . 15 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 15.1. Normative References . . . . . . . . . . . . . . . . . . . 16 - 15.2. Informative References . . . . . . . . . . . . . . . . . . 18 + 15.2. Informative References . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 - Intellectual Property and Copyright Statements . . . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . . . . 21 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 @@ -368,28 +364,37 @@ 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. 5.7. 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 [RFC3810]. However, if the node has applications that only need support for Any-Source Multicast [RFC3569], the node MAY implement MLDv1 [RFC2710] instead. If the node has applications that need support for Source-Specific Multicast [RFC3569], [RFC4607], the node - MUST support MLDv2 [RFC3810]. + MUST support MLDv2 [RFC3810]. In all cases, nodes are strongly + encouraged to implement 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 compatability mode. - When MLD is used, the rules in the Source Address Selection for the + When MLDv1 is used, the rules in the Source Address Selection for the Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be followed. 6. DNS and DHCP 6.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. @@ -413,21 +418,21 @@ 6.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315 6.2.1. 5.2.1. Managed Address Configuration The method by which IPv6 nodes that use DHCP for address assignment can obtain IPv6 addresses and other configuration information upon receipt of a Router Advertisement with the \'M' flag set is described in Section 5.5.3 of RFC 4862. In addition, in the absence of a router, those IPv6 nodes that use - DHCP for address assignment MUST initiate DHCP to obtain IPv6 + DHCP for address assignment MAY initiate DHCP to obtain IPv6 addresses and other configuration information, as described in Section 5.5.2 of RFC 4862. Those IPv6 nodes that do not use DHCP for address assignment can ignore the 'M' flag in Router Advertisements. 6.2.2. Other Configuration Information The method by which IPv6 nodes that use DHCP to obtain other configuration information can obtain other configuration information upon receipt of a Router Advertisement with the \'O' flag set is described in Section 5.5.3 of RFC 4862. @@ -785,21 +790,21 @@ "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. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. - [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over + [RFC5072] S.Varada, Haskin, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007. 15.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. @@ -883,15 +888,10 @@ attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA).