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

"Valenkamp Derk-Jan (ID NET)" <> Mon, 29 June 2015 08:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9F15A1A8784 for <>; Mon, 29 Jun 2015 01:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1wWZfiJLJPSg for <>; Mon, 29 Jun 2015 01:13:16 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AEB51A8781 for <>; Mon, 29 Jun 2015 01:13:14 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 29 Jun 2015 10:13:11 +0200
Received: from ([fe80::4875:1a61:8b1c:148]) by ([fe80::55ba:c4a5:d8a7:ab62%10]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 10:13:12 +0200
From: "Valenkamp Derk-Jan (ID NET)" <>
To: 'Mark ZZZ Smith' <>, "" <>
Thread-Topic: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients
Thread-Index: AQHQsM8Cr1YAViQEYUWVbzB756GP+53CoNGAgAB5wUA=
Date: Mon, 29 Jun 2015 08:13:11 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, de-CH
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E31607B6A0D84647BE15CC3D6C476C592B14B3BDMBX114dethzch_"
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Approved-At: Thu, 02 Jul 2015 06:53:25 -0700
Cc: "" <>
Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Jun 2015 08:13:18 -0000


See my comments inline.



From: Mark ZZZ Smith []
Sent: Montag, 29. Juni 2015 04:19
Subject: Re: [v6ops] new draft: draft-vyncke-v6ops-ipv6-only-thin-clients


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

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.

Derk: Yes, I guess for IPv6 only 33:33:00:00:00:01 will be the better choice. I’ve no experience how a Layer 2 switch handle a packet with ethertype ‘IPv6’ and destination ff:ff:ff:ff:ff:ff, which is in my opinion illegal packet.

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

Derk: The threat exist also in IPv4 networks. That’s why usually directed broadcast are only enabled with access-list, to allow the directed broadcast only from certain source IP’s.  In our university network  only allowing/using ULA addresses for WoL would not solve the threat.