Hi all, I've updated the draft on 4 major points that were discussed at the IETF. Roughly they cover stateful address autoconfig support, DHCP support, MIPv6 support and DES support.
I want to get a sense of the WG, if it would be OK to send the updated draft out and ask for a WG last call. I have an issue tracker created, to help out on the WG last call that I would like to use (http://danforsberg.info:8080/draft-ietf-ipv6-node-requirements/index) and I'd probably like to get some expert reviews, especially for the security sections. What does the group think? If it is OK with the WG, I could send the updated draft out by the end of the week. I have included the text that I have updated at the end of the mail. thanks, John 1) Stateful Address Autoconfiguration text: Stateful Address Autoconfiguration MAY be supported. DHCP [DHCPv6] is the standard stateful address configuration protocol, see section 5.3 for DHCPv6 support. For nodes which do not support Stateful Address Autoconfiguration, the node 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). 2) Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Updated to: 5.3.1 Managed Address Configuration An IPv6 node that does not include an implementation of DHCP will be unable to obtain any IPv6 addresses aside from link-local addresses when it is connected to a link over which 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). An IPv6 node that receives a router advertisement with the 'M' flag set and that contains advertised prefixes will configure interfaces with both stateless autoconfiguration addresses and addresses obtained through DHCP. For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'M' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, IPv6 Nodes that implement DHCP MUST attempt to use DHCP. An IPv6 node that does not include an implementation of DHCP will be unable to dynamically obtain any IPv6 addresses aside from link-local addresses when it is connected to a link over which 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). In this situation, the IPv6 Node will be unable to communicate with other off-link nodes unless a global or site-local IPv6 address is manually configured. 5.3.2 Other stateful configuration DHCP provides the ability to provide other configuration information to the node. An IPv6 node that does not include an implementation of DHCP 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. For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'O' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, hosts that implement DHCP MUST attempt to use DHCP. For IPv6 Nodes that do not implement DHCP, the 'O' flag of a Router Advertisement can be ignored. Furthermore, in the absence of a router, this type of node is not required to initiate DHCP. 3) Mobile IP requirements for routers updated to: Routers SHOULD support mobile IP requirements. 4) DES support removed: 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. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
