Subject: Status of the "u" bit for privacy extensions

From: Florent Fourcot <[email-masked]>
Date: Tue, 18 Feb 2014 11:02:05 +0100

Hello,

the RFC 7136 has removed/clarify the significance of bits in interface
identifier for future iids generation, but it does not include any
reference to some current iids generation.

For example, the RFC 4941 asks to set the bit 6 to zero:
http://tools.ietf.org/search/rfc4941#section-3.2.1

Should current implementations following this rule to be updated? What is
the current rule for this?

Regards,

-- 
Florent.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 18 Feb 2014 10:24:34 -0300

Hi, Florent,

> the current rule for this?

Strictly speaking, I'd say that, since RFC4941 has not been updated in
this respect, if you comply with RFC4941, you should use the old semantics.

That said, in the light of RFC7136, it would probably make sense to use
the semantics in RFC7136. -- that's what we did in
draft-ietf-6man-stable-privacy-addresses, for instance.

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

---

From: Florent Fourcot <[email-masked]>
Date: Tue, 18 Feb 2014 20:06:22 +0100

> the semantics in RFC7136.
> 

Thanks Fernando. I'm afraid, it will probably not enough convincing for
Linux kernel developers to change the current behaviour.

Regards,

-- 
Florent.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Feb 2014 10:22:29 +1300

> Linux kernel developers to change the current behaviour.

I don't see a problem. We tried to be careful in RFC7136 not to break
or even theoretically invalidate any current code. The document that
would ask for a change is draft-ietf-6man-default-iids, if approved.
But even so, it would not break any running code.

(Personal comment: breaking running code would be a really silly
thing for the IETF to do at this stage in the life of IPv6.)

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Feb 2014 02:17:04 -0300

Florent,

> Linux kernel developers to change the current behaviour.

They need not. If they implement RFC4941, that's what they should be
complying with.  RFC7136 *has not*  updated RFC4941 in this respect.

When we did draft-ietf-6man-stable-privacy-addresses (currently in the
RFC Editor queue), we took the advice from RFC7136 and thus treat all 64
bits of the IID as an opaque value.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1