Subject: [dhcwg] Questions about RA flags (M, O) processing

From: 차현욱 <[email-masked]>
Date: Thu, 04 Oct 2007 08:07:06 +0000 (GMT)

Dear, all.

I have questions about RA flags (M, O) processing. 
From the TAHI conformance spec document, I know that if the client already has an active binding, changes of M flag (1->0->1) does not affect behavior of the client. Also, as long as stateless dhcp client initiated does not receive Reply message, changes of O flag (1->0) does not affect behavior of the client.
If so, I want to know cases where changes of flags affect behavior of a client after it was triggered(or enabled) in the manner of stateful or stateless mode. 
Please give me detailed scenarios and explanations. 
Thank you in advance.

Regards, 

Joseph HyunWook Cha

The truth will set you free !!!

Software Engineer 
Development Part 1. I/Infra  
Network System Division 
Tel 031-279-3804  Mobile 010-3024-3804

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: HYUN WOOK CHA <[email-masked]>
Date: Wed, 10 Oct 2007 07:12:06 +0000 (GMT)

Dear Ralph, 

In case of the IBM DHCPv6 client, they obtain most recent flag(M, O) value saved in the kernel variable by sending a netlink request (RTM_NEWLINK) through a netlin
k socket and receiving a netlink reply from kernel including the wanted flags values.

Because of my shortage of IPv6 experience and knowledge, I am not sure that different RA flags from different routers are just an administration error. However, I think that wrong or inefficient behaviors of implementations should be avoided event if that is right. 

Thank you.

Joseph

------- Original Message -------
Sender : Ralph Droms<[email-masked]> 
Date   : 2007-10-10 14:13
Title  : Re: [dhcwg] Fwd: Questions about RA flags (M, O) processing

An unmodified Linux system will not run DHCPv6 regardless of the  
state of the M and O bits because, as far as I know, Linux is not  
distributed with a DHCPv6 client.

It's interesting to know that the IBM DHCPv6 client checks the  
received RA flags; how does it get the values of those flags out of  
the kernel?

There was a long discussion about the M and O bits before the  
publication of RFCs 4861 and 4862, with the result that the semantics  
of the M and O flags were left undefined in RFC 4862.  It seems the  
Vista DHCPv6 now uses a different interpretation of the M and O flags  
than was defined in RFC 2462.

In general, there is an assumption that all routers on a link are in  
the same administrative domain, and that different configuration  
information from those routers is a configuration error.

- Ralph

On Oct 10, 2007, at Oct 10, 2007,12:18 AM, 차현욱 wrote:

>
> Dear, Alex and all.
>
> Alex, Thank you for your reply.
>
> As long as I understand for linux kernel (2.6.20), conditions for  
> the stateless autoconfiguration (rfc4862) are as follows.
> For the kernel configurations, forwarding=0(Host only),  
> accept_ra=1, accept_ra_pinfo=1, autoconf=1.
> Then, only if A flag in the prefix info option is set to 1, the  
> stateless autoconfiguration is performed irrespective of the M flag.
> An open source implementation by IBM I checked dhcpv6 daemon gets  
> flag values recorded in "struct inet6_dev" kernel variable during  
> initial stage to be controlled in which mode the client daemon  
> starts by previous received RA flags.
>
> IMO, if DHCPv6 client is designed to be controlled by RA flags, the  
> issues for different RA flags from different routers should be  
> considered and addressed.
> I wonder this WG think this is important issue to tackle in the wg  
> scope or not. If not, which WG will be addressed? IPv6 MAN?
>
> At this stage, I hope I may have lucky chances to get valuable  
> informations from DHCPv6 authors and implementors.
> Any comments welcomed!!!
>
> Thank you all.
>
> Joseph HyunWook Cha
>
> ------- Original Message -------
> Sender : Alexandru Petrescu<[email-masked]>
> Date   : 2007-10-09 21:45
> Title  : Re: [dhcwg] Fwd: Questions about RA flags (M, O) processing
>
> 차현욱 wrote:
>> Dear, all.
>>
>> For the previous questions, I checked the behavior of a Windows Vista
>>  DHCPv6 client. Maybe many folks already know this, but I want to
>> share the results and get helpful ideas and advices from the DHC WG.
>>
>> If the dhcpv6 client received a RA message with M flag set to 1 at
>> first, it begined to solicit by SOLICIT messages. Then, immediately
>> after it received following RA message with M flag set to 0, it
>> released leases addresses by RELEASE messages. If the dhcpv6 client
>> received a RA message with M flag set to 0 and O flag set to 1 at
>> first, it started as the stateless mode by INFO-REQUEST messages.
>> Then, when it received following RA message with M flag set to 0 and
>> O flag set to 0, it removed all other config informations including
>> DNS server addresses. When the client received multiple RA messages
>> with flags set to different combinations from different Routers or
>> different links in one router, it performed infinitely iterative
>> operations between stateful (SOLICIT-REQUEST) and stateless
>> (INFO_REQUEST).
>
> GReat to know thanks.
>
> For information, linux recent kernels seem to ignore the M==1 flag  
> in RA
> and do auto-configure addresses statelessly, without invoking DHCPv6
> transactions.  Which is not very good, it should do DHCPv6 SOLICIT,  
> IMHO.
>
>> I did not find any RFCs and drafts addressing these issues. Is there
>> anybody who knows helpful informations and experiences of
>> implementations which tackled these?
>
> Err... rfc4862 (recently upgrading rfc2462 says):
>> 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.)
>
> Reading this text one would think that M flag is no longer used in RA.
> Then reading rfc4861 (recently obsoletes rfc2461) one sees:
>> M              1-bit "Managed address configuration" flag.  When set,
>> it indicates that addresses are available via Dynamic Host
>> Configuration Protocol [DHCPv6].
>
> So, yes, I think rfcs and their implementations should be updated
> accordingly.
>
> Alex
>
>
>>
>> Many thanks,
>>
>> Joseph Cha
>>
>> ------- Original Message ------- Sender : 차현욱
>> <[email-masked]>  E4(선임)/선임/개발1그룹(I/ 
>> Infra)/삼성전자 Date   :
>> 2007-10-04 17:07 Title  : Questions about RA flags (M, O) processing
>>
>>
>> Dear, all.
>>
>> I have questions about RA flags (M, O) processing. From the TAHI
>> conformance spec document, I know that if the client already has an
>> active binding, changes of M flag (1->0->1) does not affect behavior
>> of the client. Also, as long as stateless dhcp client initiated does
>> not receive Reply message, changes of O flag (1->0) does not affect
>> behavior of the client. If so, I want to know cases where changes of
>> flags affect behavior of a client after it was triggered(or enabled)
>> in the manner of stateful or stateless mode. Please give me detailed
>> scenarios and explanations. Thank you in advance.
>>
>> Regards,
>>
>> Joseph HyunWook Cha
>>
>> Software Engineer Development Part 1. I/Infra Network System Division
>> --------------------------------------------------------------------- 
>> ---
>>
>>
>>
>> _______________________________________________ dhcwg mailing list
>> [email-masked] https://www1.ietf.org/mailman/listinfo/dhcwg
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
>
>
>