My view is as follows and was going to wait till last call but will give it to you now. The "entire" 5.5.2 section is below of 2462.
------------------------------------------------------------- 5.5.2. Absence of Router Advertisements If a link has no routers, a host MUST attempt to use stateful autoconfiguration to obtain addresses and other configuration information. An implementation MAY provide a way to disable the invocation of stateful autoconfiguration in this case, but the default SHOULD be enabled. From the perspective of autoconfiguration, a link has no routers if no Router Advertisements are received after having sent a small number of Router Solicitations as described in [DISCOVERY]. --------------------------------------------------------------- This section in 2462 should be deleted. It is not necessary. 2462 only applies or should only apply if there are routers on the network. But if we want to keep the section MUST should become a MAY. But I advise strongly against this and just remove the section. It is superfluous wording in the specification, in hind site, as I supported it during 2462 deliberations as others. Thus we learn :--) Without routers on the link 2462 becomes a moot point and not relevant except for some very minor parts. We might even want to state in the introduction to 2462 it only applies when routers are in fact on the link. Now there is the exception. I have two that a mission critical customer is using as another means to use IPv6 on links. Example 1: Link comes live and no router appears but this has been anticipated and one of the nodes on the link has a direct interface to another network, which it cannot advertise as router for policy reasons (e.g. Satcom, T1). The onlink nodes know when they don't hear a router they all send packets peer-2-peer to the node that has the link, and this would be part of a proprietary config script on each node when no routers are seen or as a form of internal known policy based communications. The nodes still need link and configuration information and want to get it from DHCPv6 Server and thus will send DHCPv6 solicit messages. Example 2: Link comes live and no routers appear. An operational fast path to be prepared is to send DHCPv6 solicit to get all config required so when the router appears the nodes are configured with information to begin communications upon router communications on the link. In this example the idea is an optimized preparation for when the router appears. Regards, /jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of JINMEI Tatuya / ???? > Sent: Saturday, April 17, 2004 5:18 AM > To: Alain Durand > Cc: IPv6 Mailing List > Subject: Re: question on rfc2462bis: stateful mechanisms is a MUST? > > >>>>> On Fri, 16 Apr 2004 15:25:30 -0700, Alain Durand > >>>>> <[EMAIL PROTECTED]> said: > > > The following language from RFC2462 is still in 2462bis: > > 5.5 Creation of Global Addresses > > > Global addresses are formed by appending an interface > identifier to a > > prefix of appropriate length. Prefixes are obtained from Prefix > > Information options contained in Router Advertisements. > Creation of > > global addresses and configuration of other parameters > as described > > in this section SHOULD be locally configurable. However, the > > processing described below MUST be enabled by default. > > > > 5.5.2 Absence of Router Advertisements > > > If a link has no routers, a host MUST attempt to use stateful > > autoconfiguration to obtain addresses and other configuration > > information. An implementation MAY provide a way to disable the > > invocation of stateful autoconfiguration in this case, but the > > default SHOULD be enabled. > > > ==> Now that we are saying the stateful mechanism is > DHCPv6, does this > > implies > > that a host implementation that does not support DHCPv6 > > client is not conformant? > > What about an implementation that does only support > > DHCPv6-lite for DNS discovery? > > If I do not support DHCPv6, can I make the claim > that this is > > my way to "disable the > > invocation of sateful autoconfiguration" ? > > Before continuing the discussion, please read the following > message I sent last week. > > https://www1.ietf.org/mail-archive/working-groups/ipv6/current > /msg02227.html > > I've not seen any responses to this message...I'm not sure if > this means an agreement, but if so, the proposed change will > affect your above question. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, > Toshiba Corp. > [EMAIL PROTECTED] > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > 1H>þ°¢¹"ž+¢êfj)bž b²Ø¿¨žµú+€fŠx¬¶¶Š÷‘z«ž²Û!¶Úlÿü0ÃXžµú+ƒùšŠYšŸùb²Ø~â¦þ
