On Aug 17, 2007, at 13:22, James Carlson wrote:
james woodyatt writes:
into ManagedFlag. 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. If the value of the
ManagedFlag
[...]
ManagedFlag to FALSE upon receiving RA with M=0. When the next RA
arrives with M=1, the node will then be free to restart DHCP
discovery because the above requirement will no longer apply.
No, it won't be free to do so. The text quoted above makes it fairly
clear that if you're already running the stateful address protocol,
you don't restart it. Even if the flag changes from FALSE to TRUE.
You're right. My mistake. The sentence preceding the requirement
doesn't specify an actual contingency. The requirement applies
regardless of the current state of the ManagedFlag. Once the
stateful autoconfiguration protocol starts, it's expected to continue
without restarting until the interface disconnects from the link.
It's a one-shot event on a given interface. If you time out waiting
to hear from routers, or if any router anywhere ever tells you to run
DHCPv6 on that interface, then that's what you do. The only time you
_don't_ run DHCPv6 is when you (A) consistently hear from routers and
(B) those routers all tell you M=0 and O=0.
I don't see any MUST NOT that requires stateless AddrConf to be
deferred while the node waits "for a time" to receive of RA with
M=1. If the typical network with DHCP service never has any
legitimate routers sending RA of any sort, then nodes will typically
acquire service more quickly after connecting if they do not wait for
packets that will never arrive. Since there is no RFC 2119
requirement to wait, a conforming implementation can certainly choose
not to defer DHCP discovery while prefix discovery has not yet
completed, despite the informative text suggesting that waiting is
appropriate.
Whether DHCP6 must not complete until prefix discovery has completed
is an open question, or so it seems to me after reading RFC 3315 and
looking for guidance on the subject. I suspect I would prefer to see
RFC 3315 revised to define a new IA_PI (prefix information) option
for clients to use, which would associate a list of discovered
prefixes with their generated IAID. Clients that send Solicit
messages containing IA_TA or IA_NA options without an accompanying
IA_PI option will be implying that they failed or refused to discover
any prefixes. Servers may then refuse to send Advertise messages to
clients that have no acceptable prefixes. When clients provide a
IA_PI option, then servers are required to assign addresses from the
specified list of prefixes.
--
james woodyatt <[EMAIL PROTECTED]>
member of technical staff, communications engineering
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
