Re: Re: Operational problem caused by inconsistent RA M and O flags
차현욱 <hyunwook.cha <at> samsung.com>
2008-01-03 07:43:12 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<john_brzozowski <at> cable.comcast.com>
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, "차현욱" <hyunwook.cha <at> samsung.com> 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
> dhcwg <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
=========================================
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:john_brzozowski <at> cable.comcast.com
m) 609-377-6594
p) 856-324-2671
=========================================
_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
RSS Feed