Re: [dhcwg] Re: prefix length determination for DHCPv6

[james woodyatt <jhw at apple.com>]

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 <jhw at apple.com>
member of technical staff, communications engineering



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------