On Aug 17, 2007, at 11:36, Iljitsch van Beijnum wrote:
To stop unnecessary DHCP traffic. [...]
I think what we're seeing here is a vocal faction of the community
who believe that DHCP discovery multicasts are always necessary,
whether RA is present or not, and whether M=0 or M=1, despite the
text in RFC 2462.
Here's what they seem to be saying: wherever a DHCP server *may* be
present, DHCP discovery *MUST NOT* be prevented and *SHOULD NOT* be
delayed. If you agree with that, then perhaps it also makes sense to
move prefix and default gateway assignment into DHCP for the purpose
of improving efficiency. The DHCP advocates seem to view RA with M=1
as basically superfluous to the process, unless it can be made to
signal effectively that nodes *MUST NOT* perform stateless
autoconfiguration. Alas, unfortunately for them, RFC 2462 doesn't do
that. In fact, it explicitly states that a node *may* always perform
stateless autoconf after receiving RA with M=0 containing a PIO with
A=1, and hence the kvetching about rogue advertisers.
There is a closely related problem here in the language of RFC 2462.
Notice how the state of the ManagedFlag conceptual variable is
specified during processing of Router Advertisements.
Section 5.2 Autoconfiguration-Related Variables
Hosts maintain the following variables on a per-interface basis:
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.
[...]
5.5.3. Router Advertisement Processing
On receipt of a valid Router Advertisement (as defined in
[DISCOVERY]), a host copies the value of the advertisement's M bit
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
changes from TRUE to FALSE, the host should continue running the
stateful address autoconfiguration, i.e., the change in the
value of
the ManagedFlag has no effect. If the value of the flag stays
unchanged, no special action takes place. In particular, a host
MUST
NOT reinvoke stateful address configuration if it is already
participating in the stateful protocol as a result of an earlier
advertisement.
I see only one invocation of RFC 2119 requirements language in there,
and it's to apply a curious injunction not to restart DHCP discovery
every time RA with M=1 is received while ManagedFlag is TRUE. All
the rest of the verbiage about the ManagedFlag conceptual variable
amounts to a recommendation that DHCP discovery should be deferred
until the first receipt of RA with M=1 at the interface and should
remain in operation until the interface disconnects. One interesting
consequence of this verbiage is that it recommends setting the
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.
(Whether it *will* is not specified.) This basically nullifies the
utility of the one instance of RFC 2119 requirements language in how
the ManagedFlag is to be handled during RA processing.
As I said, it's very curious.
I think the new 6MAN working group should take up a project of
clarifying the requirements for processing router advertisements in
IPv6 nodes.
On a related note, I've heard that some operators intend to deploy
DHCP service using RA with M=1 and no PIO. I don't understand how
they imagine the "on-link flag" to be propagated in that scenario.
The "on-link flag" seems to be clearly in the domain of router
function, not dynamic node configuration. Is that to be described in
the forthcoming Internet draft?
--
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
--------------------------------------------------------------------
