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

Hello, Ted.

Linux kernel provides rtnl socket interface for applications to get latest received valude of M&O bits in RA. You can obtain wanted informations using libnl APIs, which is the way that DHCPv6 client maintained by Redhat does. (I did not try this, but just checked source codes.) For client in our SMB router, I modified linux kernel to notify transition event of flags so that client may create a netlink socket and receive netlink message and process the event rightly instead of periodic polling.

I am not sure that any other OSes like BSD provide such interface. 

Joseph

------- Original Message -------
Sender : Ted Lemon<Ted.Lemon@nominum.com> 
Date   : 2008-10-16 04:34 (GMT+09:00)
Title  : Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits

On Oct 13, 2008, at 9:48 PM, Pekka Savola wrote:
> I don't see why M/O bits would need to be completely deprecated (they
> could still be hints about what should be available in the network).

I don't see what good a hint is.   We'd need to understand what advice  
the hint was intending to give.

> I've yet to see a DHCPv6 client implementation that would listen to
> the flags in RA and conditionally start or stop the service depending
> of the presence of flags there.  It's more complex to implement and to
> operate reliably. But granted I haven't done an extensive survey; I'd
> be interested in knowing how existing implementations operate.

I actually did write a prototype DHCPv6 client that did this, but it  
was hard, because the DHCPv6 client doesn't have access to the RA  
data.   So it just watches the IP addresses on the interface, and  
behaves according to what it sees.   But your larger point is correct  
- implementing a DHCPv6 client that takes hints or direction from the  
RA requires a degree of integration that is not widely present.

Personally, I feel that the degree of integration required makes  
implementing support for the RA bits a valuable exercise for operating  
system implementors, but I don't think the RFCs should require it.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------