Subject: [dhcwg] Feedback on anonymity profile -- DHCPv6 Confirm.

From: Christian Huitema <[email-masked]>
Date: Tue, 16 Jun 2015 22:09:43 +0000

In DHCPv6, "A client sends a Confirm message to any available server to determine whether the addresses it was assigned are still appropriate to the link to which the client is connected." This is great if the client is reconnecting to the same link, e.g. when roaming between access points in a Wi-Fi network. The address will be confirmed, and there will be little if any connectivity hiatus. But when the client is actually moving to a new link, this actually reveals the previous address, which is a privacy issue. So the anonymity profile contains a recommendation that "Clients interested in protecting their privacy SHOULD NOT send Confirm messages and instead directly try to acquire addresses on the new link."

When doing our implementation, we found that recommendation a bit too harsh. Consider a large place like a conference with multiple access points. As people walk around you, the transmission conditions change, and your Wi-Fi card will disconnect from one access point and connect to another. In most cases, the old and new AP are part of the same subnet, and the client can keep the same addresses. Of course, there are time when the new AP is on a different subnet. The CONFIRM message is quite useful to delineate between the two cases. Without it, there would be a lot of address thrashing.

So I am proposing to change the text a bit. Add a "MAY send a Confirm" if the client has reasons to believe that this is the same network, and if the MAC Address has not been reset between the two connections.

Any feedback?

-- Christian Huitema

---

From: Erik Kline <[email-masked]>
Date: Wed, 17 Jun 2015 10:27:36 +0900

You could add some (non-normative, presumably) reference to nodes
using DNAv6 (https://tools.ietf.org/html/rfc6059) to first determine
if the link is likely to be the same before proceeding with the
CONFIRM.

https://tools.ietf.org/html/rfc6059#section-5.5.4 will likely become
out of date.

On Wed, Jun 17, 2015 at 7:09 AM, Christian Huitema
<[email-masked]> wrote:
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 17 Jun 2015 02:26:49 +0000

I think both proposals are good (and yes, the anonymity profile document
would thus impact 5.5.4 of RFC 6059 - thanks for pointing that out Erik).

- Bernie

On 6/17/15, 6:57 AM, "Erik Kline" <[email-masked]> wrote:

>> In DHCPv6, "A client sends a Confirm message to any available server to
>>determine whether the addresses it was assigned are still appropriate to
>>the link to which the client is connected." This is great if the client
>>is reconnecting to the same link, e.g. when roaming between access
>>points in a Wi-Fi network. The address will be confirmed, and there will
>>be little if any connectivity hiatus. But when the client is actually
>>moving to a new link, this actually reveals the previous address, which
>>is a privacy issue. So the anonymity profile contains a recommendation
>>that "Clients interested in protecting their privacy SHOULD NOT send
>>Confirm messages and instead directly try to acquire addresses on the
>>new link."
>>
>> When doing our implementation, we found that recommendation a bit too
>>harsh. Consider a large place like a conference with multiple access
>>points. As people walk around you, the transmission conditions change,
>>and your Wi-Fi card will disconnect from one access point and connect to
>>another. In most cases, the old and new AP are part of the same subnet,
>>and the client can keep the same addresses. Of course, there are time
>>when the new AP is on a different subnet. The CONFIRM message is quite
>>useful to delineate between the two cases. Without it, there would be a
>>lot of address thrashing.
>>
>> So I am proposing to change the text a bit. Add a "MAY send a Confirm"
>>if the client has reasons to believe that this is the same network, and
>>if the MAC Address has not been reset between the two connections.
>>
>> Any feedback?
>>
>> -- Christian Huitema
>>