[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dhcwg] Operational problem caused by inconsistent RA M and O flags



 
Hello Woj.
I discussed this topic at last DHC meeting and got feedbacks. 
Thomas Narten said that Implementation of Windows Vista does not conform to RFC2462 in that transition of M flag from 1 to 0 should not affect running clients. If it does, the mis-behavior described below will not be shown. 
However, as I see that there is no defined way to revoke client invoked by RA flags and no reason for the transition of M flag from 1 to 0 not to revoke it, I continued to discuss and published a draft with Bernie Volz.
Please check the URL: http://www.ietf.org/internet-drafts/draft-cha-ipv6-ra-mo-00.txt
I will appreciate if you share your concerns in more detail. 

Joseph


> -----Original Message-----
> From: Wojciech Dec (wdec) [mailto:wdec at cisco.com] 
> Sent: Saturday, June 28, 2008 2:12 AM
> To: hyunwook.cha at samsung.com
> Subject: RE: [dhcwg] Operational problem caused by 
> inconsistent RA M and O flags
> 
> Hi Joseph,
> 
> Am wondering if you received further replies on the thread 
> other than up
> to http://www.ietf.org/mail-archive/web/dhcwg/current/msg08215.html ?
> I'm particuraly concerned at the issue of M flag 0-1-0 toggle not
> turning DHCP off...
> 
> Regards,
> Woj.
> 
> > -----Original Message-----
> > From: hyunwook.cha at samsung.com [mailto:hyunwook.cha at samsung.com] 
> > Sent: 03 January 2008 01:52
> > To: dhcwg at ietf.org
> > Cc: ???; ???; ???; ???
> > Subject: [dhcwg] Operational problem caused by inconsistent 
> > RA M and O flags
> > 
> > Dear, all.
> > 
> > Though I already posted this issue, I want to re-issue this 
> > because I do not think that any clear explanation were given.
> > As you know, current IPv6 stack and DHCPv6 clients have been 
> > implemented in processing RA M/O flags as instructed by 
> > previous specification RFC2462.   
> > That is, both ManagedFlag and OtherConfigFlag are copied from 
> > the M and O flag fields of the most recently received Router 
> > Advertisement message respectively. 
> > And a host invokes the DHCPv6 client to request both address 
> > and other information when received Router Advertisement 
> > message change an internal state variable(ManagedFlag) from 
> > FALSE to TRUE and the DHCPv6 client is not running. 
> >    
> > I think that these requirements are based on the assumption 
> > that RA M/O flags from different routers on a link are consistent. 
> > However, if routers on a link do not belong to the same 
> > administrative domain, the assumption may be incorrect and 
> > result in DHCP6 clients' misbehaviors.
> > 
> > Please think about following scenario.   
> > 
> > 
> >                                     ------------------ 
> >                                     | ISP2                  |
> >    -----------------        | Access_Router2 |      
> >    | ISP1                |       ------------------              
> >    | Acess_Router1 |                   |              
> >    -----------------            CPE_Router
> >      |RA(P1, M=1)                        |RA(P2, M=0)
> >    ------------------------------------ link0
> >           |        |       |       |
> >          pc1    pc2    pc3   pc4
> >   
> > Let us assume that specific hosts pc1 and pc2 are supposed to 
> > be assigned global IPv6 addresses by ISP1.   
> > Originally, Access_Router1 advertises prefix P1 with M flag 
> > set to 1 and CPE_Router prefix P2 with M flag set to 0 On the 
> > link (link0).
> > However, the CPE_Router shoud be fixed to send RA message 
> > with M flag set to 1 to avoid host-side confusion caused by 
> > frequent changes of ManagedFlag variable.
> > For example, the DHCPv6 client in Windows Vista will continue 
> > request and release of a global IPv6 address repeatedly 
> > according to M flag value of received RA messages.  
> > In addition, if users do not want DHCPv6 service from ISP1 
> > more, CPE_Router shoud be fixed to send RA message with M 
> > flag set to 0 because DHCPv6 server is not available. 
> > Thus, the requirement that RA M, O flags should be consistent 
> > on a link cause manual RA reconfiguration cost.
> > 
> > IMO, It is desirable that IPv6 protocol stacks and DHCPv6 
> > clients should operate normally as users expect without RA 
> > reconfigurations. 
> > Please let me know if you have already considered this issue 
> > or know related information or any other opinions.
> > 
> > Thank you in advance.
> > 
> > 
> > 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
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg