>>>>> On Thu, 15 Apr 2004 20:40:14 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> As I just said in a separate message, one big question had been raised
> about rfc2462bis. It was, in my understanding,
> whether we need the M/O flags for the "stateful" protocol(s) in the
> first place.
> I know this is probably highly controversial, but I tend to agree on
> removing (or deprecating) these bits.
(Note: In this message, I'm basically speaking just as an individual
in this list. I'll propose an action as a 2462bis editor after the
entire discussion; it may or may not be same as what I'm going to say
below)
(Another note: this is a long message, sorry about it. But I hope all
who are interested in this topic will read the entire message and
comment it.)
Thanks for all the input. Going through the thread so far, I've been
thinking about this issue closer...and, I personally still have the
same opinion.
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.
- 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?
+ 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)
+ 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).
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.
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).
For me, the discussion so far indicates there is actually nothing
broken by deprecating the flags in a practical sense (believe me, I'm
trying to be fair in this sentence), as long as Cisco is okay for
their host side implementation. Regarding the Cisco case, I'd like to
hear from Ralph about his opinion.
Meanwhile, please do not forget the original specification in RFC2462
was very unclear about these flags, which might break something if we
want to clarify the behavior, even keeping the flags. For example, it
even does not specify a particular protocol (at least not clearly) to
be invoked by the flags. So, what if someone has a host side
implementation that invokes a proprietary "stateful" protocol upon
receiving the M flag and claims "my implementation perfectly working
under RFC2462 will be broken if you specify DHCPv6 as the 'stateful'
protocol". Can this be a reason for not making the specification
clear on this? I hope not, and if we can agree on this point, then it
seems to me that this discussion shows that the current specification
is too unclear to worry about breaking "something" working so far with
it.
So far, I've discussed the host case. Let's move on to the router
case.
Yes, there are many router implementations that have the ability to
set the M/O flags. However, as long as we can agree on deprecating
the flags from hosts's point of view (as discussed so far), I believe
we can still deprecate the flags without breaking implementations.
In fact, setting these flags at the router has had no effects so far
in a practical sense. So, nothing in the router implementations will
be broken unless we reuse these bits for different purposes.
Now, I've dumped what I have. Hopefully I've made several things
clear. Still, I expect different opinions (actually, I still expect
objections). So, please speak up.
I'd particularly want to have a *concrete* counter example that will
be broken with the deprecation (not just "*something* that might have
been working well and will be broken"). Also, I'd really like to know
if the lack of interoperable implementation can be an issue or not.
I'm going to wear a hat of 2462bis editor, collecting opinions again,
and would like to make a concrete proposal next week based on the
result.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
