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

From: 차현욱 <[email-masked]>
Date: Thu, 03 Jan 2008 07:43:12 +0000 (GMT)

Hello, John.

Thank you for many questions. 
Let me clarify the example customer site.
This site is multi-homed via ISP1 and ISP2. For ISP1, one modem is connected to link0 and all PCs can receive RAs from access_router1 directly. For ISP2, CPE_Router receives a prefix delegated by access_router2 and advertise derived prefix P2 from the prefix to the link0. So, all PCs can receive RAs from access_router1 and cpe_router simultaneously. 

The reason why the cpe_router should always send rotuer advertisements with the M bit set to 1 is the consistency of RA flags. As I posted before, hosts including Windows Vista almost can not use leased IPv6 addresses from ISP1 through DHCPv6, because hosts will continue requesting and releasing stateful addresses iteratively according to RA M/O flag values.  

If you have another questions or comments, please let me know.

Regards,

------- Original Message -------
Sender : John Jason Brzozowski<[email-masked]> 
Date   : 2008-01-03 15:02 (GMT+09:00)
Title  : Re: [dhcwg] Operational problem caused by inconsistent RA M and O flags

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

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

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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 03 Jan 2008 11:47:59 -0500

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.

> release of a global IPv6 address repeatedly according to M flag value of

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

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 3 Jan 2008 14:24:05 -0500

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.

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

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.

Thomas