[Dibbler] Dibbler 1.0.0 Release Candidate 1

Jyrki Soini Jyrki.Soini at iki.fi
Tue Jul 30 16:46:25 CEST 2013

On 30.7.2013 17:08, Karl Auer wrote:
> On Tue, 2013-07-30 at 14:01 +0200, Tomek Mrugalski wrote:
>> Here's a BIG counter-question: Do you think that approach makes sense?
>> If you were given a chance to be an editor of RFC3315 for a day, what
>> would you add/change to clarify the M,O behavior?*
> I think that the ONLY way that makes sense is for an interface to keep
> any addresses it has received via DHCP until their valid lifetimes
> expire.
> If M and O are informative, then M=1 means "there is a DHCP server
> available to get addresses from". It does NOT mean "you must get your
> address via DHCP". Similarly, M=0 means "there is no DHCP server
> available". It does NOT mean "you must not try to obtain an address via
> DHCP".
> So I think that "obey_ra_bits" should mean
>    a) only SOLICIT if M=1
>    b) only RENEW/REBIND if M=1 (still)
> Addresses should be retained until they expire. Or until an explicit
> direction to discard them occurs - such as a RECONFIGURE, or a negative
> response to RENEW/REBIND.
> Regards, K.
>> Tomek
>> * That's an honest question. There's RFC3315-bis work planned and I
>> expect to be involved. :)
I agree with Karl about sensible M bit semantics.

I think "obey_ra_bits" configuration should still send ORO for
dns-servers even if O=0 if it is on client configuration.
RFC4861 states:

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


More information about the Dibbler mailing list