Subject: RE: about v6 over multicast-less Ethernet

From: "Christian Huitema" <[email-masked]>
Date: Tue, 1 Mar 2005 09:51:32 -0800

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

Yes, we took that decision, and it was certainly justified by
operational constraints. However, my contention is that we did not go
far enough. We accepted that normal operation of IPv6 networks will rely
on the availability of multicast, and relegated non-multicast and
non-broadcast networks to some kind of secondary limbo. 

Yet, we are seeing more and more technologies were multicast, while
supported, is costly, slow, and unreliable. The main example is that of
wireless communication. Point-to-point operation is made more reliable
by link-level acknowledgements, which are not available for multicast
packets. Closed-loop controls allows energy saving and overall noise
reduction by just using the amount of power necessary to reach the
intended recipient, but broadcast packets must be sent at full power.
Power saving modes force access points to queue broadcast packets until
the time interval where all potential receivers are supposed to be
awake, resulting in significant delays. The list goes on.

The practical consequence is that the current multicast based systems,
in practice, do not run well over wireless networks. You may remember
that, in San Diego, IPv6 was initially turned off on the WIFI network.
Too many multicast packets were clogging the network. It could only be
turned on again when the access points were reprogrammed with new
software allowing for IPv6 neighbor discovery caching.

It does not have to be so. There is a lot of literature available on
distributed hash table technologies, which provides for distributed
resolution of binary identifiers in large networks without requiring
multicast operation. We should be able to harness these algorithms and
provide a version of neighbor discovery that does not require the use of
either broadcast or multicast.

-- Christian Huitema

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

---

From: Bob Hinden <[email-masked]>
Date: Tue, 01 Mar 2005 14:55:18 -0800

Christian,

[No hats on]

>software allowing for IPv6 neighbor discovery caching.

This is somewhat different from what I remember about the WLAN AP problems 
in San Diego.  I thought the problem was related to new beta code that 
hadn't been tested in production.  The vendor had implemented some sort of 
IPv4 ARP caching, but when they did a similar thing for IPv6 it wasn't 
fully cooked.

>either broadcast or multicast.

To the larger point about IPv6 requiring multicast, I think it is worth 
looking at approaches as you describe.  However, I think the focus should 
be on networks (e.g., wireless) where supporting reliable multicast is 
difficult or expensive, not what started this thread (i.e., an apparently 
broken ethernet interface).

Could you flesh out what you are thinking about?

Thanks,
Bob