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

[Alexandre Petrescu <[e-mail]>]

Le 19/05/2016 à 07:19, Alissa Cooper a écrit :
>
>> On May 18, 2016, at 4:22 PM, 神明達哉 <[e-mail]> wrote:
>>
>> At Tue, 17 May 2016 22:13:36 -0400, Fernando Gont
>> <[e-mail]> wrote:
>>
>>>> From this one, and your response to the next point, it seems
>>>> you are saying the decision was to refuse to address that
>>>> concern.  Am I understanding it correctly?
>>>
>>> No. My take is that the concern is flawed. Please read
>>> draft-gont-predictable-protocol-ids, and even RFC4941, which
>>> talks at length about security and privacy issues regarding
>>> reusing identifiers in different context, for different scopes,
>>> etc.
>>>
>>> Let's call a lemon a lemon: Asking to embed a layer-2
>>> identifier/address in a layer-3 address is extremely bad.
>>
>> I don't have a strong position on this matter itself, but my
>> understanding of the sense of the wg is that this is
>> controversial, and at least far from a clear consensus.  To repeat
>> myself, *my* concern on this last call is that it's not even clear,
>> at least to me, if this draft tries to say embedding a link-layer
>> address is, whether it's randomized or not, "extremely bad" (and
>> must therefore be prohibited).  If that's the intent, it should be
>> clearly stated
>
> 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

I think that recommendation is too generic.

I think it should say:
"If a human user can be reassured during a privacy worry (avoid
  traceability of IP address by surveillance or commercial interests) -
  the EUI-64 SHOULD NOT contain the company_id (the first three octets),
  nor 0xFFFE, nor the last three octets of the Ethernet address"
  - and add it to RFC2464 section 4:
    https://tools.ietf.org/html/rfc2464#section4

I think on some non-Ethernet links there are some 48bit identifiers
which are not assigned by IEEE, but imagined by programmers. They are
not used as a link-layer address (they are not in src/dst headers of
link-layer messaging), but are there only to fill in IPv6 data
structures. Some times they are based on hints, other times they are
random. When they are Unix rand(), and if this can reassure the privacy
worry of a user: they could be put in the IID.

Alex

> 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
>
>
>> and backed by a clear consensus from the wg.  Right now I don't see
>> either such a clear statement or clear wg consensus.
>>
>> -- JINMEI, Tatuya
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>