Subject: Re: RE: [dhcwg] Operational problem caused by inconsistent RA M and Oflags

From: HYUN WOOK CHA <[email-masked]>
Date: Thu, 03 Jan 2008 23:38:11 +0000 (GMT)

Hello, Thomas and Hemant.

Thank you for comments. 

I agree with you. As you pointed, RFC2462 also says if the value of ManagedFlag changes from TRUE to
FALSE and back again, DHCP is not supposed to be stopped and restarted. So, implementation of the Windows Vista is not correct by the guidance of the RFC.

One more thing I want to point is that the guidance itself has confused implementors. Is there any method that can stop DHCPv6 clients which was initiated by RA M flag set to 1? It is very natural that RA M flag set to 0 should disable DHCPv6 clients since the guidance instructs that they should be enabled by RA M flag set to 1. 

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

------- Original Message -------
Sender : Hemant Singh (shemant)<[email-masked]> 
Date   : 2008-01-04 04:24 (GMT+09:00)
Title  : RE: [dhcwg] Operational problem caused by inconsistent RA M and Oflags

I agree with Thomas' analysis. Section 5.5.3 in RFC 2462 makes sense and
the guidance this section gives to this issue is also adequate. 

Vista IPv6 stack needs looking into.

Hemant 

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Thursday, January 03, 2008 11:48 AM
To: [email-masked]
Cc: ???; ???; ???; ???; dhc WG
Subject: Re: [dhcwg] Operational problem caused by inconsistent RA M and
Oflags

Well, it is clear that it is preferable that all routers advertise
consistent values for the M&O bits.  But, wishing that were so, doesn't
prevent it from happening in some scenarios.

That said, I'm not sure I agree with your analysis:

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

IMO, this is incorrect.  If one looks at RFC 2462, it says:

     5.5.3.  Router Advertisement Processing

     On receipt of a valid Router Advertisement (as defined in
     [DISCOVERY]), a host copies the value of the advertisement's M
     bit into ManagedFlag. If the value of ManagedFlag changes from
     FALSE to TRUE, 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.  If the value of the
     ManagedFlag changes from TRUE to FALSE, the host should continue
     running the stateful address autoconfiguration, i.e., the change
     in the value of the ManagedFlag has no effect.  If the value of
     the flag stays unchanged, no special action takes place. In
     particular, a host MUST NOT reinvoke stateful address
     configuration if it is already participating in the stateful
     protocol as a result of an earlier advertisement.

Note especially that if the value of ManagedFlag changes from TRUE to
FALSE and back again, DHCP is not supposed to be stopped and restarted.

Given that RFC4862 has no words about the ManagedFlag, I'd say the
2462 guidance surely makes the most sense to follow.

Thomas

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

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 3 Jan 2008 18:59:25 -0500

Joseph,

Wrt to your statements about confusing implementors with the guidance
Thomas provided, I don't believe that is the case. The section that
Thomas has pointed out is clear for this issue. In your statements and
question below, you are only talking in terms of processing the M flag
without paying attention to what the old value of the M flag stored in
the host was. The section clearly discusses how to process the M flag of
RA by the host when the flag changes from FALSE to TRUE or vice versa. 

Hemant

-----Original Message-----
From: HYUN WOOK CHA [mailto:[email-masked]] 
Sent: Thursday, January 03, 2008 6:38 PM
To: Hemant Singh (shemant)
Cc: Thomas Narten; ???; ???; ???; ???; dhc WG
Subject: Re: RE: [dhcwg] Operational problem caused by inconsistent RA M
and Oflags

Thank you for comments. 

I agree with you. As you pointed, RFC2462 also says if the value of
ManagedFlag changes from TRUE to FALSE and back again, DHCP is not
supposed to be stopped and restarted. So, implementation of the Windows
Vista is not correct by the guidance of the RFC.

One more thing I want to point is that the guidance itself has confused
implementors. Is there any method that can stop DHCPv6 clients which was
initiated by RA M flag set to 1? It is very natural that RA M flag set
to 0 should disable DHCPv6 clients since the guidance instructs that
they should be enabled by RA M flag set to 1. 

Joseph HyunWook Cha

Software Engineer

------- Original Message -------
Sender : Hemant Singh (shemant)<[email-masked]> 
Date   : 2008-01-04 04:24 (GMT+09:00)
Title  : RE: [dhcwg] Operational problem caused by inconsistent RA M and
Oflags

Hemant 

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Thursday, January 03, 2008 11:48 AM
To: [email-masked]
Cc: ???; ???; ???; ???; dhc WG
Subject: Re: [dhcwg] Operational problem caused by inconsistent RA M and
Oflags

Thomas