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

From: 차현욱 <[email-masked]>
Date: Thu, 03 Jan 2008 00:51:53 +0000 (GMT)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: John Jason Brzozowski <[email-masked]>
Date: Thu, 03 Jan 2008 01:02:27 -0500

Hello Joseph,

I was wondering if you could help clarify your scenario.  If I read your
scenario correctly PC1 and PC2 see router advertisements from
access_router_1 and the cpe_router simultaneously?  Also, is the cpe_router
terminated against access_router_1 or access_router_2 or both?  What about
router advertisements from access_router_2, are there any?

Also, it is not clear why would the cpe_router should always send rotuer
advertisements with the M bit set to 1.  Can you clarify?  Aren't PC1 and
PC2 connected to cpe_router?

Thanks,

John

On 1/2/08 7:51 PM, "차현욱" <[email-masked]> wrote:

> 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.
> 
> 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.
> IMO, It is desirable that IPv6 protocol stacks and DHCPv6 clients should
> operate normally as users expect without RA reconfigurations.

=========================================
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
p) 856-324-2671
=========================================

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 3 Jan 2008 08:22:41 -0800

that's a problem.  i would characterize the root cause as being a
design factor of RS/RA...the client does not maintain a per-router
state machine, only global and per-prefix states.

one solution is to introduce per-router state...so that when AR2
advertises an "M bit" of zero, AR1's advertisement is not overridden.
this means on every RA reception, the client would have to traverse
a list of router states and only switch edge detections if all routers
agree.

another solution is to copy the M and O state down into the state
regarding the PIOs advertised within that RA.  this means the client
would have to traverse a list of all prefixes on that link, and
again only detect edges if any or no prefixes advertised 1's.

and a third solution is to simply always run DHCPv6 and ignore M/O
bits entirely.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg