Re: [16NG] Re: multicast and IPv6 over ETHCS

gabriel montenegro wrote:
> Alex,
> 
> The statement below is not true:
> 
> I meant links with link-layer headers.
> 
> Reading ND it says "node MUST join" before receiving an RA.  'Join' 
> can happen only if that link is multicast-capable.
> 
> 802.15.4 (a link with link-layer header) has no multicast capability 
> (only broadcast) at the link layer. Yet IPv6 can work fine.

Gabriel, on one hand I completely agree that IPv6 can work in practice
on a wide variety of links.

On another hand - ND - may be different.  Its section 6.3.3 Interface
Initialization says:
> The host joins the all-nodes multicast address on all multicast- 
> capable interfaces.

If 802.15.4 interface is attached to a router the same rfc2461 uses the
stronger MUST, section 6.2.2 rfc2461 Becoming an Advertising Interface:
> A router MUST join the all-routers multicast address on an 
> advertising interface.  Routers respond to Router Solicitations sent 
> to the all-routers address and verify the consistency of Router 
> Advertisements sent by neighboring routers.

So depending on how that reads the 'join' word, and how one interprets
IPv6 _can_ run on a specific link (does IPv6 include ND?) one can make
different conclusions.

> Of course, if one wants to optimize, one can do several things (e.g.,
>  controlled flooding, sending along a spanning tree, etc), but 
> neither is this required nor does the link layer have any concept of 
> multicast.
> 
> Wouldn't it be enough to simply say that multicast address mapping is
>  done per http://tools.ietf.org/html/rfc2464?

Yes RFC2464.  And as per RFC4291 (IPv6 Addressing Arch) and as per
RFC3810 (MLDv2) and as per RFC4489 (method for link-scope IPv6 multicast
addresses).  The four RFCs contain different IPv6 link-local multicast
addresses that an implementation should do.  These specs are disjoint
(for example only MLDv2 requires joining ff02::16 and only 4291
describes the solicited-node mapping).  Ie it's not sufficient to refer
to only one spec.

Out of these 4 essential RFCs for IPv6 link-local multicast currently
the draft cites only 2464.

I think if we want to be in alignment with how IPv6 specs we should also
think the IPv6 Scoped Address Architecture RFC4007, which defines the
scopes for link-local multicast.  Ie IP-over-ETHCS should specify the
extent of the link-local scope and zone.  Currently IPv6-over-ETHCS
doesn't talk about this.

And we should also probably think anycast.  Several anycast aspects are
mandatory for IPv6.  Off of the top of my head I can think of the
reserved subnet anycast address and the Home-Agents anycast address as
of RFC2526.  Currently IPv6-over-ETHCS doesn't talk about this.

> Should be obvious, but perhaps this is worth noting?

All the RFCs above are Standards Track.  I see lots of value of at
least referring to them.  I also see value in shortly describing what
their recommendations are and how or why IPv6-over-ETHCS should follow
them or tresspass them.

I do not recommend being silent about those RFCs.

> Because this is so, regular IP-level join protocols work fine (e.g.,
>  MLD), no need to say more. You also mention elsewhere that a 
> link-level "join" for multicast is necessary. This is not so.

2461 says a host joins and a router MUST join.

This apparent discrepancy between your oppinion and mine is probably to
be solved by suggesting that the 'join' action can happen by either
sending a MLD REPORT or by setting up a local filtering rule or by
sending a link-layer multicast-intent or multicast-dest message.  Do you
agree with this interpretation?  Do you agree this is complete
interpretation of that 'join' word and no other way can happen a 'join'?

> Notice that if a link layer simply floods all multicast packets 
> (essentially using broadcast), things work fine. The IP layer itself 
> will do the filtering.

Yes, but in that case we must specify that the IP layer must receive all
packets addressed to the 'flooding' address, which is a link-layer
multicast address.  I can explain why we need to put this on paper.
Usually  flooding means send to link-layer broadcast address
ff:ff:ff:ff:ff:ff.  But that broadcast address is for IPv4 only, not for
IPv6.  IPv6 implementations don't know about that ff:ff:ff:ff:ff:ff
link-layer address.  So I agree flooding can happen, but we need to be
specific on how it happens: is it to 12-fs or to 33:33:0:0:0:1?  This
question is particularly relevant in a draft covering both IPv4 and IPv6.

> The link-layer can do filtering to avoid flooding mcast as if it were
>  bcast, but it's just an optimization.

I agree link-layer can do filtering to avoid flooding mcast, and that's
an optimization.  So we may write it as a MAY.  I called this 'local
filtering rules' in my text.

> Now, 802.1D does propose such a link-layer optimization (IGRP/GARP), 
> but probably cuz this requires support at the clients (or perhaps for
> other reasons as well), this is not actually deployed, and yet things
> work fine over ethernet. Instead, the optimization to avoid flooding
> is possible because IPv4 and IPv6 procedures are followed for joins
> (IGMP, MLD) independently of link-layer. Typically, snooping of those
> sets state at the link-layer to achieve the desired (not required)
> optimization.

Ok.  Makes sense in a certain perspective.  I agree making 'snooping' a
recommendation to make work link-layer multicast and I think I'll want
to look into 802.1q and spanning tree protocol to see whether it's worth
mentioning too.

Alex

_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng