[Dibbler] Dibbler 1.0.0 Release Candidate 1

Tomek Mrugalski thomson at klub.com.pl
Tue Jul 30 14:01:21 CEST 2013

On 13-07-30 02:20, Karl Auer wrote:
> On Tue, 2013-07-30 at 01:57 +0200, Tomek Mrugalski wrote:
>> Dibbler 1.0.0 Release Candidate 1 [2013-07-30]
> Congratulations!

>> - Client is now able to act according to received M(managed) and O(Other
>>   configuration options) in Router Advertisements, if configured to
>>   do so.
> Exactly how does it react to these? Specifically:
In normal configuration, client will request configuration for whatever
is specified in its client.conf and will ignore RA bits completely.
However, you may add obey-ra-bits clause and then things will be different.

Let's assume this minimal config:
iface eth0 {
   option dns-server

Without obey-ra-bits enabled, it would simply send SOLICIT with
one IA_NA option (i.e. requesting non-temporary address)
and ORO requesting DNS-SERVER configuration. With obey-ra-bits: if there
is RA received with M=0, O=0, then Dibbler will not send anything and
will simply wait till RA with at least one of M or O bits is received.
If RA is received with M=0, O=1, then Dibbler will request 'other'
configuration options, i.e. all those that are not stateful or in other
words any type of IA will not be sent. Dibbler will
send INFORMATION-REQUEST with ORO requesting DNS-SERVERS. With M=1, O=0
Dibbler will send a SOLCIT only request an address, but will not ask
for DNS-SERVERS. Finally, with M=1, O=1 Dibbler will
send SOLICIT asking for both an address and DNS-SERVERS.

That's clearly described in the User's Guide, section 4.10 (Features
HOWTO: Following M,O bits from Router Advertisements).

> - does it try to get an address even if it sees RAs with no "M"?
Assuming obey-ra-bits is present, the answer is no.

> - does it try to get an address if it sees no RAs at all?
Assuming obey-ra-bits is present, the answer is no.

> - if either of the above is "yes", how long does it wait before
> requesting an address?
Assuming obey-ra-bits is present, the answer is: until RA with at least
M or O bits is set. Until that happens, it sleep 3 seconds, checks the
bits status and the sleeps again.

> And the BIG question:
I knew someone will ask that eventually. Damn, that was quick :)

> - if the client sees an RA with "M" and gets an address, and later sees
> an RA without an "M", what does it do?
Keeps doing DHCPv6 and tries to renew the address. Here's the rationale
for that approach. The M and O bits are now informative in nature. They
are not normative. Please note the subtle difference between their old
definition in RFC2461 (section 4.2) and their updated definition in
RFC4861 (also in 4.2). There was a lot of discussions about that in
IETF, so folks decided to turn them into informative.

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?*


* That's an honest question. There's RFC3315-bis work planned and I
expect to be involved. :)

More information about the Dibbler mailing list