Re: <draft-ietf-6man-default-iids> update to rfc2464bis

[Fernando Gont <[e-mail]>]

On 01/12/2017 06:57 AM, Lorenzo Colitti wrote:
> On Thu, Jan 12, 2017 at 6:21 PM, Fernando Gont <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     > I don't see what RFC 4941 has to do with this discussion. RFC4941 is a
>     > method of generating temporary addresses. It is not required to be used,
>     > and it is not the only way of forming IP addresses that can change over
>     > time.
> 
>     If you use temp-only, that means the inability to have e.g. long-lived
>     SSH sessions. I don't think that's the current operating "model", even
>     less for IPv6.
> 
> 
> I don't see why we should forbid this. It's a legitimate implementation
> choice, and has excellent privacy properties :-)

I'm not saying we should forbid this -- actually, there are scenarios
where it should probably be the recommended approach.

But that's not the operating model we have right now -- that's the point.


>     So far, the only two standardized algorithms for generating IIDs with
>     SLAAC are RFC7217, RFC4941, and traditional slaac (modified eui-64).
>     Clearly, you can hack your code and commit it. Being that this is
>     standardization body, I would expect that we're agree on standardizing
>     reasonable approaches, and calling bad approaches as such.
> 
> Sure. If you can find rough consensus to say all other methods of
> generating IIDs are bad and should not be used, the IETF will publish a
> document saying that. My bet is that you won't.

I'm not saying that. For instance, if you want temp addresses, and you
decide to send the 64 bits with a PRNG of your choice, that's fine. If
your goal is privacy and you decide to waste 18 bits 'cause you want to
stick to modified-eui64, you're doing a lousy job.

Essentially, it all boils down to "use as many bits as you're given for
your unpredictable id, and do not reuse identifiers from other layers".
Me, i don't care what you use as long as you stick to that.



> To get back to the original point: in the current state of the documents
> that we have published or are about to publish (e.g., the default-iids
> draft), as reflecting the consensus call sin th it's not true that
> modified EUI-64 is not recommended. It's only not recommended if you use
> stable link-layer addresses.
> 
> Bob, Ole, Suresh: can we also amend or remove this text in 4291bis
> before we publish it? I think it's an oversight because there was clear
> consensus in 6man (Fernando being in the rough) that it was OK to use
> modified EUI-64 with non-stable MAC addresses:
> 
>    Earlier versions of this document described a method of forming
>    interface identifiers derived from IEEE MAC-layer addresses call
>    Modified EUI-64 format.  These are described in Appendix A and are no
>    longer recommended.

All these documents are about generating stable addresses, not temporary
addresses. So I'm not sure why the text should be removed. The text in
all this documents ae about stable addresses. IETF-wise, the only doc
that is about temporary addresses is RFC4941. Hence the text seems
correct to me.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492