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

From: Bob Hinden <[email-masked]>
Date: Mon, 9 Jan 2017 12:40:55 -0800

Hi,

Based on update from draft-ietf-6man-default-iids (currently in RFC Editor queue) I changed the first two paragraphs of Section 4 of <draft-hinden-6man-rfc2464bis-01> to:

   4.  Stateless Autoconfiguration

   The default approach to create stable Interface Identifiers
   [I-D.ietf-6man-rfc4291bis] for use with SLAAC on an Ethernet
   interface should be based on [RFC7217].

   It is not recommended that Interface Identifiers for an Ethernet
   interface be based on IEEE MAC-layer addresses.  Earlier versions of
   this document described a method of forming interface identifiers
   derived from IEEE MAC-layer addresses called Modified EUI-64 format.
   This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and is
   no longer recommended.

Instead of having it pointing to <draft-ietf-6man-default-iids>, the new text points to RFC7271.  I thought this was better as Section 3 of <draft-ietf-6man-default-iids> says the RFC2464 should now follow RFC7271 (including should use RFC7217 and should not use stable link-layer address).  Avoids a extra hope so to speak.

I think the intent of <draft-ietf-6man-default-iids> is captured in the text in the new -01 version.

Comments?

Thanks,
Bob

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Jan 2017 01:59:46 -0300

Hi, Bob,

I agree with your view. Some further comments below:

On 01/09/2017 05:40 PM, Bob Hinden wrote:
> Hi,
> 
> Based on update from draft-ietf-6man-default-iids (currently in RFC
> Editor queue) I changed the first two paragraphs of Section 4 of
> <draft-hinden-6man-rfc2464bis-01> to:
> 

maybe s/should be based on/is spaciefied in/ ?

> interface be based on IEEE MAC-layer addresses.

Maybe s/It is not recommended/Nodes should not/ ?

Maybe a reference to default-iids could be useful here (in addition to
the text).

>  Earlier versions of 
> Instead of having it pointing to <draft-ietf-6man-default-iids>, the
> new text points to RFC7271.  I thought this was better as Section 3
> of <draft-ietf-6man-default-iids> says the RFC2464 should now follow
> RFC7271 (including should use RFC7217 and should not use stable
> link-layer address).  Avoids a extra hope so to speak.

Agreed.

> the text in the new -01 version.

Looks fine, but please check the small suggestions above.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Jan 2017 14:21:25 +0900

>    interface be based on IEEE MAC-layer addresses.

Please include the word "stable" in this sentence. (See below.)

>    This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and is

Based on my reading of draft-ietf-6man-default-iids-16 , it's not correct
to say that this approach is "not recommended". This approach is not
recommended for use with stable MAC addresses, but there is no
recommendation against using it for non-stable MAC addresses. We do
recommended that nodes use RFC7217 addresses by default, but only if the
node wishes to create stable addresses, and there is no requirement that a
node do so.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Jan 2017 04:20:55 -0300

Lorenzo,

On 01/12/2017 02:21 AM, Lorenzo Colitti wrote:
> On Tue, Jan 10, 2017 at 5:40 AM, Bob Hinden <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Based on my reading of draft-ietf-6man-default-iids-16 , it's not
> correct to say that this approach is "not recommended". This approach is
> not recommended for use with stable MAC addresses, but there is no
> recommendation against using it for non-stable MAC addresses.

I agree this part of your comment.

> We do
> node wishes to create stable addresses, and there is no requirement that
> a node do so.

So far, the current specs essentially require that. RFC4941 (the only
spec we have for non-temporary addresses) require that the be generated
along with the traditional (stable) addresses.

FWIW, I do think there are scenarios in which you might want to do
temporary-only, but we certainly need an update to the current specs in
that regard (and guidance regarding where to use each).

That aside, in the context of temp-only addresses, doing Modified-EUI64
based on a randomized MAC address is still a bad idea:

1) It wastes 18 bits of entropy (0xfffe, plus g/l and u/m)
2) Unnecessarily leaks what you're doing in layer-2, at layer 3.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Jan 2017 17:24:21 +0900

> along with the traditional (stable) addresses.

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.

> that regard (and guidance regarding where to use each).

There are lots of ways of forming interface identifiers. We should
absolutely not rule out the ability to form IIDs from non-stable MAC
addresses (IIRC the text in default-iids was carefully modified to ensure
that that would still be possible, based on substantial discussions in the
WG), and we should *absolutely* not say that the only possible form of
interface identifiers on an Ethernet interface are RFC7217 and RFC4941.

> based on a randomized MAC address is still a bad idea:

I am not going to rehash that argument here. Everything we had to say about
that is in the archives.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Jan 2017 06:21:28 -0300

On 01/12/2017 05:24 AM, Lorenzo Colitti wrote:
> On Thu, Jan 12, 2017 at 4:20 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > We do

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.

> addresses (IIRC the text in default-iids was carefully modified to
> ensure that that would still be possible, based on substantial
> discussions in the WG), and we should *absolutely* not say that the only
> possible form of interface identifiers on an Ethernet interface are
> RFC7217 and RFC4941.

Clearly, default-iids talks about stable-iids, and the default algorithm
for such iids. And nobody said otherwise.

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.

Better to have us discuss approaches and std'ize them, that have each
vendor come up with their own (possibly flawed) approach.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Jan 2017 18:57:40 +0900

> SSH sessions. I don't think that's the current operating "model", even

I don't see why we should forbid this. It's a legitimate implementation
choice, and has excellent privacy properties :-)

> 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.

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.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Jan 2017 07:25:24 -0300

On 01/12/2017 06:57 AM, Lorenzo Colitti wrote:
> On Thu, Jan 12, 2017 at 6:21 PM, Fernando Gont <[email-masked]

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.

> 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.

> 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:
> 

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,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Jan 2017 20:08:37 +0900

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

The point I am making is that according to current and
about-to-be-published specs, a node is free to create addresses that change
over time, since nothing forbids it.

> stick to modified-eui64, you're doing a lousy job.

Good, then we agree that a node is free to create addresses that change
over time using schemes that are not described in RFC 7217, RFC 4941, or
any other document.

> that is about temporary addresses is RFC4941. Hence the text seems

If instead of removing that text we can clarify that it only applies to
stable addresses, that works for me. Suggestion: change "These are
described in Appendix A and are no longer recommended." to ""These are
described in Appendix A and are no longer recommended for stable addresses."

The reason the text needs to be changed is because during the discussion of
default-iids there was substantial discussion of the use case of using
EUI-64 with randomized MAC addresses. There was consensus that this is a
use case we want to support, and as a result, the working group concluded
that we should change every occurrence of the phrase "based on a link-layer
address" to "based on a stable link-layer address" in the default-iids
draft. We should make the same distinction in 4291bis and 2464bis: EUI-64
is not recommended for use with stable link-layer addresses, but it can be
used with non-stable link-layer addresses.

You're certainly entitled to your opinion that using EUI-64 with random MAC
addresses is not a good idea, but IETF documents are not based on the
opinion of one participants, they are based on rough consensus.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Jan 2017 08:29:49 -0300

On 01/12/2017 08:08 AM, Lorenzo Colitti wrote:
> On Thu, Jan 12, 2017 at 7:25 PM, Fernando Gont <[email-masked]
> about-to-be-published specs, a node is free to create addresses that
> change over time, since nothing forbids it.

I guess you're allowed. That does change the operating assumptions, and
I wouldn't be surprised to see breakage.

> over time using schemes that are not described in RFC 7217, RFC 4941, or

Yes, you're "free" to do your own proprietary thing, which does not
follow any IETF stds, I guess.

> described in Appendix A and are no longer recommended for stable addresses."

Fine. Isn't the assumption in all these RFCs that the addresses are
stable, and that the MAC addresses are unique?

> The reason the text needs to be changed is because during the discussion
> of default-iids there was substantial discussion of the use case of
> using EUI-64 with randomized MAC addresses. There was consensus that
> this is a use case we want to support, and as a result, the working
> group concluded that we should change every occurrence of the phrase
> "based on a link-layer address" to "based on a stable link-layer
> address" in the default-iids draft.

My read of the discussion is that you didn't want default-iids to ban
this case (and maybe there was not more than one or two voices in this
direction), and we simply decided to have default-iids fous on stable
addresses to be able to do progress on something. Claiming that doing
temp adderesses by doing MOdified-EUI64 is streching that outcome quite
a bit, IMO.

> We should make the same distinction
> in 4291bis and 2464bis: EUI-64 is not recommended for use with stable
> link-layer addresses, but it can be used with non-stable link-layer
> addresses.

All this documents talk about stable addresses. Discussing temp
addresses in them is actually talking about stuff that simply wasn't
there, with operating conditions different from those assummed so far.

Again, I sympathize with temp only in scenarios where they make sense.
But things like that don't seem within what has been specified so far
(i.e., there's work to be done, including analyzing what might break).

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 Jan 2017 21:19:12 +0900

> stable, and that the MAC addresses are unique?

Yes, those documents were written when randomized MAC addresses did not yet
exist, yes. But those assumptions are not valid today; randomized MAC
addresses are not only in use, there are standards track documents that
assume their use (e.g., RFC7844). Since we're now republishing these
documents, we need to make them reflect the state of the world as it is
today, and the revised documents must not assume that MAC addresses are
unique and static.

> temp adderesses by doing MOdified-EUI64 is streching that outcome quite

Funny... my read of the discussion is that everyone wanted to support this
case and only you didn't (and maybe there was not more than one or two
voices in this direction". :-P

But seriously: regardless of which of the two interpretations above is
correct (likely neither), the fact of the matter is that the text in
default-iids says "stable" and that did not happen by chance, but through
explicit working group discussion. We have to respect that here.

> there, with operating conditions different from those assummed so far.

Again: we are republish these documents and we have to do so taking into
account things as they are today. Today, the fact of the matter today is
that MAC addresses are in use and the documents have to reflect that.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Jan 2017 13:25:27 +0100

[Somehow I managed to send this v6ops first :-(]

>document saying that. My bet is that you won't.

Personally I'd say "Modified EUI-64 SHOULD NOT be used on new installations.
Modified EUI-64 SHOULD be implemented"

I think modified EUI-64 with stable MAC addresses has lots of interesting use
cases. And it is upto the admin to determine what is the right thing to do.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Jan 2017 09:40:40 -0300

On 01/12/2017 09:19 AM, Lorenzo Colitti wrote:
> On Thu, Jan 12, 2017 at 8:29 PM, Fernando Gont <[email-masked]
> Yes, those documents were written when randomized MAC addresses did not
> yet exist, yes. But those assumptions are not valid today; randomized
> MAC addresses are not only in use, there are standards track documents
> that assume their use (e.g., RFC7844). Since we're now republishing
> these documents, we need to make them reflect the state of the world as
> it is today, and the revised documents must not assume that MAC
> addresses are unique and static.

Traditional slaac is based on such assumption. I'm not saying we should
keep that. I'm just saying that the documents we're revising have that
assumption in place. And if we want to change such assumption, there's
probably more to do than just "generate the iid with this other
algorithm, instead". That is, that'd be a change that goes further than
what we're doing here.

> Funny... my read of the discussion is that everyone wanted to support
> this case and only you didn't (and maybe there was not more than one or
> two voices in this direction". :-P
> 
> default-iids says "stable" and that did not happen by chance, but
> through explicit working group discussion. We have to respect that here.

As noted, I'm fine with thes docs xplicitly noting that they talk about
stable addresses. That seems to make you have too, so....

(talking about what with temporary MAC addresses would be a different
thing, and seems to be "out of scope" of the *current* effort on these
bis documents. If you want such work to be expanded, such that these
documents also cover temp MACs, I certainly wouldn't oppose... but that
doesn't seem the direction in which these documents are going).

P.S.: I do thing that we need advice on what to do when... stable+temp?
stable only? temp only? there are certainly use cases for each of these
combinations...

---

From: Tim Chown <[email-masked]>
Date: Thu, 12 Jan 2017 13:38:31 +0000

Hi,

On 12 Jan 2017, at 08:24, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> 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.

Indeed, it’s orthogonal to this discussion.

There are lots of ways of forming interface identifiers. We should absolutely not rule out the ability to form IIDs from non-stable MAC addresses (IIRC the text in default-iids was carefully modified to ensure that that would still be possible, based on substantial discussions in the WG), and we should *absolutely* not say that the only possible form of interface identifiers on an Ethernet interface are RFC7217 and RFC4941.

Indeed, I was at CERN yesterday and my address (and thus IID) there was assigned via DHCPv6, which is the only way you can get IPv6 addresses there.  RFC2464 pre-dates DHCPv6; should reference to it be included in the -bis?

I am not going to rehash that argument here. Everything we had to say about that is in the archives.

I support Lorenzo’s suggestion to change the text in the -bis update to emphasise the recommendation is for *stable* identifiers.

This reflects what the default-iids draft clearly states:

"This document changes the recommended default IID generation scheme
   for cases where SLAAC is used to generate a stable IPv6 address.  It
   recommends using the mechanism specified in RFC7217 in such cases,
   and recommends against embedding stable link-layer addresses in IPv6
   Interface Identifiers.”

And it’s only a recommendation. The text does not preclude use of embedded stable MAC addresses if someone really wants to do that.  Nor does it say anything about the relationship to temporary (non-stable) addresses.

Tim

---

From: 神明達哉 <[email-masked]>
Date: Thu, 12 Jan 2017 10:27:39 -0800

At Thu, 12 Jan 2017 13:38:31 +0000,

>    and recommends against embedding stable link-layer addresses in IPv6

+1.  That matches my recollection of the latest discussion for
default-iids.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Fri, 13 Jan 2017 07:09:34 +1100

On 12 Jan. 2017 23:19, "Lorenzo Colitti" <[email-masked]> wrote:

> Yes, those documents were written when randomized MAC addresses did not yet exist, yes. But those assumptions are not valid today; randomized MAC addresses are not only in use, there are standards track documents that assume their use (e.g., RFC7844). Since we're now republishing these documents, we need to make them reflect the state of the world as it is today, and the revised documents must not assume that MAC addresses are unique and static.

(IEEE) MAC addresses aren't the only types of link layer addresses and
may not be in the future.

ARCNet only has 8 bit link-layer addresses and despite its age, it
still looks like it is being manufactured and used.

https://www.ccontrols.com/tech/arcnet.htm

CanBus, used in cars, looks to only have 11 bit or 29 bit addresses

https://en.wikipedia.org/wiki/CAN_bus#Frames

I'm sure there are other link layers out there that we would want IPv6
to run over that have similar sorts of link layer address sizes.

I don't think we shouldn't bind IPv6 address security properties to
link layer address properties, because then it puts the IPv6 address
security properties out of our control.

We could require link-layer addresses to be of a certain size and have
certain properties before running IPv6 over it, however that will
limit IPv6 applicability (in other words, demand that the link layer
addresses under IPv6 MUST be IEEE MAC addresses.)

We could try to check the randomness properties of the link layer
address before using it in a IPv6 address, however then you still need
a fall back if the link-layer address fails that test, so you're going
to have general, non-link layer specific fall back method available
anyway, and the extra code complexity of link layer address validation
checks.

I think it is simpler and easier to ignore the link layer address
properties and generate IPv6 addresses with good security properties
independently of them. The only use of link layer properties is as a
possible seed and as an interface distinguisher when useful or
necessary, which is what RFC7217 does.

I think it is better to try to minimise the coupling and dependencies
between the link layer and link layer properties and the IPv6 layer
rather than trying to tighten it. That seems to have been a theme of
IPv6 e.g., using DHCPv6 over PPP rather than embedding IPv6 upper
layer parameters in PPP such as DNS addresses, and the shifting of
neighbor discovery into IPv6 rather than having a parallel link layer
specific neighbor discovery protocol (i.e., ARP and IPv4 being in a
parallel, and ARP being Ethernet specific.)

This theme is described in RFC1958, even though security benefits may
not have been the reason for it at the time.

"The Internet level protocol must be independent of the hardware
   medium and hardware addressing.  This approach allows the Internet to
   exploit any new digital transmission technology of any kind, and to
   decouple its addressing mechanisms from the hardware. It allows the
   Internet to be the easy way to interconect fundamentally different
   transmission media, and to offer a single platform for a wide variety
   of Information Infrastructure applications and services. There is a
   good exposition of this model, and other important fundemental
   issues, in [Clark]."

> Funny... my read of the discussion is that everyone wanted to support this case and only you didn't (and maybe there was not more than one or two voices in this direction". :-P

I also supported the decoupling. I understand the convenience and
motivation for using random MAC addresses (I've had many of my systems
including my main laptop changing them at boot for a number of years
now), however I think it is a layer dependency that is better to avoid
(i.e., have addresses at both layers that have good security
properties and that don't have any security bindings or couplings
between each other.)

Regards,
Mark.

>But seriously: regardless of which of the two interpretations above is correct (likely neither), the fact of the matter is that the text in default-iids says "stable" and that did not happen by chance, but through explicit working group discussion. We have to respect that here.

> there, with operating conditions different from those assummed so far.

Again: we are republish these documents and we have to do so taking
into account things as they are today. Today, the fact of the matter
today is that MAC addresses are in use and the documents have to
reflect that.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Jan 2017 10:11:29 +1300

> I wouldn't be surprised to see breakage.

It will break on sites that choose a managed addressing policy (as
Tim told us they do at CERN). I wonder what Android users at CERN do?

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Jan 2017 15:41:56 -0800

Hi Fernando,

Thanks for the comments.  

Inline.

Bob

> On Jan 11, 2017, at 8:59 PM, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Bob,
> 

I used “should” because on it comes from draft-ietf-6man-default-iids, that is:

     Nodes SHOULD implement and employ [RFC7217] as the default scheme for
     generating stable IPv6 addresses with SLAAC.

so I think the “should” is important.

> Maybe s/It is not recommended/Nodes should not/ ?

Likewise, draft-ietf-6man-default-iids uses the recommend language.  This is,

   By default, nodes SHOULD NOT employ IPv6 address generation schemes
   that embed a stable link-layer address in the IID.  In particular,
   this document RECOMMENDS that nodes do not generate stable IIDs with
   the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491],
   [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338],
   [RFC4391], [RFC5121], and [RFC5072].

> Maybe a reference to default-iids could be useful here (in addition to

Let me think about that a bit.

>> link-layer address).  Avoids a extra hope so to speak.

Good, thanks.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Jan 2017 15:57:36 -0800

Lorenzo,

> On Jan 11, 2017, at 9:21 PM, Lorenzo Colitti <[email-masked]> wrote:
> 

I agree, this is consistent with draft-ietf-6man-default-iids.

> Based on my reading of draft-ietf-6man-default-iids-16 , it's not correct to say that this approach is "not recommended". This approach is not recommended for use with stable MAC addresses, but there is no recommendation against using it for non-stable MAC addresses. We do recommended that nodes use RFC7217 addresses by default, but only if the node wishes to create stable addresses, and there is no requirement that a node do so.

Would it be better to say (incorporating the change above):

   It is not recommended that Interface Identifiers for an Ethernet
   interface be based on stable IEEE MAC-layer addresses.  Earlier versions of
   this document described a method of forming interface identifiers
   derived from stable IEEE MAC-layer addresses called Modified EUI-64 format.
   This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and is
   no longer recommended.

That is, add “stable”.

Would it then make sense to be explicit to add a new sentence like:

   This approach may be used to create Interface Identifiers based on non-stable (e.g.,
   random) IEEE Mac-layer addresses.

with a reference to the appropriate IEEE specification.

Thanks,
Bob

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Jan 2017 10:27:05 +0900

>    This is described in Appendix A of [I-D.ietf-6man-rfc4291bis] and is

That works for me.

> with a reference to the appropriate IEEE specification.

Yes, that's great.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Jan 2017 10:33:01 +0900

> Tim told us they do at CERN). I wonder what Android users at CERN do?

Presumably they get IPv4 only and don't notice. The few that do, depending
on their opinions, either ask their network admins to follow the best
practices in RFC 7934 or go to http://b.android.com/32621 to complain about
it. :-)

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Jan 2017 18:07:51 -0800

Lorenzo,

> On Jan 12, 2017, at 5:27 PM, Lorenzo Colitti <[email-masked]> wrote:
> 

Good

>> with a reference to the appropriate IEEE specification.

Good.

Do you have a reference to a document that defines random IEEE mac addresses?

Bob

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Jan 2017 12:47:07 +0900

> Do you have a reference to a document that defines random IEEE mac

Not an IEEE reference, but we could certainly cite RFC 7844 section 2.1,
which goes into the subject in detail. Christian might have a better
reference. Christian?

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 12 Jan 2017 21:35:56 -0800

On Thursday, January 12, 2017 7:47 PM, Lorenzo Colitti wrote:

> Not an IEEE reference, but we could certainly cite RFC 7844 section 2.1, which goes
> into the subject in detail. Christian might have a better reference. Christian?

RFC 7844 includes a couple of citations on past experience. There is also the presentation that I gave in Prague: https://www.ietf.org/proceedings/93/slides/slides-93-intarea-5.pdf. Mathy Vanhoef wrote a description of MAC Address Randomization in Windows 10 here: https://www.mathyvanhoef.com/2016/03/how-mac-address-randomization-works-on.html. 

There is work in progress in IEEE 802. Juan Carlos is following it, and may have a good reference.

-- Christian Huitema

---

From: Bob Hinden <[email-masked]>
Date: Fri, 13 Jan 2017 08:16:21 -0800

Christian,

> On Jan 12, 2017, at 9:35 PM, Christian Huitema <[email-masked]> wrote:
> 

Thanks, I will review the info, and look forward to hearing from Juan Carlos.

Bob

---

From: Tim Chown <[email-masked]>
Date: Tue, 17 Jan 2017 15:20:07 +0000

Hi,

On 13 Jan 2017, at 01:33, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Jan 13, 2017 at 6:11 AM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
It will break on sites that choose a managed addressing policy (as
Tim told us they do at CERN). I wonder what Android users at CERN do?

Presumably they get IPv4 only and don't notice. The few that do, depending on their opinions, either ask their network admins to follow the best practices in RFC 7934 or go to http://b.android.com/32621 to complain about it. :-)

Yes, they only get IPv4.

As for the “petition”, that was marked low priority and closed three years ago, so I assume everyone has given up!

Back more directly on topic, addition of “stable” is +1 here too.

Tim