[Dibbler] Address Autoconfiguration based upon Router Advertisement

[Jyrki Soini]

On Tue, Sep 9, 2008 at 5:29 PM, Tomasz Mrugalski <thomson at klub.com.pl> wrote:
> On Tue, 9 Sep 2008 somebody known as Lalit Mishra wrote:
>
>> RFC 2462 5.2 states that hosts should maintain variables ManagedFlag
>> and  OtherConfigFlag on per interface basis. These flags describe the
>> behavior of the host for stateful autoconfiguration mechanism.
>> Accordingly if router advertisement on a link has ManagedFlag set  and
>> the host is not already running the stateful address autoconfiguration
>> protocol, the host should invoke the stateful address autoconfiguration
>> protocol, requesting both address information and other information.
>> (section 5.5.3).
>>

RFC 4862 that obsoletes RFC 2462 states in the Changes section:

" o  Removed the text regarding the M and O flags, considering the
      maturity of implementations and operational experiences.
      ManagedFlag and OtherConfigFlag were removed accordingly.  (Note
      that this change does not mean the use of these flags is
      deprecated.)
"


>> Is this behavior observed for dibbler 0.7.2 and linux kernel 2.6.13?
>> When I run dibbler-client the machine acquires an address from the
>> server running on the same link even if the router advertisement has
>> ManagedFlag set. Is there some configuration changes required to make
>> this work according to RFC?

Thats exactly the behaviour RFC 2462 anticipated: DHCPv6 is the
stateful address autoconfiguration protocol.

The M and O bits are discussed several times at IETF without a concensus
of the exact semantics of the bits and what should happen when the bit changes.
The current thinking that can be accepted by most is that the bits are
only hints for
the hosts whether DHCPv6 is available on the link or not.

> No, that part is not implemented. Client asks for whatever is specified in
> the client.conf. There are several reasons behind that:
> - I don't know how to check those bits (under Linux and various Windows
>   flavors)
> - When specifies that some options or addresses are to be configured, it
>   would complicate things if client waited for RA and started after that.
>   In other words, right now you can use DHCP without RA. With this change,
>   you'd have to use them together.
>
> Especially reason 2 is significant. It raises some questions: Is it
> possible to run DHCPv6 in a routerless network? In mobile environment, is
> it ok to start DHCP process before RA is received? If not, we are adding
> extra delays to the handover.
>

The delay might not be that big, the host may send Router Solicitation
message to get
RA message right away without waiting for the next timely multicasted RA.

> On the other hand, if you show me how to read those bits, I could
> implement support for them. A piece of code or patch would be appreciated.
>
> Regards,
> Tomek
> _______________________________________________
> http://klub.com.pl/cgi-bin/mailman/listinfo/dibbler
>

--
Jyrki Soini