Hi Itojun, > i still don't understand why you are trying to impose additional > restriction for link-local multicast groups (maybe i'm dumb). > without MLD joins for link-local multicast groups, default routers > won't be able to know which multicast group the 3GPP node is > interested in. there's no special text available in RFC2710 for > p2p links.
First some motivation in the practical situation. The GGSN has no applications, and hence there wouldn't be a link-local video distribution from it, as an example. Furthermore, I believe IPv6 ND packets are sent to the link regardless of the state of the MLD situation on e.g. a Solicited Node address -- or perhaps I have missed some text somewhere? Hence there'd be no use of the MLD for the IPv6 routing functioanality either. Obviously, there are no switches around in these interfaces. Finally, MLD packets do consume bandwidth, particularly if they need to be sent even when there is no traffic and we are just listening e.g. on our solicited node mcast address. (I'm not exactly sure how much this bandwidth is -- perhaps someone could enlighten me? At least some initial packets have to be sent, but is there a periodic refresh as well?) But I do understand that the RFCs must be followed. However, I wonder if you Brian could say something about the background for the link-local and the Solicited Node multicast address requirements, were they done specifically to allow switches to operate or for some other reason? I also wonder about text in Section 2, which says that MLD should be on all interfaces from which an application or upper-layer protocol has requested reception of multicast packets. I wonder what "upper layer" means in this particular case...? If it means above IP then we could argue that we are following the RFC. I also wonder if the timers -- which are configurable per the RFC -- could be tuned to minimize overhead? Finally, I have a compromise proposal. I do appreciate Itojun's point some time ago that MLD even on a p2p link would allow the router to reduce traffic to the link. This is because it would know whether there are listeners or not. Perhaps in the future there will be some new parts of IPv6, or some new applications for which this would be useful, even in a 3GPP environment. However, I do wonder about the Solicited Node multicast address case. Assuming the rules about this are in the RFC for the support of switches, could we use MLD for all link-local and global addresses, except for all nodes and solicited node multicast addresses? Given that I can't find a place where ND would depend on MLD, I think this would work well. And the case is important, as all hosts would have these addresses and would have to announce them over the network otherwise. So, the proposal is to have the following text: 2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 MLD should be supported by cellular hosts. 2.9.1 MLD in 3GPP networks Within 3GPP networks, hosts are connected to their default routers (GGSN) via point-to-point links. This arrangement also precludes any network switches. Consequently, hosts cannot communicate directly with each other using link-local addresses. Furthermore, none of the entities along the link will be doing any address-based switching, and all messages sent to the point-to-point link normally arrive to the other end. As Neighbor Discovery operates without relying on MLD, joining on solicited node and all nodes multicast addresses is not required. However, MLD is required for all other multicast addresses in all scopes. Jari -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
