>>>>> On Thu, 30 Nov 2006 23:09:10 +1100,
>>>>> "Hesham Soliman" <[EMAIL PROTECTED]> said:
>> > The set of addresses assigned to an interface may change over time.
>> > New addresses might be added and old addresses might be removed
>> > [ADDRCONF]. In such cases the node MUST join and leave the
>> > solicited-node multicast address corresponding to the new and old
>> > addresses, respectively. Joining the solicited-node multicast
>> address
>> > SHOULD be done using the Multicast Listener Discovery [MLD] or
>> > [MLDv2] protocols. Note that multiple unicast addresses may map into
>> > the same solicited-node multicast address; a node MUST NOT leave the
>> > solicited-node multicast group until all assigned addresses
>> > corresponding to that multicast address have been removed.
>>
>> Hmm. should we point to MLD v1 at all? And doesn't the SHOULD make
>> this a normative reference?
> => Yes to both questions I think. If we didn't point to MLDv1 then the
> change woulod not be backward compatible. I.e. using MLDv2 only would break
> old implementations. As for the second question, I agree that it makes MLDv2
> normative but I was hoping the "or" would get us out of this dilemma.
I suspect the main issue is that [MLD] (RFC2710) and MLDv2 (RFC3810)
are both in the PS status and normative reference(s) to these would
cause a downref issue. In this sense "or" doesn't help.
Meanwhile. If I remember correctly, this sentence was added due to a
claim from someone who argued it is not clear that joining a multicast
group normally involves MLD (whether it's v1 or v2) operations. To me
it's too trivial and mentioning it in this context is superfluous.
It's here probably because including it was a consensus at that time,
but now that it's going to be a blocking issue, I'd like to ask for a
reconsider. Do we really need to mention this "trivial (to me)" thing
here?
Even if we do, I doubt the reference should be normative. According
to RFC3967, a rough definition of a normative reference is as follows:
Broadly speaking, a normative reference specifies a document that
must be read to fully understand or implement the subject matter in
the new RFC, or whose contents are effectively part of the new RFC,
as its omission would leave the new RFC incompletely specified.
If I'm allowed to talk about a particular implementation, I'd be able
to implement the relevant part of RFC2461 (or 2461bis) without reading
[MLD] or [MLDv2] on the KAME/BSD stack. In fact, this implementation
provides a routine named in6_joingroup(), and I'd simply call this
function from a routine that configures a new address. This is a
straightforward implementation of "the node MUST join (and leave) the
solicited-node multicast address", and I don't care whether
in6_joingroup() internally performs MLDv1 or v2 operation (it does
actually).
I'm not arguing this can be generalized for other implementors, but at
the same time I believe this is essentially applicable to many other
implementations because joining/leaving a multicast group is a very
common operation.
So, my suggestion to this issue is (in the preferred order):
1. remove the sentence mentioning MLD, or
2. change the sentence to
Joining the solicited-node multicast address is done using the
Multicast Listener Discovery [MLD] or [MLDv2] protocols.
(and leave [MLD] and [MLDv2] informative)
Note: there is another occurrence of references to [MLD] and [MLDv2]
in Section 7.2.8, which should also be updated.
> IPv6 node reqirements provides more
>> guidance on when to use MLD vs. MLDv2. should we include similar text?
>> Is there some other standards track document to refer to? Or should we
>> just provide a pointer to node requirements, even though it is only an
>> informational RFC?
> => All good questions, does anyone have a suggestion here? I can't think of
> one yet. I'm also not sure if we need to give recommendations for MLDv1 Vs
> v2 if there is another document that does that in a generic manner (i.e. not
> specific to this doc).
If we choose option 1 above, this problem will automagically go away:-)
If we still need to mention the MLD protocols, I don't think we need
to discuss the preference between MLDv1 and MLDv2 in this context.
One possible wording trick is to change the above option to further:
Joining the solicited-node multicast address is done using a
Multicast Listener Discovery protocol such as [MLDv2].
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
