Subject: Re: [dhcwg] Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"

From: HYUN WOOK CHA <[email-masked]>
Date: Thu, 18 Sep 2008 10:14:05 +0000 (GMT)

Hello, Thomas.

Thank you for your clarifications. 
Please see my comments below.

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]] 
> Sent: Thursday, September 18, 2008 12:18 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Request for Advices on the draft 
> "draft-cha-ipv6-ra-mo-00.txt"
> 
> HYUN WOOK CHA <[email-masked]> writes:
> 
> > Hello, Thomas Narten and 6MAN folks.
> 
> > I made a presentation for our draft "draft-cha-ipv6-ra-mo-00.txt" at
> > the 6MAN session in Dublin IETF. This draft aims to clarify the
> > handling of the M/O flags of IPv6 RA. Though I got several comments
> > during my presentation, I could not figure out what you really
> > pointed out. So, I decided to ask you again why you think that the
> > issues which the draft addresses are neither clear nor considered as
> > worthy to be discussed in the 6MAN wg.
> 
> Meta point. This WG has (multiple times) over the last few years had
> discussions about what the best semantics for the M&O bits should
> be. Despite hundreds of emails, and multiple drafts, there was not
> (and still is not) consensus on what the exact semantics should be.
> 
> If you look at the history, RFC 2462 had text about the M&O bits. It
> basically said that if the M or O bit was set, a client should invoke
> DHC. Note: the wording was "should" not "must". When 2462 was reissued
> as RFC4862, all the wording about the M&O bits was removed. The change
> section says:
> 
>    o  Removed the text regarding the M and O flags, considering the
>       maturity of implementations and operational experiences.
>       ManagedFlag and OtherConfigFlag were removed accordingly.  (Note
>       that this change does not mean the use of these flags is
>       deprecated.)
> 
> This was done because the WG could not agree on alternative wording on
> how to define the M&O bits.
> 
> Thus, my main comment at the microphone was that unless something  has
> changed (and I have seen no indication of this), the WG should not
> take on this topic or discuss it further because there is no consensus
> to make any changes.
>   

Although alternatives are possible as existing drafts proposed, my concern is focused on the invocation of DHCPv6 clients through RA flags, which is specified in the RFC2462 and have been supported widely by existing implementations and conformance test tools such as TAHI. As an implementor, I wrote a draft to clarify the issues which I observed.  

> > First of all, I would like to give a brief summary for the draft.
> 
> > Existing specification (RFC2462) does not give a method on how to
> > revoke DHCPv6 clients once they were invoked by the M or O flags of
> > RA messages.
> 
> Personally, I do not believe this is wrong or a problem. IMO, it is
> just fine that there is no way to revoke an earlier hint that DHC is
> available and clients should use it. (DHC has its own ways for dealing
> with unresponsive servers -- clients will retransmit at a very low
> rate, in such a way that such retransmissions do not cause operational
> problems.)
> 

Perhaps this point might be a major conflict. As we both know, consecutive DHCPv6 SOLICIT messages are sent exponentially back-offed if no valid replies are received within timeouts. Since this always holds, I would like to ask you why M/O flags should not be deprecated. 
IMO, revocation of DHCPv6 clients has also benefits if invocation of DHCPv6 clients should be guided by RA flags. 

> > Let us think about the case that a administrator wants to change
> > network policy from stateful addressing via DHCPv6 to stateless
> > one.
> 
> It can do so by simply starting to send out RAs with the relevant
> information. There is no need to disable DHC in order to switch to
> stateless configuration. (It would of course be foolish for the
> information sent out via RAs to conflict with the DHC advertised
> information.)
> 
> > Although the admin clears M flag of RA messages and reconfigure(or
> > shutdown) the DHCPv6 server, the DHCPv6 clients keep operating. Even
> > after all bindings expire and stateful addresses are invalidated,
> > the client will keep searching another stateful servers by sending
> > SOLICITs, because the DHCPv6 protocol does not care about values of
> > RA flags.
> 
> As stated before, I do not consider this to be a problem.
> 
> > If the intention of the restriction that DHCPv6 clients should be
> > invoked at the transition from FALSE to TRUE of the M or O flag of
> > RA is that waste of resources of network infrastructure and host
> > devices caused by useless DHCPv6 operation can be prevented and
> > stateful addresses can be configured automatically by the
> > administrative policy, we believe that our draft has value to
> > supplement missing parts which existing specification and
> > implementations have.
> 
> Note: there is not WG consensus that if the M/O bits are cleared that
> one MUST NOT invoke DHC. Routers could be misconfigured and leave the
> bits cleared, even though DHC is to be used. Or there may not even be
> a router on the link! Thus, some persons argue that they want the
> freedom to ignore the M&O bits and invoke DHC anyway. That said,
> others (just as strongly) feel that a client MUST NOT invoke DHC if
> the M/O bits are cleared.  This is a point on which the WG simply does
> not have consensus. I do not believe anything has changed in the WG to
> suggest that the WG could reach agreement now, if it were to reopen
> discussion on the matter.
>     
> > The second issue (which is likely less important) is concering
> > conflicts M/O flags from different routers which belongs to differnt
> > administrative domains.
> 
> This type of environment is problematical and there are no good
> solutions. If two routers are sending out conflicting information
> (intentionally), there is little a client can do to "make things
> right".
> 
> > Existing IPv6 stack implementations such as linux are assumed to
> > comply with handling of the M/O flags of RA in the RFC2462. So, they
> > just keep the most recent M/O values without considering senders of
> > RA messages.
> 
> In this type of environment, you would presumably want clients to
> continue using DHC even if an RA was received with the M&O bits
> cleared. That is precisely the behavior that is defined/implemented
> today per existing RFCs.
> 
> Your proposal would differ and (from what I can tell) cause DHC to be
> enabled/disabled/enabled/disabled/etc/ over and over again. This seems
> like a bad solution in this case.
> 

This is not true. Please refer to the section 4 in our draft.

4.  An Algorithm for the Management of Internal State Variables

   We introduce an algorithm for the management of the internal state
   variables as follows.  In this algorithm, two timers (M-timer and
   O-timer) are used, lifetimes of which is chosen to be 3 times of
   MaxRtrAdvInterval in [RFC4861].  When an RA is received that has the
   M flag set, ManagedFlag is set to TRUE and the M-timer is started or
   restarted.  When an RA is received that has the O flag set, the
   OtherConfigFlag is set to TRUE and O-timer is strarted or restarted.
   If the M-timer goes off, the ManagedFlag is set to FALSE.  If the
   O-timer goes off, OtherConfigFlag is set to FALSE.  Thus, once
   ManagedFlag or OtherConfigFlag is set to TRUE, it can only be changed
   into FALSE after no RA is received with the bit set within lifetime
   of timers.  Thus, state variables can be managed consistently even
   when a host is connected to multiple routers sending conflicting RA
   messages, because the RA messages with the bit set will overrule the
   ones with the bit clear.

> > This point does not expose serious problems though it does not
> > provide consistent informations about the availability of the DHCPv6
> > service. Since we would like to support revocation of DHCPv6 clients
> > at the transition of M or O flag from TURE to FALSE, the handling of
> > the flags is reworked in our draft to avoid the iteration of
> > invoking and revoking of the clients.
> 
> I do not agree with your problem statement that  there is a need to
> revoke DHC.
> 
> IMO, the WG should first discuss the actual problem statement. That
> is, discuss what exactly is broken that needs to be fixed. Only if
> there is agreement that we have a problem that needs fixing should the
> WG revisit this topic.
> 
> Thomas
> 

If you can not agree with our problem statement, I just hope that you have only the reasons mentioned above.

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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 18 Sep 2008 09:01:09 -0400

HYUN WOOK CHA <[email-masked]> writes:

> Perhaps this point might be a major conflict. As we both know,
> consecutive DHCPv6 SOLICIT messages are sent exponentially
> back-offed if no valid replies are received within timeouts. Since
> this always holds, I would like to ask you why M/O flags should not
> be deprecated.

Because the WG doesn't feel that the flags were so problematic that
they needed to be deprecated? There certainly has been concern that
existing implementations that do support the M&O bits should not
become non-complient through deprecation of the M&O flags.

IMO, if we were to start over knowing what we know today, I'd be in
favor of not having the M&O bits at all. But we are not starting from
scratch...

> IMO, revocation of DHCPv6 clients has also benefits if invocation of
> DHCPv6 clients should be guided by RA flags.

On this point, I have seen little indication that the WG agrees with
you.

> This is not true. Please refer to the section 4 in our draft.

OK. Sorry for not reviewing this point in advance.

>    messages, because the RA messages with the bit set will overrule the

Sure, this would work. Though one can question whether the additional
implementation complexity is worth the benefit.

> If you can not agree with our problem statement, I just hope that
> you have only the reasons mentioned above. 

Right. I just don't see the problem as particularly significant, and I
don't believe the WG will be able to agree on changing the definition
of the M&O flags (given past discussions).

If your real concern is that DHC continues to be invoked forever (even
when no DHC servers are available), wasting network resources, IMO,
the better place to make changes is in the DHC specification. I.e.,
the DHC client should backoff more aggressively and "poll" for the
appearance of a new server very infrequently.

This would be appear to be as simple as changing the value of SOL_MAX_RT:

   Parameter     Default  Description
   -------------------------------------
   SOL_MAX_RT      120 secs  Max Solicit timeout value

See Section 17.1.2 in RFC 3315.

Thomas

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Sep 2008 09:57:40 -0700

> become non-complient through deprecation of the M&O flags.

Why would they become non-compliant?   I think it's because DHCPv6  
clients would not attempt to discover DHCPv6 servers if the managed  
bit wasn't set.  So there's an easy solution: deprecate the bits, but  
require that both the M and O bits be set in all RA messages.

> favor of not having the M&O bits at all. But we are not starting from

It's never too late.   It's simply unclear what the M&O bits do right  
now.   By leaving this lack of clarity, we practically guarantee that  
interoperability problems will arise, because the RFCs provide no  
guidance on how the implementor should deal with transitions or  
conflicts in M&O bit settings.

>> implementation complexity is worth the benefit.

Deprecating M&O would definitely be simpler.

> appearance of a new server very infrequently.

I don't know what Joseph's objections are, but my reason for being  
interested in this is that I see a potential dead zone in the protocol  
that clients can get into but can't get out of.   Because DHCP relay  
is required for a solicit to go off-network, if no DHCPv6  
infrastructure exists at a site, there will be no concentration of  
solicits on a central server, and the number of packets per second  
will be fairly small even on a crowded network.

So my reason for wanting to address the problem Joseph is talking  
about is simply that as it stands, there is no clear recommendation  
for implementors as to how to handle transitions, and I suspect that  
some implementations will wind up doing the wrong thing, because in  
fact the implementor may not even think about the problem Joseph has  
raised.

I would actually prefer your solution to Joseph's: just deprecate the  
M&O bits, and require that they be set on to prevent whatever old  
implementations are already deployed from failing to attempt DHCPv6.

But if the IPv6 WG does have consensus that DHCPv6 should not happen  
if the M bit isn't set, and that DHCPv6-lite shouldn't happen if the O  
bit isn't set, then I think something is needed to address the concern  
that Joseph has identified.   And if the IPv6 WG cannot reach  
consensus on this point, I don't think that's a reason to leave things  
as they are, because things are broken as they are.

The main reason, I think, that the DHCPv6 WG doesn't have a consensus  
on this is that the RFC that's supposed to address this problem is not  
a DHC RFC.

>   Parameter     Default  Description

This would make DHCPv6 recover very slowly from a server outage, and I  
don't think it's necessary - 120 seconds is a pretty long time.   If  
you have 200 clients on a link, that's fewer than 2 solicits per  
second.   However, I am definitely sympathetic to those who would  
prefer not to see these solicits at all.