Subject: RE: [rfc2462bis] whether we need the M/O flags

From: [email-masked]
Date: Thu, 15 Apr 2004 16:14:57 +0300

Hi all,

>  > As I just said in a separate message, one big question had been raised
>  > about rfc2462bis.  It was, in my understanding, 
> 
> => The question you raise affects 2461 and as a consequence it affects 2462.
> FWIW, I really think that there is no point in going round and round again
> in this discussion when there is no harm done by keeping them. 
> Removing them is not backward compatible for 2461 anyway. 
> So I recommend we leave them as defined.

I agree with Hesham.  Unless they are doing harm, I don't think they should be removed
& create compatability problems.

John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 16 Apr 2004 00:18:28 -0400

> I think that deprecating the O & M bits will be good.
 > I'm not too worried about incompatibility, as most code
 > do not support those bits anyway. 

=> I'm sorry, "most" is not good enough. If there is one implementation
that supports it then we have _no_ right to do this. This is not the
intention
of the revision. We don't know what every implementation does and we
can't just keep playing around with specs forever.

 > In terms of harm, I think leaving O & M is harmful, as it keeps 
 > confusing people.

=> Instead of removing them and writing another BCP, I have an alternative:
isn't it easier to clarify the confusion in the text? this is already done in
2461bis.

If we don't start taking IPv6 DSs seriously no one else will.

Hesham

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is 
strictly prohibited.  If you are not the intended recipient please contact
the sender and delete all copies.
========================================================

---

From: [email-masked]
Date: Fri, 23 Apr 2004 18:51:44 +0300

Hi Jinmei,

> Now let's think about cons of deprecating these flags.
> 
> The obvious one is that this action may break existing
> implementations.  In fact, this is the most typical objection I've
> seen in this thread.

I'd like to withdraw my original objection to this.  I had a chance
to discuss with the guys who implemented some IPv6 stacks
internally & deprecating the flags won't break the implementations.

John

---

From: "Soliman Hesham" <[email-masked]>
Date: Sat, 24 Apr 2004 01:36:29 -0400

As a general comment, IMHO we're wasting cycles on this
discussion and I agree with Iljitsch's email on this. 
Specific comments below

 > Some people commented that we needed to clarify what's bad with the
 > M/O flags if we want to deprecate (or remove) them.  That's a fair
 > comment.  My points are as follows (some of which have already been
 > shown in the thread):
 > 
 > - the lack of interoperable implementation (or the fact that 
 > there are
 >   very few implementations) regarding the flags, at the host side
 >   particularly, will probably be a barrier to recycle the document as
 >   a DS.  From my honest impression on Section 4.1.2 of RFC2026, even
 >   2462 should have not become a DS document.  I've still not 
 > heard why
 >   they could make it at that time, so I know I may be wrong.

=> FWIW this is a valid point but not against the M/O flags. This is 
a point of discussion about the process. It _is_ a DS now. We can
discuss whether that's a mistake if we want to make it a PS. 
I'm not sure what this achieves though.

 > 
 > - each flag can only convey information of a single-bit, causing
 >   several problems:
 >   + we'd need to specify a single protocol corresponding to each flag
 >     in order to avoid combination mess and interoperability problems.
 >     For the M flag, it's probably okay, because we seem to 
 > have agreed
 >     on the protocol is DHCPv6 (RFC3315).  For the O flag, 
 > however, I'm
 >     not sure if the situation is mature enough.  Stateless DHCPv6
 >     (RFC3736) is likely to be a candidate (and I'd personally take
 >     it), but can we really agree on it?  Aren't there other
 >     possibilities?  For example, the full DHCPv6 protocol (RFC3315)
 >     can also work as the protocol for the O flag.  Others may want to
 >     propose non DHCPv6 protocols like SLP...then, are we really sure
 >     we won't want to introduce flexibility by a separate mechanism
 >     allowing a particular protocol?

=> Sure there are other possibilites, but there is also plenty of 
space for new options. So if there is a need for more space to
indicate which protocols should be used and at some point in future
there are no more flags, then a new option will do.

 > 
 >   + there is no way to turn off the use of "stateful" protocols.
 >     (Note that changing the flag from set to clear does not mean
 >      turning off the protocol)

=> How does this argue for removing the flags though? What would be 
the new way of turning off "stateful" that cannot be done today with
the flags?

 > 
 >   + if we adopt stateless DHCPv6 as the protocol for the O 
 > flag, we'll
 >     need a separate trick to handle renumbering events, e.g., as
 >     proposed in draft-vijay-ipv6-icmp-refresh-otherconf-00.txt.  Of
 >     course, we'd probably be able to separate this as a future
 >     extension, but then why can't we reconsider the purpose of the O
 >     flag from the beginning?  (If you're going to say "because it
 >     will break existing work", please see below first).

=> I don't understand how this is a "+". But anyway, it's not a big issue.

 > To discuss this point precisely, I'd fist like to talk about the host
 > side.  That is, implementations that
 > 
 >   A. invoke some "stateful" protocol on the reception of an 
 > RA with the
 >      M flag being set
 >   B. invoke some "stateful" protocol on the reception of an 
 > RA with the
 >      O flag being set
 > 
 > As far as I know, there is no type-A implementation.  And, 
 > as far as I
 > know, there are only two type-B implementations: Cisco's host
 > implementation, and the one implemented by KAME (that I 
 > myself wrote):
 > both of them (can) invoke an RFC3736 client in this case.
 > 
 > I don't know how Cisco would feel if the O flag were deprecated.
 > Perhaps Ralph can comment on it.  If they strongly want to keep this
 > flag, of course it will be a strong reason to do so.
 > 
 > Regarding KAME's implementation, at least the implementor (myself) is
 > okay to deprecate the flags.  Also, it's just an experimental
 > implementation to identify issues, so this feature (invoking an
 > RFC3736 client) is disabled by default in the implementation and is
 > not officially released in the BSD community.  In fact, I'm 
 > tempted to
 > deprecate the flags based on my experiments with the implementation,
 > identifying the issues described above.
 > 
 > Of course, as someone said in the thread, this does not mean 
 > there are
 > no implementors who have an implementation that would be broken by
 > deprecating the flags and thus would complain about it.  However, I'd
 > respectfully say this argument is unfair, considering the scale of
 > this mailing list and the number of participants in this particular
 > thread.  Actually, (at least) 7 people from different organizations
 > have commented, and none of them could show concrete examples except
 > the above two.  In general, it is hard to prove the non-existence of
 > something, and I think it's almost impossible in this kind of topic
 > (you could always say "someone in an isolated island only with
 > computers and RFCs might have implemented this feature" - no one can
 > refute this argument).

=> A final comment on the above text and the whole issue:
First of all, since the point of "existing implementations" has been raised
several times, I think the onus is on people who want to remove this
feature to do a survey of all existing implementations and prove that 
nothing will be affected. Of course it's very hard to do that but how else
do we make sure that we're not stuffing people around ? Is it enough
to note that Cisco and KAME are happy to remove it? I don't think so.
There are many other router, host, and embedded systems vendors
that have their own implementations and I haven't heard anything 
from them about this.  

Second, given the above discussion, what is the bottom line, concrete 
reason for doing this? It seems to me like "it's cleaner" or "it's better
this way". I can think of many more significant improvements to both
RFCs, for example due to MIPv6 that the WG didn't want to solve because
it was "too much" or "out of scope for this update". Given that, if we try
to use the same standards, then these changes are not needed and are
definitely out of scope for this update.  

Hesham

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 26 Apr 2004 09:29:51 -0700

> Baseline is, it would be good to postpone the deprecation discussion and
> at the same time update the definition of the use of the M/O bits. I can
> think of scenarios where M/O is useful but the mental picture of these
> is not clear enough yet to really make a point. Deciding upon
> deprecation or not would be premature at this point of time, IMHO.

I am sorry, but I draw the opposite conclusion. The progression along the standard track is supposed to reflect implementation experience (DS) and wide interoperability (IS). As you mention in your mail, implementers have barely started implementing the M/O bit, if at all. As such, the M/O part of the spec does not have the level of maturity required for a full standard, and just does not belong in 2462bis. 

The proper procedure would be to remove it from 2642bis, and to progress it if needed in a separate effort.

-- Christian Huitema

---

From: "Soliman Hesham" <[email-masked]>
Date: Mon, 26 Apr 2004 21:54:32 -0400

Alain

Your point about security is valid but is relevant to securing RAs
in general, and is not specific to the M/O bits. If you want to be sure
they're 
secure just use SEND. 

Hesham

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On 
 > Behalf Of Alain Durand
 > Sent: Monday, April 26, 2004 1:14 PM
 > To: IETF IPv6 Mailing List; JINMEI Tatuya / ????
 > Subject: Re: [rfc2462bis] whether we need the M/O flags
 > 
 > 
 > Let me try to explain why I, as an implementor, do not like the M/O 
 > bits very much.
 > 
 > It is not that DHCPv6 cannot be made secure, it is that the 
 > M/O bits are
 > an automatic and insecure way to trigger an external configuration 
 > mechanism.
 > 
 > The are security implication for the hosts in implementing 
 > those bits.
 > They are received in RA, which are mostly insecure (anyone 
 > can send a 
 > "valid" RA)
 > The current text says a host should turn stateful autoconf when 
 > receiving those bits.
 > So one could mount an attack fairly easily by introducing a 
 > rogue DHCPv6
 > server on a network that had no DHCPv6 so far and send a fake RA with
 > the M/O bits on. The host will then configure itself using 
 > data coming
 > from the new rogue DHCPv6 server.
 > 
 > 2462 says "host should invoke the stateful address autoconfiguration 
 > protocol"
 > and not "MUST invoke", so there are already provision for not obeying
 > the M/O bits. But if those bits are not mandatory to 
 > execute, why are 
 > they here in
 > the first place? To give a hint that DHCPv6 is present?
 > Host should not blindly believe this unless the RA are secured.
 > Also, there are no such bits in IPv4, and host implementations that 
 > chose to turn
 > DHCPv4 on simply try it. Why is is not good for IPv6?
 > 
 > 	- Alain.
 > 
 >