[2462bis issue 596] definition of "multicast-capable"

[JINMEI Tatuya / $B?@L@x#:H(B <jinmei@xxxxxxxxxxxxxxxxxxxxx>]

(The issue is now recorded at
https://rt.psg.com/ which can be viewed with login/passwd=ietf/ietf)

>>>>> On Mon, 16 Aug 2004 18:43:04 +0100, 
>>>>> "Elwyn Davies" <elwynd@nortelnetworks.com> said:

>> Regarding "multicast interface", I think we can simply replace it with
>> "multicast-capable interface" if you are happy with that.  Do you
>> think we need to do more on this? (e.g., do you think we need 
>> to define
>> the term "multicast-capable"?)

> Changing s.5.1 to multicast-capable is good. The problem is actually in
> 2461bis - multicast-capable should be defined there and referenced in
> 2462bis - I put in a comment on 2461bis suggesting that this needs to be
> clarified.  The problem is that the whole of the ND and RD process (and
> hence by implication Stateless autoconfig) was intended to be revisited on
> links that are not 'multicast-capable':  the understanding appears (at least
> at some stage)to have been that multicast-capable means that the underlying
> link layer support multicast natively but the term is not defined to mean
> exactly that. On the other hand, the note in 2461bis specifies that every
> IPv6 link must offer a multicast service so it should (or might) be possible
> to use this service to do all the things (such as ND) that need link local
> multicast.  2462bis needs at least some weasel words along the same lines as
> the second paragraph of the Introduction (s.1) of 2461bis to say that some
> other mechanism might be used on NBMA etc. 

Hmm, I'm not really sure if we need to do something on this in
rfc2462bis, but assuming we'll agree that multicast-capable should be
defined in rfc2461bis and rfc2461bis will do that, perhaps the easiest
and the best approach is to modify the definition of "link" in Section
2 a little bit like:

   link - a communication facility or medium over which nodes can
      communicate at the link layer, i.e., the layer immediately below
      IP.  Examples are Ethernets (simple or bridged); PPP links; X.25,
      Frame Relay, or ATM networks; and internet (or higher) layer
      "tunnels", such as tunnels over IPv4 or IPv6 itself.  The links
      on which the protocol used in this document are specified in
      [RFC2461].

(or s/[RFC2461]/[rfc2461bis]/ if and when necessary)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------