draft-ietf-ipv6-node-requirements-08.txt

非常好的dns解析软件

   IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
   This specification MUST be supported for nodes that are hosts.

   Nodes that are routers MUST be able to generate link local addresses
   as described in RFC 2462 [RFC-2462].

   From 2462:

      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



Loughney (editor)          February 16, 2004                    [Page 7]





Internet-Draft


      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.

4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041

   Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041]
   SHOULD be supported.  It is recommended that this behavior be
   configurable on a connection basis within each application when
   available.  It is noted that a number of applications do not work
   with addresses generated with this method, while other applications
   work quite well with them.

4.5.4 Default Address Selection for IPv6 - RFC3484

   The rules specified in the Default Address Selection for IPv6 [RFC-
   3484] document MUST be implemented. It is expected that IPv6 nodes
   will need to deal with multiple addresses.

4.5.5 Stateful Address Autoconfiguration

   Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-
   3315] is the standard stateful address configuration protocol; see
   section 5.3 for DHCPv6 support.

   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 which 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.

4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710

   Nodes that need to join multicast groups SHOULD implement MLDv2
   [MLDv2]. However, if the node has applications, which only need
   support for Any- Source Multicast [RFC3569], the node MAY implement
   MLDv1 [MLDv1] instead. If the node has applications, which need
   support for Source- Specific Multicast [RFC3569, SSMARCH], the node
   MUST support MLDv2 [MLDv2].




Loughney (editor)          February 16, 2004                    [Page 8]





Internet-Draft


   When MLD is used, the rules in "Source Address Selection for the
   Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be
   followed.

5. Transport Layer and DNS

5.1 Transport Layer

5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147

   This specification MUST be supported if jumbograms are implemented
   [RFC- 2675].

5.2 DNS

   DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363]
   and [RFC-3596] MAY be supported.  Not all nodes will need to resolve
   names. All nodes that need to resolve names SHOULD implement stub-
   resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
   support for:

    - AAAA type Resource Records [RFC-3596];
    - reverse addressing in ip6.arpa using PTR records [RFC-3152];
    - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
      octets.

   Those nodes are RECOMMENDED to support DNS security extentions
   [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT].

   Those nodes are NOT RECOMMENDED to support the experimental A6 and
   DNAME Resource Records [RFC-3363].

5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732

   RFC 2732 MUST be supported if applications on the node use URL's.

5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315

5.3.1 Managed Address Configuration

   Those IPv6 Nodes that use DHCP for address assignment initiate DHCP
   to obtain IPv6 addresses and other configuration information upon
   receipt of a Router Advertisement with the 'M' flag set, as described
   in section 5.5.3 of RFC 2462.  In addition, in the absence of a
   router, those IPv6 Nodes that use DHCP for address assignment MUST
   initiate DHCP to obtain IPv6 addresses and other configuration
   information, as described in section 5.5.2 of RFC 2462.  Those IPv6
   nodes that do not use DHCP for address assignment can ignore the 'M'



Loughney (editor)          February 16, 2004                    [Page 9]





Internet-Draft


   flag in Router Advertisements.

5.3.2 Other Configuration Information

   Those IPv6 Nodes that use DHCP to obtain other configuration
   information initiate DHCP for other configuration information upon
   receipt of a Router Advertisement with the 'O' flag set, as described
   in section 5.5.3 of RFC 2462.  Those IPv6 nodes that do not use DHCP
   for other configuration information can ignore the 'O' flag in Router
   Advertisements.

   An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to
   obtain other configuration information.

6. IPv4 Support and Transition

   IPv6 nodes MAY support IPv4.

6.1 Transition Mechanisms

6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893

   If an IPv6 node implements dual stack and tunneling, then RFC2893
   MUST be supported.

   RFC 2893 is currently being updated.

7. Mobile IP

   The Mobile IPv6 [MIPv6] specification defines requirements for the
   following types of nodes:

       - mobile nodes
       - correspondent nodes with support for route optimization
       - home agents
       - all IPv6 routers

   Hosts MAY support mobile node functionality described in Section 8.5
   of [MIPv6], including support of generic packet tunneling [RFC-2473]
   and secure home agent communications [MIPv6-HASEC].

   Hosts SHOULD support route optimization requirements for
   correspondent nodes described in Section 8.2 of [MIPv6].

   Routers SHOULD support the generic mobility-related requirements for
   all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY
   support the home agent functionality described in Section 8.4 of
   [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC].



Loughney (editor)          February 16, 2004                   [Page 10]





Internet-Draft


8. Security

   This section describes the specification of IPsec for the IPv6 node.

8.1 Basic Architecture

   Security Architecture for the Internet Protocol [RFC-2401] MUST be
   supported. RFC-2401 is being updated by the IPsec Working Group.

8.2 Security Protocols

   ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported.
   RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group.


8.3 Transforms and Algorithms

   Current IPsec RFCs specify the support of certain transforms and
   algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96.
   The requirements for these are discussed first, and then additional
   algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed.

   NULL encryption algorithm [RFC-2410] MUST be supported for providing
   integrity service and also for debugging use.

   The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD
   NOT be supported. Security issues related to the use of DES are
   discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as
   required by the existing IPsec RFCs, but as it is currently viewed as
   an inherently weak algorithm, and no longer fulfills its intended
   role.

   The NULL authentication algorithm [RFC-2406] MUST be supported within
   ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC-
   2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP,
   described in [RFC-2403] MUST be supported. An implementer MUST refer
   to Keyed- Hashing for Message Authentication [RFC-2104].

   3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC
   and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES-
   CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected
   to be a widely available, secure algorithm that is required for
   interoperability. It is not required by the current IPsec RFCs, but
   is expected to become required in the future.

   In addition to the above requirements, "Cryptographic Algorithm
   Implementation Requirements For ESP And AH" [CRYPTREQ] contains the
   current set of mandatory to implement algorithms for ESP and AH as



Loughney (editor)          February 16, 2004                   [Page 11]





Internet-Draft


   well as specifying algorithms that should be implemented because they
   may be promoted to mandatory at some future time.  It is RECOMMENDED
   that IPv6 nodes conform to the requirements in this document.

8.4 Key Management Methods

   Manual keying MUST be supported.

   IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast
   traffic. 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. Note that the IPsec WG is working
   on the successor to IKE [IKE2]. Key management methods for multicast
   traffic are also being worked on by the MSEC WG.

   "Cryptographic Algorithms for use in the Internet Key Exchange
   Version 2" [IKEv2ALGO] defines the current set of mandatory to
   implement algorithms for use of IKEv2 as well as specifying
   algorithms that should be implemented because they made be promoted
   to mandatory at some future time. It is RECOMMENDED that IPv6 nodes
   implementing IKEv2 conform to the requirements in this
   document.

9. 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.

9.1 General

9.1.1 IPv6 Router Alert Option - RFC2711


   The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-
   Hop Header that is used in conjunction with some protocols (e.g.,
   RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will
   need to be implemented whenever protocols that mandate its usage are
   implemented. See Section 4.6.

9.1.2 Neighbor Discovery for IPv6 - RFC2461

   Sending Router Advertisements and processing Router Solicitation MUST
   be supported.

10. Network Management

   Network Management MAY be supported by IPv6 nodes.  However, for IPv6



Loughney (editor)          February 16, 2004                   [Page 12]





Internet-Draft


   nodes that are embedded devices, network management may be the only
   possibility to control these nodes.

10.1 Management Information Base Modules (MIBs)

   The following two MIBs SHOULD be supported by nodes that support an
   SNMP agent.

10.1.1  IP Forwarding Table MIB

   IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes
   that support an SNMP agent.

10.1.2 Management Information Base for the Internet Protocol (IP)

   IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an
   SNMP agent.

11. Security Considerations

   This draft does not 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.  "IP Security
   Document Roadmap" [RFC-2411] is important for everyone to read.

   The security considerations in RFC2460 describe the following:

      The security features of IPv6 are described in the Security
      Architecture for the Internet Protocol [RFC-2401].

12. References

12.1 Normative

   [CRYPTREQ]     D. Eastlake 3rd, "Cryptographic Algorithm Implementa-
                  tion Requirements For ESP And AH", draft-ietf-ipsec-
                  esp-ah-algorithms-01.txt, January 2004.

   [IKEv2ALGO]    J. Schiller, "Cryptographic Algorithms for use in the
                  Internet Key Exchange Version 2", draft-ietf-ipsec-
                  ikev2-algorithms-04.txt, Work in Progress.

   [DHCPv6-SL]    R. Droms, "A Guide to Implementing Stateless DHCPv6
                  Service", draft- ietf-dhc-dhcpv6-stateless-00.txt,
                  Work in Progress.

   [MIPv6]        J. Arkko, D. Johnson and C. Perkins, "Mobility Support
                  in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in



Loughney (editor)          February 16, 2004                   [Page 13]





Internet-Draft


                  progress.

   [MIPv6-HASEC]  J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec
                  to Protect Mobile IPv6 Signaling between Mobile Nodes
                  and Home Agents", draft-ietf- mobileip-mipv6-ha-
                  ipsec-06.txt, Work in Progress.

   [MLDv2]        Vida, R. et al., "Multicast Listener Discovery Version
                  2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in
                  Progress.

   [RFC-1035]     Mockapetris, P., "Domain names - implementation and
                  specification", STD 13, RFC 1035, November 1987.

   [RFC-1981]     McCann, J., Mogul, J. and Deering, S., "Path MTU
                  Discovery for IP version 6", RFC 1981, August 1996.