Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits

[Markku Savela <[e-mail]>]

> From: Ralph Droms <[e-mail]>

> 1. Is the following text an accurate summary of the previous IETF
> consensus on the definition and use of M/O bits:
> 
>    The M/O flags indicate the availability of DHCPv6 service for
>    address assignment and other configuration information,
>    respectively.  The IPv6 specifications make no requirements on the
>    behavior of DHCPv6 clients in response to the values of the M/O
>    flags received in RAs.

YES.

> 2. Does the IETF choose to continue to accept this consensus or should
> the definition of client behavior in response to the M/O flags be
> revisited?

> 2. YES: Is that consensus adequately described in the IPv6 RFCs or  
> should
> the IPv6 RFCs be revised in some way to describe the consensus
> requirements?

YES.

I don't know how to fix the descriptions, for example a host prepared
to support multihoming, would

 - configure addresses from RA, and

 - if it sees M/O, it might *also* try to acquire additional addresses
   from DCHPv6

 - if also might acquire IPv4 addresses via DCHPv4, and get the DNS
   servers from it (to be used for both IPv4 and IPv6 resolutions)

Or a host might wait for RA, and see if M/O are set. Depending on some
local configuragtion toggle in the host, it could either prefer DHCPv6
or RA address configuration.

Or based on some configuration toggle on a host, it could just do
DHCPv6 without waiting RA.

Or, etc...

There are many possible needs for the host, I don't think IETF should
limit the possible actions by a too restrictive specification.

ps. I still think that the RA could also include DNS server addresses
(as proposed by some RFC? Draft?)
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------