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

2015-12-03 Thread Ignatios Souvatzis
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  followed
by a couple of times its mac address anywhere in a packet, right?

-is


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

2014-09-23 Thread Phil Mayers

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

2014-09-22 Thread Mikael Abrahamsson

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 Abrahamssonemail: swm...@swm.pp.se


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

2014-09-22 Thread Stig Venaas

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)

2014-09-22 Thread Sander Steffann
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)

2014-09-22 Thread Steinar H. Gunderson
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)

2014-09-22 Thread Andrew 👽 Yourtchenko
On 9/21/14, Sander Steffann  wrote:
> Hi Mikael,
>
> Op 21 sep. 2014, om 07:45 heeft Mikael Abrahamsson  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)

2014-09-22 Thread Phil Mayers

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)

2014-09-22 Thread Phil Mayers

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)

2014-09-22 Thread Ignatios Souvatzis
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)

2014-09-21 Thread Tom Hill
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)

2014-09-21 Thread Sander Steffann
Hi Mikael,

Op 21 sep. 2014, om 07:45 heeft Mikael Abrahamsson  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)

2014-09-20 Thread Mikael Abrahamsson

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 Abrahamssonemail: swm...@swm.pp.se


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

2014-09-17 Thread Thomas Schäfer
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 
> \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)

2014-09-17 Thread Enno Rey
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)

2014-09-17 Thread Ignatios Souvatzis
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)

2014-09-17 Thread Ignatios Souvatzis
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)

2014-09-17 Thread Mikael Abrahamsson

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 Abrahamssonemail: swm...@swm.pp.se


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

2014-09-16 Thread Tom Hill
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)

2014-09-16 Thread Bjørn Mork
Ignatios Souvatzis  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  
\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)

2014-09-16 Thread Ignatios Souvatzis
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)

2014-09-15 Thread Thomas Schäfer
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:4: 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