Subject: Re: about v6 over multicast-less Ethernet

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2005 13:53:10 +0100

Greg Daley wrote:
> I think that Alex was thinking about end hosts which don't support 
> IPv6.

YEs, hosts that support v4 ok and can't support v6 because of the 33
requirement of RA (RAs must be sent to 33:33:0:0:0:1 by this RFC).
Receiving an initial RA is essential to configure the stack.  Ok, IPv6
stack configuration could be done manually, but in that case using IPv4
is more advantageous than using IPv6 because IPv4 uses DHCP
autoconfiguration.

> It is intentional though that Routers use multicast for Neighbour 
> Discovery in order to identify packet destinations, rather than rely 
> on flooding.

Good.  It's just that routers should not use multicast for ND when
multicast is not available and simply use broadcast.  It's better to use
broadcast and have things working, better than just assuming that
multicast works and have nothing working.

> Using ff:ff:ff:ff:ff:ff completely defeats this mac-layer filtering 
> (as does 33:33:33:00:00:01, since all ipv6 hosts will use this group)
> 
> 
> 
MAC-layer filtering should be used when available, but the entire IPv6
ND should not rely on its existence.  IPv6 ND should work with plain
broadcast as well.

> The only way to identify the frames to forward (without causing 
> switches to peer into L3 for every frame) is to have smaller groups 
> which will not be bridged out every port.
> 
> If we start sending multicast frames as ff:ff:ff:ff:ff:ff, we can say
>  goodbye to a scalable, long-term IPv6 over BNEP/Bluetooth and even 
> 802.11 in bridged environments.

Hold on, we're not saying goodbye to "scalable".  It's good to have
"scalable" stuff.  But it's also good to have things working instead of
not working because of scalability worries.  I think in  hotspot areas
they use all-ff DHCP DISCOVER - ok that's not scalable but that works.

> Hosts would _always_ wake up to process ff:ff:ff:ff:ff:ff frames, if
>  they were incorporated in IPv6.

I mean have the "broadcasted" RAs (not the unicasted) sent to all-ff if
33 is not possible.  I don't mean to have all ND to use all-ff.  First,
just have the RA to all-ff if 33 not available.  If ok, then maybe the
NA too.  But only the ND messages that are broadcast in nature.

> This wastes battery power for wireless hosts, as well as the 
> previously mentioned bandwidth.

ND messages that are broadcast in nature are sent to everybody under the
same hub anyways, it's going to wake everybody up anyways, it's just
that the address notation is different.

> We've got more multicast than ever in IPv6.

Good.

> In that case, there will be old cards which can't support 33:33 MAC 
> addresses.   Perhaps it is well to note that these cards won't be 
> able to run IPv6.

Ok, so that's an option.  Another is to just say that when 33 multicast
is not available for broadcast, just use ff broadcast.

Alex
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 01 Mar 2005 14:10:10 +0100

>is more advantageous than using IPv6 because IPv4 uses DHCP

Never heared of IPv6 DHCP ? :)

>multicast works and have nothing working.

If you have such old hardware why even bother upgrading it to IPv6, the
OS running on it won't support it either.

Ethernet cards go for around $15 US, why not simply swap the card when
you are going to do multicast ethernet.

As mentioned the driver of the card could solve this itself, if it
doesn't upgrade it.

>is not available for broadcast, just use ff broadcast.

Which is what various drivers already do. Most of the time when you have
a card and RA's don't work, ifconfig eth0 promisc and done.
But it is more likely better to upgrade the card as it is prone to have
more problems anyway, see above and the other messages.

Greets,
 Jeroen

---

From: "Martin Dunmore" <[email-masked]>
Date: Tue, 1 Mar 2005 13:23:27 -0000

<snip>
 
> is not available for broadcast, just use ff broadcast.

So the obvious question is... how do we know if a receiver on the link
cannot use 33 multicast? I dont know of a way for the IP stack to find this
out. But assuming that we can and do detect such a reciever then all
multicast RA/ND messages from a router would then have to use ff broadcast?

Perhaps it would be simpler just to add some text saying that Ethernet NICs
that do not support 33 multicast may not (cannot?) be able to support v6?

Regards,
Martin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Mar 2005 14:57:25 +0100

Alexandru Petrescu wrote:
...
> ND should not rely on its existence.  IPv6 ND should work with plain

It's my recollection that (8 years ago, for RFC 1972) we took
a very conscious decision *not* to do this. Many of us had been
sufficiently traumatized by IPv4 ARP storms etc. to believe
FFFF addressing should never, ever be used by IPv6. Not using
MAC-level broadcast may even have been listed as a design
requirement.

     Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2005 16:59:12 +0100

Martin Dunmore wrote:

> <snip>
> 
> 
>>> In that case, there will be old cards which can't support 33:33 
>>> MAC addresses.   Perhaps it is well to note that these cards 
>>> won't be able to run IPv6.
>> 
>> Ok, so that's an option.  Another is to just say that when 33 
>> multicast is not available for broadcast, just use ff broadcast.
> 
> 
> So the obvious question is... how do we know if a receiver on the 
> link cannot use 33 multicast? I dont know of a way for the IP stack 
> to find this out.

Right.  The problem is I don't know about about a way for the IP stack
to find out that the receiver _does_ use 33 multicast.  It simply
assumes it.  The RFC assumes it.

> But assuming that we can and do detect such a reciever then all 

No no, only the RA and NA messages that are intended to be broadcasted,
and broadcasted to the complete set of members, not just some group
address derived from a specific MAC address.

For example, RAs can be sent to either 33:33::1 or to specific MAC
addresses too.  Those that can be sent to 33:33::1 should be able to be
sent to all-ff too.  It's just a change in notation.  There is no change
in scalability or power consumption.

> Perhaps it would be simpler just to add some text saying that 
> Ethernet NICs that do not support 33 multicast may not (cannot?) be 
> able to support v6?

"cannot" is too strict.  IPv6 is a big thing.  Only a certain form of
easy stateless autoconf is not supported if the 33 multicast is not
supported.  If a non-33 host sends a RS to a pre-configured router then
that host does receive a directed RA.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Mar 2005 17:02:20 +0100

> a card and RA's don't work, ifconfig eth0 promisc and done.

I don't think 'ifconfig eth0 promisc' (provided card supports this) is a 
proper way to say that IPv6 works over Ethernet.  'promisc' simply 
nullifies all other Ethernet address processing.

If people do ifconfig eth0 promisc in order to have IPv6 working then 
this should be at least documented somewhere.

Alex

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 01 Mar 2005 17:59:12 +0100

>nullifies all other Ethernet address processing.

But it gets your multicast to work and that is the trick. Note that you
can also try 'allmulti', which on some cards/drivers is enough to get
multicast going.

>this should be at least documented somewhere.

This works for broken network cards/driver combinations.
Usually the driver was to blame as it would work on Windows(tm) ;)

In short: complain to your vendor to make it work.
Or vote with your money and get something that works out of the box.

Greets,
 Jeroen

---

From: "Martin Dunmore" <[email-masked]>
Date: Tue, 1 Mar 2005 17:13:10 -0000

> assumes it.  The RFC assumes it.

I thought the RFC specifies the use of 33:33 multicast rather than assumes
it?

> in scalability or power consumption.

Ok, this is a superfluous argument but if the router *could* detect a non
33:33 capable node on it's link it would have to either 1) send all
multicasted RA/ND messages to the all ff address (so that the non 33:33 node
can see them) or 2) unicast the multicasted RA/ND messages in duplicate to
the non 33:33 node.

> that host does receive a directed RA.

I agree "cannot" is too strong. However, the normal (according to RFC 2461)
RA response to a RS is sent to the all nodes multicast address (FF02::1 i.e.
33:33::1) rather than the specific MAC address of the soliciting node.
Although most implementations may allow you to change this to a unicast
response, I'm fairly sure the default settings will be for a multicast
response. 

Martin

---

From: Greg Daley <[email-masked]>
Date: Wed, 02 Mar 2005 10:53:39 +1100

Hi Alex,

Alexandru Petrescu wrote:
> Greg Daley wrote:
> 
>> I think that Alex was thinking about end hosts which don't support IPv6.
> 
> 

I don't even think manual configuration should be done on those devices.
They can't do the ND component properly, regardless of the Router 
Discovery component.

NS uses multicast as well, and is the basis of DAD.

> ND should not rely on its existence.  IPv6 ND should work with plain

Not plain broadcast, plain multicast.

broadcast shouldn't be used because it prevents any attempts at
MAC filtering, not because filtering is required.

> they use all-ff DHCP DISCOVER - ok that's not scalable but that works.

I'll reply to this below.

> NA too.  But only the ND messages that are broadcast in nature.

Hang on a minute:

ND uses multicast on:

Neighbour Solicitation  (Solicited-Nodes:All Address Resolution, DAD)
Neighbour Advertisement (All-Nodes : only really on becoming a Proxy ND,
			and DAD completion)
Router Solicitation     (All-Routers: Always)
Router Advertisemen:    (All-Nodes: when multicast delivery is used

Only one of these is (almost) guaranteed to be on the fixed network
infrastructure side of the network (RA).

So, in every other case they are mutlicast.  This means that in your
plan, every IPv6 host sends NS's, RS's and Unsolicited NA's out every 
LAN segment and cell?

And still the nodes can'd handle MLD (v1 or v2) queries...

> that the address notation is different.

No-one uses hubs anymore. This is the 21st century.

Clearly I'm generalizing, but we shouldn't build in bad
technology for the sake of a few devices.

>> addresses.   Perhaps it is well to note that these cards won't be able 
>> to run IPv6.
> 
> 

It's not as simple as that.

Now we've got a deployed base.
What do we do about 2460/2461/2462/2463 compliant nodes?

Greg

---

From: Greg Daley <[email-masked]>
Date: Wed, 02 Mar 2005 12:25:33 +1100

Hi Martin,

[chop]
> response, I'm fairly sure the default settings will be for a multicast

Are we interested in clarifying whether packets need to be sent to
33:33, or whether using promiscuous or all-multi flags on interfaces
are sufficient to get legacy ethernet devices to work with IPv6?

Is this for reception only, or do the legacy devices also need to
transmit on ff:ff:ff:ff:ff:ff?

I understand that one may imply changing the other, but it may be
useful to see if only the reception can be modified, and whether
these modifications work on all interfaces.

If there's reluctance to change ND for broadcast, then this may be
a way around the issue.

Greg