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

From: HYUN WOOK CHA <[email-masked]>
Date: Wed, 02 Jul 2008 01:23:28 +0000 (GMT)

Hello, Kre.

Please see my inline comments.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, June 30, 2008 5:58 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [dhcwg] Operational problem caused by 
> inconsistent RA M and O flags
> 
>     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.

(Joseph) Yes, I agree that this is right from the view of RFC4861, 4862. Anyway, it is an option for vendors to implement their DHCPv6 clients to be invoked by M or O flags in RA and I believe that this is the case for many implementations as old RFC(2462) specifies. Our draft is focused on this case. 

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

(Joseph) I do not think that what you are saying is same as current specification(RFC3315). According to the RFC3315, DHCPv6 clients do not care about M & O flags in received RAs. So, even after bogus RA flags are cleared, clients keep sending queries with back-off intervals. Actually our draft proposes the way you mention.  

> 
> 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.
> 
(Joseph) I agree that this is a right approach. We suggested this in our draft. 
Also, we included immediate revocation of DHCPv6 clients at a transition of M or O flag from 1 to 0 as another option because it does not cause any serious problem to allow this.

> 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
> 
(Joseph) Again, the approach you are mentioning is not specified in the current documents. In addition, one more thing that you should notice is that modification on the handling M & O flags in an RA is required if  the scenario where a client sees RAs with conflict M or O flag sent by multiple routers is considered. In our draft, we suggested new algorithm for this topic. 

Joseph

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