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

From: Thomas Narten <[email-masked]>
Date: Wed, 17 Sep 2008 11:17:36 -0400

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

> 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 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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "hyunwook cha" <[email-masked]>
Date: Fri, 19 Sep 2008 12:08:39 +0900

Thomas,
I would like to add a few comments as below.
>
> ------- Original Message -------
> Sender : Thomas Narten<[email-masked]>
> Date   : 2008-09-18 22:01 (GMT+09:00)
> Title  : Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"
>
>> 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...
>

I am not sure that M&O bits has no value. At this moment, I simply do
not want to enter long debates for this topic. According to the
RFC4861 and 4862, we have freedom to choose handling of M&O bits in
RA. Specification in the RFC 2462 may be considered as an option,
which has been implemented and practiced widely by many vendors. In
this option, we found out the issue that there is no method to revoke
DHCPv6 clients once invoked by RA M/O bits. Thus, we devised our
proposal to address the issue clearly.

>> 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.
>
>> 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.
>
> 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).
>
I agree that the issue itself is not significant. However, we believe
that the issue is a missing part which should be handled clearly so
that implementors may be guided well and our proposal can be
applicable for this.

> 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
>
>
>
I do not think that your suggestion is right approach. Why do not you
simply allow to revoke DHCPv6 clients by RA flags through which they
are invoked?

Joseph

---

From: HYUN WOOK CHA <[email-masked]>
Date: Tue, 30 Sep 2008 01:10:00 +0000 (GMT)

Hello, Ted.

That's correct. I believe that the ability to stop DHCP clients using M/O bits in RA is required once they were invoked by M/O bits in RA. 

Joseph

------- Original Message -------
Sender : Ted Lemon<[email-masked]> 
Date   : 2008-09-30 09:36 (GMT+09:00)
Title  : Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"

Joseph, to summarize, it sounds like you believe that the ability to  
stop DHCP clients broadcasting on a link is a requirement.   And you  
therefore think that deprecating the M&O bits is not the right  
answer.   Is that correct?