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

From: gabriel montenegro <[email-masked]>
Date: Wed, 17 Jan 2007 15:37:14 -0800 (PST)

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. 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?

Should be obvious, but perhaps this is worth noting? 

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

-gabriel

----- Original Message ----
From: Alexandru Petrescu <[email-masked]>

_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: "Jihoon Lee" <[email-masked]>
Date: Thu, 18 Jan 2007 09:06:05 +0900

Gabriel,

> Notice that if a link layer simply floods
> all multicast packets (essentially  using
> broadcast), things work fine.

Let's focus on the main issue. As I know, we started to discuss this
problem, because of the lack of flooding function (surely including
multicast) between MSs (uplink) in 802.16 MAC layer. So, we're trying to
discuss this problem regarding IPv6overETHCS.

Best regards,
Jihoon

2007/1/18, gabriel montenegro <[email-masked]>:
> if one wants to optimize, one can do several things ( e.g., controlled
> From: Alexandru Petrescu < [email-masked]>
>
>
>
>
>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jan 2007 12:22:51 +0100

gabriel montenegro wrote:
> Reading ND it says "node MUST join" before receiving an RA.  'Join' 
> can happen only if that link is multicast-capable.
> 
> (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.

>  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.

> 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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jan 2007 12:24:58 +0100

Jihoon Lee wrote:
>> (essentially  using broadcast), things work fine.
> 
> multicast) between MSs (uplink) in 802.16 MAC layer. So, we're trying
> to discuss this problem regarding IPv6overETHCS.

I think for IPv6, 'flooding' means sending to the link-layer multicast
address 33:33::1.  Do you agree?  Do you think there's another
link-layer multicast address that does this flooding?

Alex

---

From: "Jihoon Lee" <[email-masked]>
Date: Fri, 19 Jan 2007 00:16:24 +0900

Hi Alex,

My comments inline.

Best regards,
Jihoon

2007/1/18, Alexandru Petrescu <[email-masked] >:
> address 33:33::1.  Do you agree?

Yes, I do.

> Do you think there's another link-layer multicast address that does this
> flooding?

No, I don't

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Jan 2007 17:31:09 +0100

Hi Jihoon,

Jihoon Lee wrote:
> 
> Hi Alex,
> 
> My comments inline.
> 
> Best regards, Jihoon
> 
> 2007/1/18, Alexandru Petrescu <[email-masked] 
> <mailto:[email-masked]> >:
> 
> Jihoon Lee wrote:
>> Gabriel,
>> 
>> Let's focus on the main issue. As I know, we started to discuss 
>> this problem, because of the lack of flooding function (surely 
>> including multicast) between MSs (uplink) in 802.16 MAC layer. So, 
>> we're trying to discuss this problem regarding IPv6overETHCS.
> 
> I think for IPv6, 'flooding' means sending to the link-layer 
> multicast address 33:33::1.  Do you agree?
> 
> 
> Yes, I do.
> 
> 
> Do you think there's another link-layer multicast address that does 
> this flooding?
> 
> 
> No, I don't

I think thus we can define *IPv6 flooding* as being IPv6 packets sent
over ETHCS (or over the bridge 'device' in the system deploying the
ETHCS for transmitting Ethernet frames over IEEE802.16), and addressed
to the link-layer address 33:33:0:0:0:1.

More specifically, we can define it as being packets addressed to any
link-layer address prefixed by 33:33 (see the post-scriptum why).

I think we have that definition ok.  I think we need to identify what
are the means to avoid flooding.

Otherwise, you seem to say we need to discuss the problem of lack of
flooding function in 802.16.  What do you mean?

Alex

PS: many other link-layer link-local addresses are candidates of being
flooded.

There may be questions about whether 33:33:0:0:0:2 (not 1) can be target
of an IPv6 multicast link-local flood.

The way to build a link-layer multicast address from an IPv6 multicast
address is specified in rfc2464 sec 7.  If the IPv6 link-local multicast
address is ff02::1 then the link-layer multicast address is
33:33:0:0:0:1.  RFC4291 (addr arch) says that there can be several IPv6
multicast addresses interface-local or link-local: ff01::1 and ff02::1
(all-nodes); and ff01::2 and ff02::2 (all-routers).

Thus one is tempted to think packets sent 33:33:0:0:0:2 (not 1) -
all-routers -  is a potential target for flooding too.

Correspondingly, if we use MLDv2, then floods can happen to 33:33::16
(:16 !) too, flooding all MLDv2-capable nodes.

Floods could happen to 33:33:ff:xx:xx:xx too, the solicited-node address.

Floods could happen to 33:33::1:1 too (flood all NTP servers, relevant
if IEEE 802.16 decides to use NTP in the future, instead of current TIME).

Floods could happen to 33:33::1:2 (all-dhcp-relays-servers) and to
33:33::1:3 (all-dhcp-servers), too.

http://www.iana.org/assignments/ipv6-multicast-addresses lists all
multicast addresses out of which one could derive 33:33 multicast
addresses potential targets for flooding.  One could find some orthodox
protocols such as DVMRP, OSPF or other less orthodox names such as ST,
UPnP or Mobile-Agents.

This would reduce our definition of flooding as being addressed to
33:33::1 link-layer address to wider definition of flooding being
packets addressed to _any_ link-layer address prefixed by 33:33.

---

From: "Jihoon Lee" <[email-masked]>
Date: Fri, 19 Jan 2007 09:43:28 +0900

Hi Alex,

> link-layer address prefixed by 33:33 (see the post-scriptum why).

Sure. I agree. To support IPv6 transparently over ETHCS over 802.16,
multicasting
(or broadcasting) packets in both directions of which MAC addresses are
33:33:x:x:x:x is sufficient.

> I think we need to identify what are the means to avoid flooding.

I'm sorry, I don't know what you're referring to. Anyway, I presume that you
mean that flooding (i.e., broadcast) is inefficient in terms of bandwidth
usage comparing to multicast. Am I correct?

As Gabriel said before, it's about efficiency. IMHO, supporting either
multicast or broadcast (just flood 33:33:x:x:x:x packets)  should be fine.

> flooding function in 802.16.  What do you mean?

I just pointed out there was no uplink broadcast as well as multicast in
802.16 PMP(point-to-multipoint) mode.

Best regards,
Brandon

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 19 Jan 2007 12:33:59 +0100

Jihoon Lee wrote:
> Hi Alex,
> 
>> More specifically, we can define it as being packets addressed to 
>> any link-layer address prefixed by 33:33 (see the post-scriptum 
>> why).
> 
> multicasting (or broadcasting) packets in both directions of which 
> MAC addresses are 33:33:x:x:x:x is sufficient.

Let's focus on the flooding problem, not solution.

> I'm sorry, I don't know what you're referring to. Anyway, I presume 
> that you mean that flooding (i.e., broadcast) is inefficient in terms
>  of bandwidth usage comparing to multicast. Am I correct?

Ok, flooding is not broadcast.

Up to now we agreed flooding is sending to 33:33-prefixed packets.
Broadcast is sending to ff:ff:ff:ff:ff:ff address.  It's completely
different.

> As Gabriel said before, it's about efficiency. IMHO, supporting 
> either multicast or broadcast (just flood 33:33:x:x:x:x packets) 
> should be fine.

Ok, I must say I disagree.  I completely respect Chair indications with
respect to administrative, but I think that oppinion was expressed as a
technical oppinion, not as Chair, so anyone can disagree with it.

It is a very strong goal, and much more than qualifying as 'efficient or
less efficient', to not deliver the IPv6 multicast packet to a stack
that hasn't indicated willingness to participate into that multicast
group.  Or, to deliver a multicast packet only to a stack that has
expressed interest in it.  This is a requirement, as I see it.  What do
you think?

I can mention a scenario where this flooding can become a tsunami: if
one doesn't use link-layer filtering rules, or MLD, then an attacker can
send a packet to a 33:33 address and falsely put 33:33 in its src
address.  At which point everybody will respond to everybody, and more
everybody to everybody, etc.  A broadcasted NS is but an example.

Oftentimes this behaviour that I called 'tsunami' people call actually
'flooding'.  So our flooding problem would be so too.

What do you think about 'IPv6 flooding' not being ff:ff.. but '33:33',
and about the necessity to not deliver a multicast IPv6 packet to an
IPv6 stack that hasn't expressed interest in it?  Is this necessary in
your view?

Alex

---

From: "Jihoon Lee" <[email-masked]>
Date: Sat, 20 Jan 2007 03:15:32 +0900

Hi Alex,

> IPv6 stack that hasn't expressed interest in it?  Is this necessary in

I thought it over. Ok, I think we don't have to allow flooding (though you
think the flooding MUST NOT be allowed).

>From now on, Iet's focus on the multicast which avoids flooding.

Thanks,
Jihoon