wake on lan / wol with linux in IPv6-LAN (without IPv4)

Ignatios Souvatzis ignatios at cs.uni-bonn.de
Mon Sep 22 09:42:06 CEST 2014


Hi,

On Sun, Sep 21, 2014 at 08:01:49PM +0100, Tom Hill wrote:
> On 17/09/14 11:07, Ignatios Souvatzis wrote:
> >    In IPv6, the data forwarding rules are more straight forward because
> >    MLD is mandated for addresses with scope 2 (link-scope) or greater.
> >    The only exception is the address FF02::1 which is the all hosts
> >    link-scope address for which MLD messages are never sent.  Packets
> >    with the all hosts link-scope address should be forwarded on all
> >    ports."
> 
> Forgive me if I'm missing some crucial element here, but wouldn't it be
> possible to:
> 
> (1) assign new multicast address for v6 WoL (and not use ff02::1)
> (2) require that traffic for this address is forwarded /like/ ff02::1

Ah - but this would not work on existing switches that do MLD.
That's the same reason IPv4 WoL is typically addressed to
255.255.255.255 or subnet broadcast, to result in ff:ff:ff:ff:ff:ff.

Given that waking up machines isn't a frequent event (compared to
other multicast traffic, where used - neighbour discovery, routing
protocols, video streams, etc.), I don't feel ignoring others WoL
packets on the interupt stack is a huge burden for the non-addressed
machines.

Do we have typical numbers? If I'd measure on my networks, I'd have
about none on our work LANs, and one every couple of weeks at home.

But I imagine people might want to wake every host once a night
and run some backup or software update remotely; so unconcerned
machines would see, say, one or two packets times the number of
sleeping machines per night. How many hosts do you have per broadcast
domain? more than 2**8?

There's another consideration: if you do have the need, due to huge
broadcast domains, nobody prevents you to make your machines
subscribe to a locally assigned multicast address and send your
WoL packets there. All the magic is in the data portion. So why 
change how switches work?

	-is


More information about the ipv6-ops mailing list