Re: 6man w.g. last call for <draft-ietf-6man-default-iids-11.txt>

[Mark Smith <[e-mail]>]

On 19 May 2016 4:11 PM, "Lorenzo Colitti" <[e-mail]> wrote:
>
> On Thu, May 19, 2016 at 2:19 PM, Alissa Cooper <[e-mail]> wrote:
>>
>> The draft makes just about a clear a statement in this vein as is
possible:
>>
>> "By default, nodes SHOULD NOT employ IPv6 address generation schemes
>>    that embed the underlying link-layer address in the IID.”
>>
>> Note that this statement does not prohibit anything, nor does it make a
normative (in the moral sense) judgment. It just states the recommendation,
which is the point of the document.
>>
>> I appreciate that not everyone on the list agrees with this
recommendation. But I find the claim that this recommendation is unclear to
be difficult to understand. That is, I can’t think of a way to convey the
same recommendation that would be clearer. If you can, please suggest text.
>
>
> Alissa,
>
> I don't think anybody is claiming that the recommendation itself is
difficult to understand. What is difficult to understand is how the
document justifies that claim.
>
> It looks like the main argument used to justify this recommendation is
major privacy risks. But embedding a link layer identifier into an IP
address is not a major [1] privacy risk. It is only embedding a *STABLE*
link-layer address that is a major privacy risk.
>
> Recommending that link-layer address be embedded only if they are
ephemeral would address the privacy concerns just as well as (or maybe even
better) than the approach proposed in this document.
>

So how would the IPv6 layer test that, and if it was tested properly, what
happens if the test fails?

I think the testing of layer 2 address randomisation, and coming up with a
both a user acceptable and friendly scheme to deal with a test failure is
harder and more complex that just universally applying RFC7217 to all past,
current and future link layers, regardless of how good or bad their link
layer addresses are.

It fits the principle of having a single and general solution for all cases
rather than having tests, dealing with exceptions and individual
case-by-case solutions.

IPv6 has followed a theme of trying to generalise functions from layer 2
into layer 3 (e.g.,  ND over ICMPv6 rather than link specific versions of
ND, DHCPv6 over IPv6 over PPP rather than DNS etc. in IPV6CP etc.).

This IPv6 address privacy problem exists at the IPv6 layer. Solve it at the
IPv6 layer and it has only needed to be solved once, rather than
repeatedly, and has been solved universally.

> I think what people are do not understand is why this document recommends
one but not the other. I certainly don't.

RFC1958 explains it:

"The Internet level protocol must be independent of the hardware medium and
hardware addressing."

RFC7217 is fixing a mistake as well as increasing privacy.

Regards,
Mark.

> Cheers,
> Lorenzo
>
> [1] I argue that cross-referencing IPX traffic to IP traffic is not a
major privacy risk because IPX is so uncommon.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>