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

From: 차현욱 <[email-masked]>
Date: Sun, 29 Jun 2008 23:42:51 +0000 (GMT)

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:[email-masked]] 
> Sent: Saturday, June 28, 2008 2:12 AM
> To: [email-masked]
> 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: [email-masked] [mailto:[email-masked]] 
> > Sent: 03 January 2008 01:52
> > To: [email-masked]
> > 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Robert Elz <[email-masked]>
Date: Mon, 30 Jun 2008 15:58:19 +0700

Date:        Sun, 29 Jun 2008 23:42:51 +0000 (GMT)
    From:        =?euc-kr?B?wvfH9r/t?= <[email-masked]>
    Message-ID:  <18976255.327701214782971649.JavaMail.weblogic@epml07>

  | However, as I see that there is no defined way to revoke client
  | invoked by RA flags

I'm not sure what you're imagining gets to be revoked here
(more below)

   and no reason for the transition of M flag from 1 to 0 not to revoke it,

Obviously there is - the example you quoted is just that.   In particular,
we want the protocol to "fail sensibly" in the presence of configuration
foulups.   Those certainly should be fixed, but they should not be messing
up the network.

For example, if one router sends a RA containing prefixes P1 P2 and P3
and another sends only P1 and P2, addresses configured using P3 are not
supposed to come and go as RAs from the two routers are observed.

I'm not sure what the issue is supposed to be here.   The M and O flags
merely advise clients of the presence of DHCPv6 servers that should
provide full (M) or Lite (O) service to the client if desired.   Nothing
can compel the client to go query the server advertised, likewise, nothing
can prevent the client attempting DHCPv6 even of both flags are clear.

As I gather it, you're trying to find some way to tell hosts that
continuing with DHCP queries is a waste of their time, and you want
to use RAs to do that.   IMO that's not the right approach.

If a host has seen M (or O) and sent a DHCPv6 DISCOVER then one of two
things will have happened.

If the flag was genuine, then a server will have replied, and the client
will be continuing with the DHCP message sequence.

If the flag was bogus, and there is no server (including the case where there
actually is one, but the server(s) refuse to acknowledge the particular client
for whatever policy reason), the client will try a few times, and eventually
either give up, or fall back to an occasional probe looking to see if the
DHCP server has appeared.   In this final state, if future RAs no longer have
M (or O) set, that is probably a good hint to the client that the probes
are not going to be useful, and it might as well stop, whereas if M (or O)
keeps being seen, then perhaps it should keep up a background level of attempts.

If the client has obtained its address via DHCP, then the DHCP (DHCPv6)
protocol rules apply, with lease lifetimes, re-validation of leases and
all that.   What RAs might be sending should be 100% irrelevant at this
point, as long as the DHCP server keeps renewing the lease (or providing
other config info) the client should keep on using it - the motivation for
beginning with the protocol is irrelevant now, the rules of the protocol
need to be followed.   If the network wants the client to stop using DHCP
info, the way to achieve that is to have the server(s) stop providing it
(to all clients, or that client in particular).

When a client fails to renew a lease, before starting the process of
acquiring a new address all over again, it might be prudent to consult the
RA flags, to see if DHCP is still (apparently) offered, but that's as
strong as I think I'd make it.

Now, exactly how any of that fits with your notion of "revokes" I'm not
sure, but I do not believe there's any need for anything more than
correct implementation of the existing specifications - beyond that we're
just into implementation quality issues, I believe.

kre