Subject: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients

From: [email-masked]
Date: Sat, 27 Jun 2015 04:47:01 -0700

A new draft has been posted, at http://tools.ietf.org/html/draft-vyncke-v6ops-ipv6-only-thin-clients. Please take a look at it and comment.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 27 Jun 2015 19:59:11 +0000

> On Jun 27, 2015, at 4:47 AM, Fred Baker (fred) <[email-masked]> wrote:
> 

You have seen my comments about the developing agenda for IETF 93. This is a draft that I'm specifically looking for feedback on. If there is interest in the working group, we may have a few minutes to discuss it f2f; in any event, I think it needs discussion on the list, and I'd be happy to see it discussed somewhere else if that works better.

The draft is a quick read, and I suspect covers only the most glaring issues in IPv6-only networks. Folks that are running IPv6-only handsets in mobile networks are dealing with various issues, no doubt, and we have several wireline networks that are experimenting with IPv6-only with an IPv4 overlay. What are the IPv6 issues (not IPv4 issues) that we are seeing with hosts in IPv6-only networks?

Your comments please...

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 27 Jun 2015 23:20:47 +0000

The Preboot section needs more work.  Only if the deployment does not include a router which sends an RA, does the preboot use DHCPv6.   Magically, the node would know to initiate DHCPv6 and preboot...  If the deployment includes a router, the node can generate a global IPv6 address using SLAAC and then use tftpv6 to fetch its OS tar ball and be done.   

Maybe when we have at least 5-6 serious issues collected we can consider the document for v6ops WG adoption.

Thanks,

Hemant

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker (fred)
Sent: Saturday, June 27, 2015 3:59 PM
To: v6ops list
Cc: [email-masked]
Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients

Your comments please...

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Jun 2015 11:54:09 +1200

> 1.  Wake-on-Lan
...
>    for a specific host.  This is called the magic packet: with the
>    Ethernet payload having somewhere 6 bytes containing 0xFF followed by
>    16 times the network interface datalink-layer address.

How is this going to work with surveillance-averse clients that change
their MAC address from time to time? I think wake-on-lan is going to
need a complete rethink (including IPv6, of course) because of this.

It seems to me that to solve this *and* the PXE issue, there's going
to end up being some requirement for the thin client to wake itself
up periodically and execute some sort of discovery process. (Something
we are going to need in the Anima WG, too, IMHO.)

Regards
   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 29 Jun 2015 02:19:09 +0000 (UTC)

Hi,
Some thoughts/comments:

Regarding WoL, at least one of my Wifi NICs supports it, so it isn't exclusive to wired links. I don't know much about it, I've discovered it because I've wanted to save device power and therefore switch it off. According to some Internet searching it is more generally known as "Wake on Wireless LAN" or "WoWLAN".

"1.3.  Mitigation"

"For example, to reach all nodes in 2001:db8::/64, let's
   configure a static Neighbor Cache entry for 2001:db8::cafe:c0:ffee as   ff-ff-ff-ff-ff-ff."
I think it would be better to use the IPv6 link-layer "all nodes" multicast address of 33:33:00:00:00:01 for this. Ideally, in an IPv6 only network, NICs could drop link-layer broadcasts and perform an amount of multicast address filtering.
...

"2.  opening a door to a denial of service attack: a remote hostile       party could keep sending packets this is specific unicast address       forcing all hosts to stay awake, hence wasting electrical energy.       As this address is a unicast address which does not belong to any       physical host on the layer-2 domain, then all nodes will silently       discard this packet at the layer-3."
This reads to me as though it is being seen as an IPv6 specific threat, where as I'd consider it to also be a threat in an IPv4 network. If it is not seen as an IPv4 threat because of RFC1918 addresses, then I think the equivalent mitigation for IPv6 would be to limit the ability to wake devices by only allowing/using ULA addresses for WoL magic destinations (i.e., devices would still have global addresses, but a global address would not be a magic WoL address.)
Regards,Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 29 Jun 2015 02:32:06 +0000 (UTC)

From: Brian E Carpenter <[email-masked]>
 To: v6ops list <[email-masked]> 
Cc: draft-vyncke-v6ops-ipv6-only-thin-clients@.ietf.org 
 Sent: Sunday, 28 June 2015, 9:54
 Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients
   
...

/ As I haven't worked on a network that uses WoL, I was thinking that it must already be pretty onerous to be maintaining a list of devices and their MAC addresses for WoL purposes. 
/ There seem to be a number of other WoL methods; here are the list of WoL packet types/events that can be set using the Linux 'ethtool' utility for a NIC:

--       wol p|u|m|b|a|g|s|d...              Sets Wake-on-LAN options.  Not all devices  support  this.   The              argument  to  this  option  is a string of characters specifying              which options to enable.
              p   Wake on PHY activity              u   Wake on unicast messages              m   Wake on multicast messages              b   Wake on broadcast messages              a   Wake on ARP              g   Wake on MagicPacket™              s   Enable SecureOn™ password for MagicPacket™              d   Disable (wake on  nothing).   This  option                  clears all previous options.
       sopass xx:yy:zz:aa:bb:cc              Sets  the  SecureOn™ password.  The argument to this option must              be 6 bytes in Ethernet MAC hex format (xx:yy:zz:aa:bb:cc).--
/ Looking at the WoL spec referenced, that looks to be the MagicPacket option mentioned above. Perhaps networks using WoL are using more coarse methods which would continue to work even with changing MAC addresses.

/ Regards,/ Mark.

Regards
  Brian

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Jun 2015 10:31:58 +0200

> IPv6-Only for Wired Thin-Clients

Examples of recent wired thin clients please?  I am left at the point 
where HP's Apollo workstation and Sun's network computers disappeared 
from the market?

The initial issues presented - "Wake-on-LAN" and "PXE" - are valid in my 
thick laptop as well.

draft says:
>    In IPv6, there is no directed broadcast for good reason.  Only a
>    link-local multicast group such as ff02::1 for all link-local hosts.
>    So, the magic packet for a single host could be sent to this
>    multicast group, reaching all link-local hosts (as switches and
>    routers will forward this packet to all ports/interfaces) and waking
>    up the sleeping node.  But, there is no solution for a remote
>    operator to send this magic packet...

A 'directed broadcast' in IPv4 parlance RFC2644, that needs to reach 
across-the-subnet groups, would mean a classical IPv6 multicast group 
with global scope.  The thin clients on a subnet would join this 
multicast group before going to sleep.

I guess this would work.

I guess this would benefit from a registration of particular multicast 
group.

Or otherwise is there a problem in that the magic packet is a non-IP 
packet?  If yes then either we make the magic packet an IP packet (IPv4 
and IPv6) or we request IEEE to implement link-layer across-the-subnet 
multicast, if such a thing could exist.

Other issues to be suggested to an IPv6-only draft: a recent SDN 
implementation absolutely needs IPv4 to make IPv6 work, details on the 
web.  But this may be too high level?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Jun 2015 10:33:53 +0200

Le 29/06/2015 04:32, Mark ZZZ Smith a écrit :
>
> ------------------------------------------------------------------------
> *From:* Brian E Carpenter <[email-masked]>
> *To:* v6ops list <[email-masked]>
> *Cc:* draft-vyncke-v6ops-ipv6-only-thin-clients@.ietf.org
> *Sent:* Sunday, 28 June 2015, 9:54
> *Subject:* Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients
>
>  > 1.  Wake-on-Lan
> ...
> / As I haven't worked on a network that uses WoL, I was thinking that it
> must already be pretty onerous to be maintaining a list of devices and
> their MAC addresses for WoL purposes.
>
> / There seem to be a number of other WoL methods; here are the list of
> WoL packet types/events that can be set using the Linux 'ethtool'
> utility for a NIC:
>
> --
>         wol p|u|m|b|a|g|s|d...
>                Sets Wake-on-LAN options.  Not all devices  support
>   this.   The
>                argument  to  this  option  is a string of characters
> specifying
>                which options to enable.
>
>                p   Wake on PHY activity
>                u   Wake on unicast messages
>                m   Wake on multicast messages
>                b   Wake on broadcast messages
>                a   Wake on ARP
>                g   Wake on MagicPacket™
>                s   Enable SecureOn™ password for MagicPacket™
>                d   Disable (wake on  nothing).   This  option
>                    clears all previous options.

That begs for an option 'n' Wake on ND.

Alex

>
>         sopass xx:yy:zz:aa:bb:cc
>                Sets  the  SecureOn™ password.  The argument to this
> option must
>                be 6 bytes in Ethernet MAC hex format (xx:yy:zz:aa:bb:cc).
> --
>
> / Looking at the WoL spec referenced, that looks to be the MagicPacket
> option mentioned above. Perhaps networks using WoL are using more coarse
> methods which would continue to work even with changing MAC addresses.
>
> / Regards,
> / Mark.
>
>
> [email-masked] <mailto:[email-masked]>