Re: [v6ops] M/O flags and PD

[Tore Anderson <[e-mail]>]

Hi Ole,

* [e-mail]

> I've changed subject.
> 
> > I am in 100% agreement with you, but I have clearly failed to express
> > this correctly. What I have been meaning to say is that IA_PD is
> > considered part of the "other configuration" (a.k.a. "not addresses")
> > class of DHCPv6 options whose availability can be explicitly signaled
> > through O=1 *or* implicitly through M=1.
> 
> that's incorrect.

I hear you say that, but I am struggling to find any reference in any
standard that supports this view. Mailing list posts doesn't really
count here, even if they number in the thousands. I'm interested in
learning which section of which RFC is telling me I'm incorrect. Give
me a pointer to that and I'll shut up.

We can even disregard RFC 7084, as it's not a standard. RFC 4861
Section 4.2 is where the flags and their meaning is specified. It says,
and I quote:

      M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].

                     If the M flag is set, the O flag is redundant and
                     can be ignored because DHCPv6 will return all
                     available configuration information.

      O              1-bit "Other configuration" flag.  When set, it
                     indicates that other configuration information is
                     available via DHCPv6.  Examples of such information
                     are DNS-related information or information on other
                     servers within the network.

So DHCPv6-provided configuration is divided into two categories:

1) addresses
2) other

The availability of both of these categories of configuration is
signalled through the M/O flags. Nowhere that I can find is a third
«other than "other"» category of DHCPv6-provided configuration defined
or even hinted at.

So to me, the only logical interpretation of the above, is that the
availability of every single DHCPv6 option - including IA_PD - is
signalled through the O/M flags.

What RFC 4861 goes on to say makes me even more certain of this
interpretation:

        Note: If neither M nor O flags are set, this indicates that no
        information is available via DHCPv6.

> 7084 pseudocode:
> if A=1: do SLAAC
> 
> if M=1
>  /* include IA_NA in request to DHCPv6 server /*
>  /* include requests for other configuration options (not IA_*) /*
> else if O==1:
>  /* include requests for other configurations options */
> 
> do DHCP PD (include other options as indicated above)

Your pseudocode seems to confirm that you consider the IA_PD to be in
this third apparently-not-specified-anywhere «other than "other"»
category of DHCPv6-provided configuration.

It also appears to ignore the «If neither M nor O flags are set, this
indicates that no information is available via DHCPv6» statement. (But
I would agree that ignoring this "indication" is not forbidden.)

And finally it does not faithfully represent RFC 7084. Your code will
unconditionally request IA_PD in the O=M=0 case, while RFC 7084 says
this combination is «out of scope»:

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when either the M or O flags are set to 1 in a
           received Router Advertisement (RA) message.  Behavior of the
           CE router to use DHCPv6 prefix delegation when the CE router
           has not received any RA or received an RA with the M and the
           O bits set to zero is out of scope for this document.

In other words, your pseudocode seems to instead represent this
requirement (which is *not* a quote from RFC 7084):

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation.

That said, I do not mean to say that requesting IA_PD when O=M=0 is a
wrong thing to do for a RFC 7084 CE. The O=M=0 case is, after all, left
unspecified.

> your pseudocode also had the bug of coupling DHCP and SLAAC address
> assignment.

Agreed.

In any case, I think we can also agree that it is improper for
draft-jjmb-v6ops-unique-ipv6-prefix-per-host-00 to imply that the
availability of IA_PD is contingent on the M flag alone?

The authors could avoid opening this apparent can of worms by changing
the current bullet:

   o  M-flag = 0 (UE/subscriber address is not managed through DHCPv6),
      this flag may be set to 1 in the future if/when DHCPv6 prefix
      delegation support over Wi-Fi is desired)

With:

   o  M-flag = 0 (UE/subscriber address is not managed through DHCPv6).

That way, the draft doesn't say anything controversial, and we can
leave the discussion on if IA_PD is «addresses», «other than
addresses», or «other than "other than addresses"» for another day.

[The draft does in any case goes on to say that O should be set to 1,
which means the described network already accomodates for (future) use
of IA_PD for both of our world views: an UE implemented by me would
then request IA_PD because of O=1, and one written by you would - AIUI
- just ignore the O/M flags and request IA_PD unconditionally.]

Tore