Subject: RE: a short comment on draft-okabe-ipv6-lcna-minreq-00.txt

From: Jung Cyndi-ACJ099 <[email-masked]>
Date: Sat, 17 Nov 2001 13:32:18 -0600

Jinmei,

The link-local groups in IPv4 do not use IGMP, and the IGMP snooping
switches take this into consideration, for the most part - those that don't
consider it don't work.  Those link-local addresses are things like OSPF
Hellos and RIPv2 updates. 

Are you suggesting that MLD become part of the minimum requirements 
because of as yet unavailable MLD snooping switches?  Those switches 
could check the scope of the IPv6 destination and forward all link-local 
scope multicast to all ports of the subnet - it is at a fixed offset forever
and always.  Unless we really expect heavy traffic use of link-local scope 
multicast, using this as the reason for mandating MLD as a minimum
requirement is more of an obstacle than an aid for IPv6, in my opinion.

Cyndi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 16, 2001 10:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: a short comment on draft-okabe-ipv6-lcna-minreq-00.txt

(I think the ipng ML is the best place to discuss the issue, but
please correct me if this is not appropriate.)

I've taken a quick look at draft-okabe-ipv6-lcna-minreq-00.txt and
have a short comment (or a question).

The draft says

2.3 Multicast
    Multicast is not treated in this draft, and it is the candidate for
    further study (RFC 2375[8], RFC 2710[9]). However, the multicast
    related to neighbor discovery is considered.   

So the minimum implementation must join some multicast groups for
neighbor discovery (e.g. solicited node groups).  This means the
implementation should perhaps support MLD, because there will be L2
switches that filter multicast packets unless the switches hear MLD
reports for the multicast group.  This will even be the case for
link-local groups, as in IPv4 multicasts.  Since MLD needs a
hop-by-hop router alert option, the implementation should support
the hop-by-hop options header as a consequence.

However, this draft also says

3.1.1 Hop-by-Hop Options Header
    [Sending]
    Following 3.1, minimum hosts do not send packets with this extension 
    header. 

This seems to contradict with the fact above.  I think the draft
should clarify this point.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 19 Nov 2001 21:31:34 +0900

>>>>> On Sat, 17 Nov 2001 13:32:18 -0600, 
>>>>> Jung Cyndi-ACJ099 <[email-masked]> said:

> Hellos and RIPv2 updates. 

Hmm, then I misunderstood the current situation.  I should also have
checked draft-ietf-magma-snoop-00.txt, which says:

   To avoid this situation, IGMP snooping switches should be less con-
   servative when forwarding packets to these addresses and flood them
   to all ports.
   (2.2.  IGMPv2 snooping and 224.0.0.X)

> requirement is more of an obstacle than an aid for IPv6, in my opinion.

I agree.  The previous comment of mine was simply due to my
misunderstanding about the current IGMP snooping.  I applied the wrong
analogy to the "as yet unavailable switches."  Please just forget this.

However, I have still some concern about the "future" switches.

The magma draft only mentions addresses in the form of
FF0X:0:0:0:0:0:X:X.  It does not directly talk about the link-local
multicast.  Also, RFC 2710 explicitly says MLD messages are sent for
link-local groups:

   MLD messages ARE sent for multicast addresses whose scope is 2
   (link-local), including Solicited-Node multicast addresses [ADDR-
   ARCH], except for the link-scope, all-nodes address (FF02::1).

So I'm still afraid the "future" switches might snoop and filter
link-local addresses.  We should probably clarify this on the magma
draft.

					JINMEI, Tatuya