Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. nsp>
  3. ipv6
wake on lan / wol with linux in IPv6-LAN (without IPv4)
thomas at cis
Sep 15, 2014, 3:29 AM
Post #1 of 23 (15981 views)
Permalink
Hi,

On Saturday I disabled IPv4 in my home network. ( using DNS64/NAT64 for
external things). ( no great discussion about it, it is just a test)

But I was surprised by this problem:

wol 1C:6F:65:C9:87:46
wol: Cannot send magic packet for '1C:6F:65:C9:87:46' to
255.255.255.255:40000: Network is unreachable

wakeonlan 1C:6F:65:C9:87:46
Sending magic packet to 255.255.255.255:9 with 1C:6F:65:C9:87:46
send : Network is unreachable at /usr/bin/wakeonlan line 83.


Does anybody know a small wol implementation for linux, usable in IPv6-LANs?


The packages I used are:

thomas@eee-box:~> rpm -qi wol
Name : wol
Version : 0.7.1
Release : 157.1.2
Architecture: x86_64
Install Date: So 17 Nov 2013 15:36:24 CET
Group : Productivity/Networking/Boot/Utilities
Size : 149735
License : GPL-2.0+
Signature : RSA/SHA256, Fr 27 Sep 2013 22:42:51 CEST, Key ID
b88b2fd43dbdc284
Source RPM : wol-0.7.1-157.1.2.src.rpm
Build Date : Fr 27 Sep 2013 22:42:34 CEST
Build Host : build24
Relocations : (not relocatable)
Packager : http://bugs.opensuse.org
Vendor : openSUSE
URL : http://ahh.sourceforge.net/wol/
Summary : Wake On Lan client
Description :
The Wake On Lan client wakes up magic packet compliant machines such as
boxes with wake-on-lan ethernet-cards. Some workstations provide
SecureON which extends wake-on-lan with a password. This feature is
also provided by wol.



Authors:
--------
Thomas Krennwallner <krennwallner@aon.at>
Distribution: openSUSE 13.1


thomas@eee-box:~> rpm -qi wakeonlan
Name : wakeonlan
Epoch : 0
Version : 0.41
Release : 21.1
Architecture: noarch
Install Date: Mo 15 Sep 2014 11:45:29 CEST
Group : Development/Libraries
Size : 13924
License : Artistic
Signature : DSA/SHA1, Di 22 Okt 2013 00:20:22 CEST, Key ID ac99268ca568d868
Source RPM : wakeonlan-0.41-21.1.src.rpm
Build Date : Di 22 Okt 2013 00:20:08 CEST
Build Host : cloud110
Relocations : (not relocatable)
Vendor : obs://build.opensuse.org/home:ang-cz
URL : http://gsd.di.uminho.pt/jpo/software/wakeonlan/
Summary : Perl script to wake up computers through Magic Packets
Description :
This script sends 'magic packets' to wake-on-lan enabled ethernet
adapters and motherboards, in order to switch on the called PC.
Distribution: home:ang-cz / openSUSE_13.1
thomas@eee-box:~>


Regards,
Thomas Schäfer
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
thomas at cis
Sep 15, 2014, 10:46 AM
Post #2 of 23 (15873 views)
Permalink
Am Montag, 15. September 2014, 12:29:45 schrieb Thomas Schäfer:
> Hi,
>
> On Saturday I disabled IPv4 in my home network. ( using DNS64/NAT64 for
> external things). ( no great discussion about it, it is just a test)
>
> But I was surprised by this problem:
>
> wol 1C:6F:65:C9:87:46
> wol: Cannot send magic packet for '1C:6F:65:C9:87:46' to
> 255.255.255.255:40000: Network is unreachable
>
> wakeonlan 1C:6F:65:C9:87:46
> Sending magic packet to 255.255.255.255:9 with 1C:6F:65:C9:87:46
> send : Network is unreachable at /usr/bin/wakeonlan line 83.
>
>
> Does anybody know a small wol implementation for linux, usable in IPv6-LANs?

I found one tool "etherwake" by Donald Becker. It doesn't use IP/UDP. It makes
wol directly on ethernet, but it needs to be run as root.

I am still looking for an IPv6-wol (without mono)

Thomas
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
ignatios at cs
Sep 16, 2014, 12:59 AM
Post #3 of 23 (15819 views)
Permalink
On Mon, Sep 15, 2014 at 07:46:04PM +0200, Thomas Schäfer wrote:

> I am still looking for an IPv6-wol (without mono)

I suspect that sending to the all-stations multicast would work, wouldn't
it? The hardware detects the magic pattern anywhere in the packet.

Thinking about it - it should work whether the target machine uses IPv6
in normal operation or not.

-is
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
bjorn at mork
Sep 16, 2014, 5:34 AM
Post #4 of 23 (15818 views)
Permalink
Ignatios Souvatzis <ignatios@cs.uni-bonn.de> writes:
> On Mon, Sep 15, 2014 at 07:46:04PM +0200, Thomas Schäfer wrote:
>
>> I am still looking for an IPv6-wol (without mono)
>
> I suspect that sending to the all-stations multicast would work, wouldn't
> it? The hardware detects the magic pattern anywhere in the packet.
>
> Thinking about it - it should work whether the target machine uses IPv6
> in normal operation or not.

This depends on all-stations multicast being forwarded to inactive
ports. If it works with your switches, then fine. But I don't think you
can assume it works everywhere.

You could try something like this (might need a bit more error
detection...):

#!/usr/bin/perl
use Socket;
use Socket6;
my $iface = shift;
my $mac = pack("C6", map { hex } split(/:/, shift || die "Usage: $0 <iface> <mac>\n"));
socket(S, AF_INET6, SOCK_DGRAM, 17);
require "sys/ioctl.ph";
ioctl(S, &SIOCGIFINDEX, $iface);
setsockopt(S, IPPROTO_IPV6, IPV6_MULTICAST_IF, substr($iface, 16));
send(S, pack("C6", (255) x 6) . $mac x 16, 0, pack_sockaddr_in6(7, inet_pton(AF_INET6, "ff02::1")));


But IP(v4) broadcast has the advantage that it will be forwarded to all
ports in the L2 broadcast domain. That's why it is often used for
non-root wake-on-lan tools. I guess it's easier/better to just add a
dummy IPv4 broadcast route if you want to enable non-root users to send
wol packets.


Bjørn
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
tom at ninjabadger
Sep 16, 2014, 12:16 PM
Post #5 of 23 (15813 views)
Permalink
On 16/09/14 13:34, Bjørn Mork wrote:
> This depends on all-stations multicast being forwarded to inactive
> ports. If it works with your switches, then fine. But I don't think you
> can assume it works everywhere.

I'd be quite surprised if you find a switch that doesn't treat ff02::1
in the same way as IPv4 broadcast, by default.

Saying that, I'd much prefer that IPv6 WoL had a known IPv6 multicast
address, as opposed to using ff02::1.

--
Tom
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
swmike at swm
Sep 17, 2014, 1:14 AM
Post #6 of 23 (15828 views)
Permalink
On Tue, 16 Sep 2014, Tom Hill wrote:

> I'd be quite surprised if you find a switch that doesn't treat ff02::1
> in the same way as IPv4 broadcast, by default.
>
> Saying that, I'd much prefer that IPv6 WoL had a known IPv6 multicast
> address, as opposed to using ff02::1.

This is actually quite interesting. I read RFC 4291:

"All Nodes Addresses: FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1

The above multicast addresses identify the group of all IPv6 nodes,
within scope 1 (interface-local) or 2 (link-local)."

So, one interpretation would be that if the device hasn't subscribed to
the "all IPv6 nodes" multicast group, it's not an IPv6 node, and shouldn't
receive the traffic.

Also, regarding the above, in order to keep being subscribed to a WoL
multicast address group, wouldn't the NIC have to keep emitting REGISTER
messages periodically? Is this something NICs do today, emitting packets
while the CPU is in fairly deep sleep?

--
Mikael Abrahamsson email: swmike@swm.pp.se
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
ignatios at cs
Sep 17, 2014, 2:59 AM
Post #7 of 23 (15809 views)
Permalink
Hi,

On Wed, Sep 17, 2014 at 10:14:31AM +0200, Mikael Abrahamsson wrote:

> So, one interpretation would be that if the device hasn't subscribed to the
> "all IPv6 nodes" multicast group, it's not an IPv6 node, and shouldn't
> receive the traffic.

Uh, no.

the link-local stuff must never be snooped and blocked, because it is
used to implement neighbour discovery and multicast routing protocols,
multicast group managment etc.

I think there's explicit wording for this - at least for the low /112 -
somehwere.

-is
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
ignatios at cs
Sep 17, 2014, 3:07 AM
Post #8 of 23 (15805 views)
Permalink
On Wed, Sep 17, 2014 at 11:59:55AM +0200, Ignatios Souvatzis wrote:
> Hi,
>
> On Wed, Sep 17, 2014 at 10:14:31AM +0200, Mikael Abrahamsson wrote:
>
> > So, one interpretation would be that if the device hasn't subscribed to the
> > "all IPv6 nodes" multicast group, it's not an IPv6 node, and shouldn't
> > receive the traffic.
>
> Uh, no.
>
> the link-local stuff must never be snooped and blocked, because it is
> used to implement neighbour discovery and multicast routing protocols,
> multicast group managment etc.
>
> I think there's explicit wording for this - at least for the low /112 -
> somehwere.

I slightly misremembered.

RFC 4541 "Considerations for Internet Group Management Protocol (IGMP)
and Multicast Listener Discovery (MLD) Snooping Switches" says:

"3. IPv6 Considerations
[...]

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

-is
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
erey at ernw
Sep 17, 2014, 3:08 AM
Post #9 of 23 (15803 views)
Permalink
Hi,

On Wed, Sep 17, 2014 at 12:07:23PM +0200, Ignatios Souvatzis wrote:
> On Wed, Sep 17, 2014 at 11:59:55AM +0200, Ignatios Souvatzis wrote:
> > Hi,
> >
> > On Wed, Sep 17, 2014 at 10:14:31AM +0200, Mikael Abrahamsson wrote:
> >
> > > So, one interpretation would be that if the device hasn't subscribed to the
> > > "all IPv6 nodes" multicast group, it's not an IPv6 node, and shouldn't
> > > receive the traffic.

RFC 2710, sect. 5, states that no REPORT or DONE messages are to be sent for link-scope all-nodes (ff:02::1), so one can't potentially "subscribe" to that address in a setting with MLD snooping.


>
> RFC 4541 "Considerations for Internet Group Management Protocol (IGMP)
> and Multicast Listener Discovery (MLD) Snooping Switches" says:
>
> "3. IPv6 Considerations
> [...]
>
> 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."
>
> -is

it should be noted that RFC 4541 is an "Informational" one and I don't think any normative value for a kind-of vendor-proprietary thing called "MLD snooping" might be attached to it ;-)

best

Enno






--
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
thomas at cis
Sep 17, 2014, 1:24 PM
Post #10 of 23 (15813 views)
Permalink
Am Dienstag, 16. September 2014, 14:34:13 schrieb Bjørn Mork:

> You could try something like this (might need a bit more error
> detection...):
>
> #!/usr/bin/perl
> use Socket;
> use Socket6;
> my $iface = shift;
> my $mac = pack("C6", map { hex } split(/:/, shift || die "Usage: $0 <iface>
> <mac>\n")); socket(S, AF_INET6, SOCK_DGRAM, 17);
> require "sys/ioctl.ph";
> ioctl(S, &SIOCGIFINDEX, $iface);
> setsockopt(S, IPPROTO_IPV6, IPV6_MULTICAST_IF, substr($iface, 16));
> send(S, pack("C6", (255) x 6) . $mac x 16, 0, pack_sockaddr_in6(7,
> inet_pton(AF_INET6, "ff02::1")));
>

The first try was ok for me. Thanks a lot!

Regards,
Thomas
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
swmike at swm
Sep 20, 2014, 10:45 PM
Post #11 of 23 (15798 views)
Permalink
On Wed, 17 Sep 2014, Enno Rey wrote:

> it should be noted that RFC 4541 is an "Informational" one and I don't
> think any normative value for a kind-of vendor-proprietary thing called
> "MLD snooping" might be attached to it ;-)

I would like to see IGMP and MLD snooping properly standardized.

--
Mikael Abrahamsson email: swmike@swm.pp.se
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
sander at steffann
Sep 21, 2014, 5:31 AM
Post #12 of 23 (15795 views)
Permalink
Hi Mikael,

Op 21 sep. 2014, om 07:45 heeft Mikael Abrahamsson <swmike@swm.pp.se> het volgende geschreven:
> On Wed, 17 Sep 2014, Enno Rey wrote:
>
>> it should be noted that RFC 4541 is an "Informational" one and I don't think any normative value for a kind-of vendor-proprietary thing called "MLD snooping" might be attached to it ;-)
>
> I would like to see IGMP and MLD snooping properly standardized.

Big +1
Sander
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
tom at ninjabadger
Sep 21, 2014, 12:01 PM
Post #13 of 23 (15792 views)
Permalink
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

This means that only hosts listening for IPv6 packets on this multicast
group would care about the WoL traffic sent (giving the stack plenty of
chances to ignore it if it isn't WoL-capable), and that any station
awaiting WoL instructions will not have to emit any sort of MLD
subscription.

Whether the ability to send MLD packets is severely constrained by the
standby power of the NIC, is another matter entirely (and one that I'm
not qualified to comment upon).

My main concern in piggy-backing on ff02::1 for its inherent "passive"
ability, are the associated management/security concerns on a mixed-use
LAN segment. For instance, basic L2 filters could then easily block the
use of the new group, on ingress ports that have no business sending
such WoL commands.

--
Tom
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
ignatios at cs
Sep 22, 2014, 12:42 AM
Post #14 of 23 (15776 views)
Permalink
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
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
p.mayers at imperial
Sep 22, 2014, 2:51 AM
Post #15 of 23 (15785 views)
Permalink
On 22/09/14 08:42, Ignatios Souvatzis wrote:

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

We have some IPv4 /21 with >2**10 hosts actually. They're managed
machines and it's largely to work around the IPv6 address space wastage.
It's marginally suboptimal from a "size of failure domain" PoV, but
we've never actually had the sort of problems this can lead to in
theory, and the alternative was worse.

Obviously single /64 IPv6 (bliss!)

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

Erm... while they're asleep? Doubtful that would work - most network
stacks end up dropping then re-initialising the ethernet link when they
go to sleep, so MLD snooping state is likely to be cleared, and absent
something like AMT/vPro (which comes with it's own IPv6 hassles ;o) to
join the group in the sleeping link-state...
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
p.mayers at imperial
Sep 22, 2014, 2:54 AM
Post #16 of 23 (15775 views)
Permalink
On 22/09/14 10:51, Phil Mayers wrote:
> On 22/09/14 08:42, Ignatios Souvatzis wrote:
>
>> 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?
>
> We have some IPv4 /21 with >2**10 hosts actually

Just to clarify - nearly 2**11, so it isn't half a subnet wasted!
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
ayourtch at gmail
Sep 22, 2014, 9:44 AM
Post #17 of 23 (15760 views)
Permalink
On 9/21/14, Sander Steffann <sander@steffann.nl> wrote:
> Hi Mikael,
>
> Op 21 sep. 2014, om 07:45 heeft Mikael Abrahamsson <swmike@swm.pp.se> het
> volgende geschreven:
>> On Wed, 17 Sep 2014, Enno Rey wrote:
>>
>>> it should be noted that RFC 4541 is an "Informational" one and I don't
>>> think any normative value for a kind-of vendor-proprietary thing called
>>> "MLD snooping" might be attached to it ;-)
>>
>> I would like to see IGMP and MLD snooping properly standardized.
>
> Big +1

Please help me understand.

The standards' purpose is to facilitate the interoperability.

"MLD snooping" happens within a single device.

Its only result in a correct implementation must be "if you join the
group, you should get the traffic, if you did not, you should not"
function.

A result of composition of multiple independent correct
implementations of this function remains the same - "if you join the
group, you should get the traffic, if you did not, you should not".

So, which undefined behaviors that prevent the interop today do you
think would need to be standardized ?

--a



> Sander
>
>
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
sesse at google
Sep 22, 2014, 9:57 AM
Post #18 of 23 (15762 views)
Permalink
On Mon, Sep 22, 2014 at 06:44:11PM +0200, Andrew ? Yourtchenko wrote:
> The standards' purpose is to facilitate the interoperability.
>
> "MLD snooping" happens within a single device.

What about the interaction between switches and the machines?
All interoperability is not about inter-switch/-router.

A few things that would be nice to have standardized (and then put into the
BCP document):

1. Support for IPv4 and IPv6.
2. Support for working correctly in the presence of PIM
(I've seen switches get greatly confused by this, and mess up
the refcounting).
3. Support for SSM.

> A result of composition of multiple independent correct
> implementations of this function remains the same - "if you join the
> group, you should get the traffic, if you did not, you should not".

I suppose the standard would exist to define what _is_ a correct
implementation.

/* Steinar */
--
Software Engineer, Google Switzerland
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
sander at steffann
Sep 22, 2014, 2:41 PM
Post #19 of 23 (15759 views)
Permalink
Hi Andrew,

> Please help me understand.
>
> The standards' purpose is to facilitate the interoperability.
>
> "MLD snooping" happens within a single device.
>
> Its only result in a correct implementation must be "if you join the
> group, you should get the traffic, if you did not, you should not"
> function.
>
> A result of composition of multiple independent correct
> implementations of this function remains the same - "if you join the
> group, you should get the traffic, if you did not, you should not".
>
> So, which undefined behaviors that prevent the interop today do you
> think would need to be standardized ?

Maybe it's as simple as writing down what you described :) Standards don't have to be complicated. Maybe it can describe how a device should operate in certain failure scenarios like when 1000 hosts join 500 multicast groups each and the switch runs out of memory/CPU/etc. The most 'interesting' interoperability problems occur when different devices behave in different ways in weird situations :)

And maybe it is just as simple as you describe :)

Cheers,
Sander
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
stig at venaas
Sep 22, 2014, 3:03 PM
Post #20 of 23 (15770 views)
Permalink
Hi

On 9/22/2014 2:41 PM, Sander Steffann wrote:
> Hi Andrew,
>
>> Please help me understand.
>>
>> The standards' purpose is to facilitate the interoperability.
>>
>> "MLD snooping" happens within a single device.
>>
>> Its only result in a correct implementation must be "if you join the
>> group, you should get the traffic, if you did not, you should not"
>> function.

Aren't the existing documents sufficient? See

RFC 4541
RFC 4605

and also this is related
draft-ietf-pim-explicit-tracking-10

Stig

>> A result of composition of multiple independent correct
>> implementations of this function remains the same - "if you join the
>> group, you should get the traffic, if you did not, you should not".
>>
>> So, which undefined behaviors that prevent the interop today do you
>> think would need to be standardized ?
>
> Maybe it's as simple as writing down what you described :) Standards don't have to be complicated. Maybe it can describe how a device should operate in certain failure scenarios like when 1000 hosts join 500 multicast groups each and the switch runs out of memory/CPU/etc. The most 'interesting' interoperability problems occur when different devices behave in different ways in weird situations :)
>
> And maybe it is just as simple as you describe :)
>
> Cheers,
> Sander
>
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
swmike at swm
Sep 22, 2014, 11:43 PM
Post #21 of 23 (15769 views)
Permalink
On Mon, 22 Sep 2014, Stig Venaas wrote:

> Aren't the existing documents sufficient? See
>
> RFC 4541
> RFC 4605
>
> and also this is related
> draft-ietf-pim-explicit-tracking-10

RFC 4541 is only informational, not standards track. RFC4605 is standards
track. The PIM draft is also standards track, but as far as I can see,
there is no standards-track document for MLD/IGMP snooping.

--
Mikael Abrahamsson email: swmike@swm.pp.se
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
p.mayers at imperial
Sep 23, 2014, 2:14 AM
Post #22 of 23 (15764 views)
Permalink
On 22/09/2014 17:44, Andrew 👽 Yourtchenko wrote:

> Its only result in a correct implementation must be "if you join the
> group, you should get the traffic, if you did not, you should not"
> function.
>
> A result of composition of multiple independent correct
> implementations of this function remains the same - "if you join the
> group, you should get the traffic, if you did not, you should not".

Sadly, some vendors actually need that spelling out, in a way they can't
dodge. There are some very very bad IGMP/MLD snooping implementations
out there; as someone else has pointed out, failure mode on (s,g)
slot/memory exhaustion is particular pernicious. We have devices that
just stop forwarding all current and future multicast (although
thankfully flooding link-local IPv6 so ND etc. continue to work).

Vendor claims this is "expected behaviour" when "too many" hosts join
"too many" groups :o/

It would be a lot easier if a very strict (and short) RFC embodied what
you wrote above, and people could say "must be RFC xxxx compliant" under
their procurement rules. Similar to the RIPE docs for IPv6 feature set.
Re: wake on lan / wol with linux in IPv6-LAN (without IPv4) [ In reply to ]
ignatios at theory
Dec 3, 2015, 5:12 AM
Post #23 of 23 (12579 views)
Permalink
On Tue, Sep 16, 2014 at 08:16:06PM +0100, Tom Hill wrote:
> On 16/09/14 13:34, Bj?rn Mork wrote:
> > This depends on all-stations multicast being forwarded to inactive
> > ports. If it works with your switches, then fine. But I don't think you
> > can assume it works everywhere.
>
> I'd be quite surprised if you find a switch that doesn't treat ff02::1
> in the same way as IPv4 broadcast, by default.
>
> Saying that, I'd much prefer that IPv6 WoL had a known IPv6 multicast
> address, as opposed to using ff02::1.

But... that would mean you'd have to configure that. WoL wants to work
with minimal hardware action - it only checks for any ffffffffffff followed
by a couple of times its mac address anywhere in a packet, right?

-is

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal