Hi all,

Reading 2462, it says about the M-bit:

     ManagedFlag      Copied from the M flag field (i.e., the
                       "managed address configuration" flag) of the most
                       recently received Router Advertisement message.
                       The flag indicates whether or not addresses are
                       to be configured using the stateful
                       autoconfiguration mechanism. It starts out in a
                       FALSE state.

      OtherConfigFlag  Copied from the O flag field (i.e., the "other
                       stateful configuration" flag) of the most
                       recently received Router Advertisement message.
                       The flag indicates whether or not information
                       other than addresses is to be obtained using the
                       stateful autoconfiguration mechanism. It starts
                       out in a FALSE state.

This makes me believe that by both these being set to FALSE, then
Stateful Address Autoconfig is not the default.  This, then,
seems to imply that Stateful Address Autoconfig support is
a SHOULD or MAY.

However, further down, it says:

                If the value of ManagedFlag changes from FALSE to
   TRUE, and the host is not already running the stateful address
   autoconfiguration protocol, the host should invoke the stateful
   address autoconfiguration protocol, requesting both address
   information and other information. 

and says about the O-bit:

                If the
   value of OtherConfigFlag changes from FALSE to TRUE, the host should
   invoke the stateful autoconfiguration protocol, requesting
   information (excluding addresses if ManagedFlag is set to FALSE).


My proposed text is:

4.5.5 Stateful Address Autoconfiguration

   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, an
   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).

... If the WG feels that SHOULD is the proper level, I suggest adding
something along the lines of:

  Stateful Address Autoconfiguration SHOULD be supported, unless the
  possible use cases for the specific implementation concerned are clearly
  satisfied by Stateless Address Autoconfiguration.


----------------- and -----------

5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   
   DHCP MUST be supported for nodes that support stateful address 
   autoconfiguration.  DHCP SHOULD be supported for nodes which need
   support for other configuration, such as DNS configuration.  Nodes
   which do not support stateful address autoconfiguration or need
   support for other configuration, MAY support DHCPv6.

   DHCP [DHCPv6] is the standard stateful configuration protocol and
   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.





--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to