> 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.
Hesham
>
> whether we need the M/O flags for the "stateful" protocol(s) in the
> first place.
>
> (Actually, different people used different representation related to
> this issue, but, in my understanding, we can simply summarize the
> essential part of the question as above).
>
> I know this is probably highly controversial, but I tend to agree on
> removing (or deprecating) these bits.
>
> The main reasons have already been shown in the thread
> starting at the
> following URL:
> http://www1.ietf.org/mail-archive/working-groups/ipv6/current
/msg02262.html
One additional point is that I'm not sure if we can really recycle
rfc2462bis as a draft standard with keeping these bits. If we keep
them, we'll probably need to find running implementations regarding
these bits that are interoperable. (If so) can we really make it
soon? As far as I know, no host implementation supports the M flag.
Regarding the O flag, I've implemented the host side of the flag,
which invokes a DHCPv6 client upon receiving an RA with the O bit.
But I've never heard of other implementations.
This also means one obvious problem when we remove these bits is
actually a non-issue. That is, we do not have to worry about the
problem that we may make serious loss of compatibility.
Another possible disadvantage is that we'll lose the ability to
trigger DHCPv6 (or, if you like a general wording, trigger a stateful
protocol). I admit this can be a problem. A rough idea to deal with
this is to provide a different, more general way to provide the
ability as a separate document. For example, a separate ND option
which can trigger a particular protocol (including DHCPv6) for a
particular purpose (e.g., to get "additional" configuration
information) might make sense to implement the idea. In fact, an
extension to ND to re-invoke a protocol for "other information" has
already been proposed: draft-vijay-ipv6-icmp-refresh-otherconf-00.txt.
I know this is probably too radical to make a concrete proposal at
this stage, but if we can really agree on the basic idea of this path,
I'd probably do the followings in rfc2462:
- remove all references to "stateful" protocols
- deprecate the M and O flags, that is,
+ reserve the fields and clarify that they must not be used
(this may affect rfc2461bis, too)
+ remove all the usages regarding these flags
Any comments/suggestions/objections are welcome. Thanks in advance,
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
--------------------------------------------------------------------
========================================================
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.
========================================================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
