[Dibbler] Dibbler 1.0.0 Release Candidate 1

Karl Auer kauer at biplane.com.au
Tue Jul 30 16:08:55 CEST 2013


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. :)

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017



More information about the Dibbler mailing list