Subject: default-iids: Closing concern regarding stable address requirement

From: Fernando Gont <[email-masked]>
Date: Sun, 22 May 2016 16:07:39 -0400

Folks,

Lorenzo suggested this text:

   The recommendations in this document apply only in cases where
   implementations otherwise would have configured a stable IPv6 IID
   containing a link layer address. Configuring a stable IPv6 IID is
   OPTIONAL.

IMHO this goes one step further than what this I-D was meant to do (just
improve stable addresses), but I guess most of us (all?) agree that
there are scenarios where you might want to use e.g. temporary-addresses
*only*.

Is anyone opposed to adding the above text, suggested by Lorenzo?

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

---

From: Mark Smith <[email-masked]>
Date: Mon, 23 May 2016 08:27:48 +1000

> Is anyone opposed to adding the above text, suggested by Lorenzo?

I think it is OK.

I think it would be useful to add some text to say that temporary only
hosts needs some further work due to RFC4941 saying that temporary
addresses co-exist with the host's existing stable addresses.

Regards,
Mark.

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

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 23 May 2016 00:29:17 +0200

> On May 22, 2016, at 10:07 PM, Fernando Gont <[email-masked]> wrote:
> 
> Folks,
> 

WFM

Alissa

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 May 2016 10:10:57 +0900

>    containing a link layer address. Configuring a stable IPv6 IID is

Jinmei had some better text, IIRC. Jinmei?

---

From: 神明達哉 <[email-masked]>
Date: Mon, 23 May 2016 11:37:02 -0700

At Mon, 23 May 2016 10:10:57 +0900,

> Jinmei had some better text, IIRC. Jinmei?

My suggested text was this:

   The recommendations in this document apply only in cases where
   implementations otherwise would have configured a stable IPv6 IID
   containing a link layer address.  For example, this document does
   not change any existing recommendations concerning the use of
   temporary addresses as specified in [RFC4941], nor do the
   recommendations apply to cases where the link layer address is not
   stable (e.g., it is periodically randomized) in the first place,
   nor does it introduce any new requirements regarding when stable
   addresses are to be configured.  Thus, the recommendations in this
   document simply improve the security and privacy properties of
   stable addresses.

I've seen two responses to my suggestion, one from Fernando:
http://www.ietf.org/mail-archive/web/ipv6/current/msg24495.html

and the other from Ole:
http://www.ietf.org/mail-archive/web/ipv6/current/msg24512.html

And, basically, they didn't seem to be happy about it.  In the above
text I just tried to make the scope of this document super clear
(i.e., cases where the link-layer address is not stable are out of
scope of this document), but it looks like Fernando didn't even like
to mention it at all, or may even think we should explicitly recommend
against that:

> The root of this problem is reusing a link-yaer ID at layer-3. THat's
> bad, and we have to recommend against that.

If this is a very important point of this document, all I can say is
that this document should be revised to say this position explicitly
and that revised version will have to get wg consensus.

On the other hand, Ole seemed to say my additional text itself is out
of scope of this document:

> I don't think this document is the place to to clarify that there
> might be interfaces with only short-lived IIDs.

In a sense, I agree.  But as I said in my response, since this has
been a central point of controversy in this last call discussion, I
thought an explicit clarification on the specific case (that it's out
of scope of this document) was one promising way to move forward.

I don't know the general sense of the wg on my suggested text.  If
it's just deemed to be redundant or possibly out-of-scope but
otherwise acceptable while it makes some others much happier (on which
I'm quite sure) I think it's still worth considering.  But I'm not
pushing my specific agenda in proposing this text, so if the text
itself is so controversial I won't argue for it.

--
JINMEI, Tatuya

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 23 May 2016 19:34:02 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of [Tatuya Jinmei]

>> The root of this problem is reusing a link-yaer ID at layer-3.
>> THat's bad, and we have to recommend against that.
>
> If this is a very important point of this document, all I can say
> is that this document should be revised to say this position
> explicitly and that revised version will have to get wg consensus.

We seem to get continually dragged into the tangential discussion, out of scope, about temporary addresses.

My feeling is that the case against use of short-lived MAC addresses, in temp IP address IIDs, was not made convincingly. In part, because the IETF does not control how temp MAC addresses are created. So some of the assertions made might not be true. For example, in a multihomed host, do we know for sure that the temp MAC addresses would be identical for each interface?

So, for the purposes of this draft, I think we should only emphasize what it addresses, and not dwell on what it does not cover. In Section 1, the draft already says more than it needs to say, on tangential subjects. Plus, it also says:

   The recommendations in this document apply only in cases where
   implementations otherwise would have configured a stable IPv6 IID
   containing a link layer address.  That is, this document does not
   change any existing recommendations concerning the use of temporary
   addresses as specified in [RFC4941], nor does it introduce any new
   requirements regarding when stable addresses are to be configured.
   Thus, the recommendations in this document simply improve the
   security and privacy properties of stable addresses.

So, I'm not sure how to be more explicit than this. "If you have objections to the way temp addresses are formed, refer to the relevant documents," is in essence what the draft says.

Since we keep getting bogged down on temp addresses, in this draft, perhaps text should be subtracted rather than added. E.g., also from Section 1, this text might be leading people to go off on the tangential discussions:

   More generally, the reuse of identifiers that have their own
   semantics or properties across different contexts or scopes can be
   detrimental for security and privacy
   [I-D.gont-predictable-numeric-ids].  In the case of traditional
   stable IPv6 IIDs, some of the security and privacy implications are
   dependent on the properties of the underlying link-layer addresses
   (e.g., whether the link-layer address is ephemeral or randomly
   generated), while other implications (e.g., reduction of the entropy
   of the IID) depend on the algorithm for generating the IID itself.
   In standardized recommendations for IPv6 IID generation meant to
   achieve particular security and privacy properties, it is therefore
   necessary to recommend against embedding link-layer addresses in IPv6
   IIDs.

Perhaps that should be shortened to say more simply:

   More generally, the reuse of identifiers that have their own
   semantics or properties across different contexts or scopes can be
   detrimental for security and privacy
   [I-D.gont-predictable-numeric-ids].  In the case of traditional
   stable IPv6 IIDs, some of the security and privacy implications are
   dependent on the properties of the underlying link-layer addresses.
   In addition, the algorithm to produce the IID reduces the entropy
   by 16 bits, which may also be undesirable. It is therefore
   recommended against embedding link-layer addresses in IPv6 IIDs.

No MUST NOT, just a general recommendation. And only as relates to stable addresses.

Bert

---

From: Philip Homburg <[email-masked]>
Date: Tue, 24 May 2016 10:37:35 +0200

>itself is so controversial I won't argue for it.

The problem I have with this draft and the discussion surrounding the draft
is that it starts somewhere in the middle.

A particular device, say server or laptop, in a particular environment,
trusted, untrusted, etc. results in a set of requirements for what addresses
the device should have.

Then we can map those requirements to particular technologies.

Instead we describe and discuss a number of things we can do, but then it is
upto the operating system software vendor or the operator or the user to
figure out what goes where.

We create an endless maze of SHOULDs where everything is possible. But
too many options lead to non-experts getting lost.

So in my opinion, a default-iids document should start with set of example
configuration that map to a set of features that we want to support
and then to a set of IID options.

Then an implementor can start at the top, look up the type of device to
support and find what needs to be done.

For a selected class of devices, I'm a huge fan of using EUI-64 based IIDs.
I agree that in general EUI-64 based IIDs are bad, but we can just as
well write down when they make life easier.

---

From: [email-masked]
Date: Tue, 24 May 2016 10:50:37 +0200

Philip,

> well write down when they make life easier.

are you saying that you'd rather have seen a v6ops style document giving recommendations for what type of IIDs should be used for an enumerated set of scenarios?

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Tue, 24 May 2016 11:40:03 +0200

>are you saying that you'd rather have seen a v6ops style document giving 
>recommendations for what type of IIDs should be used for an enumerated 
>set of scenarios?

Yes. I think we need such a document. There are too many options to 
configure IIDs. 

And I think that would also structure the current discussion. I.e, what
requirements do we have with respect to addresses for mobile devices and
what technologies do we use for that.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 May 2016 18:45:26 -0400

On 05/23/2016 02:37 PM, 神明達哉 wrote:
>    addresses are to be configured.

DO you consider the scenario where a hsot configures an address for
multiple prefixes, using the same IID? -- But that's one possible
outcome if you allow link-layer identifiers in IPv6 addresses -- even if
they are andomized.

  Thus, the recommendations in this
>> bad, and we have to recommend against that.

Please see my comment above, besides Brian's example of two different
layer-3 protocols embedding link-layer addresses....

> and that revised version will have to get wg consensus.

Hasn't it always been the case of this document to recommend against
embedding link-layer addresses in the IPv6 IID?

> of scope of this document) was one promising way to move forward.

Your text -- modulo the text about randomized link-layer addresses --
looks good to me.

> itself is so controversial I won't argue for it.

Fine with me, modulo the link-lyer addresse stuff...

Thoughts?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 25 May 2016 17:39:41 -0400

> are you saying that you'd rather have seen a v6ops style document giving recommendations for what type of IIDs should be used for an enumerated set of scenarios?

SUch a document, whether inv6ops or 6man would be useful. BUt
default-iids is orthogonal to that. It improves stable addresses where
such addresses are to be used.

Since there *are* scenarios where stable addresses are required and/or
desirable (whether -only or in addition to temp addresses), the work in
this document is of value, and orthogonal to any further advice
regarding of when/where you do stable addresses and/or temp addresses.

Thanks,

---

From: [email-masked]
Date: Thu, 26 May 2016 10:23:12 +0200

> regarding of when/where you do stable addresses and/or temp addresses.

RFC7217 covers that.

Given the recent discussions on RFC4941, random MACs and on this document, I'm more and more leaning towards the opinion that we (as in the IETF) shouldn't have gotten into the business of trying to declare what people should put in the lower 64 bits. :-)

We cannot all IPv6 implementations non-compliant by removing section 4 of RFC2464 as this document proposes.

Thought experiment. What if we abandon this document, and instead start work on updates to the IPv6 over foo documents? 2464bis specifically.

Cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 26 May 2016 19:08:16 +1000

On 26 May 2016 at 18:23,  <[email-masked]> wrote:
>>> are you saying that you'd rather have seen a v6ops style document
giving recommendations for what type of IIDs should be used for an
enumerated set of scenarios?
> Given the recent discussions on RFC4941, random MACs and on this
document, I'm more and more leaning towards the opinion that we (as in the
IETF) shouldn't have gotten into the business of trying to declare what
people should put in the lower 64 bits. :-)

I think we should. What shouldn't have happened is embedding forms of layer
2 addresses in layer 3 IIDs.

> We cannot all IPv6 implementations non-compliant by removing section 4 of
RFC2464 as this document proposes.

I think "deprecated" would be a better term for them.

> Thought experiment. What if we abandon this document, and instead start
work on updates to the IPv6 over foo documents? 2464bis specifically.

Don't we try to decouple layer 2 and 3 as much as possible, so we can slot
in new layer 2s as they become available, and layer 3 hides those changes?

RFC6272, "Internet Protocols for the Smart Grid"

"2. The Internet Protocol Suite"

"2.1.3.1. Internet Protocol"
[...]

"The Internet layer provides a uniform network abstraction network
   that hides the differences between various network technologies.
   This is the layer that allows diverse networks such as Ethernet,
   802.15.4, etc. to be combined into a uniform IP network.  New network
   technologies can be introduced into the IP Protocol Suite by defining
   how IP is carried over those technologies, leaving the other layers
   of the IPS and applications that use those protocol unchanged."

RFC7217 creates that addressing abstraction for stable addresses, as well
as localising the IID meaning to a specific prefix, which is also the scope
of an IID for the purposes of sending or receiving packets. Doing it once
now means never having to do it again for IPv6-over-future-foo documents.

Regards,
Mark.

---

From: [email-masked]
Date: Thu, 26 May 2016 11:39:45 +0200

Mark,

> I think we should. What shouldn't have happened is embedding forms of layer 2 addresses in layer 3 IIDs.

it was convenient at the time.
it's still convenient in certain cases, but not as the default for _all_ devices.

> I think "deprecated" would be a better term for them.

I'm not even sure we should do that.
there are valid uses for the current scheme.
it's implemented, deployed, understood and well tested.
the company I work for have tens of IPv6 implementations and hundreds of different products with IPv6 stacks in them. it's unlikely I'm going to champion making a change from EUI-64 to 7217 in cases where it doesn't provide value.

there are 2^64 ways to generate an IID, we can only provide general advice.
for mobile devices it is clearly not a good idea to embed L2 addresses in L3 addresses.
but for those devices a lot of other things aren't good ideas either. if you really care about privacy I'm not quite sure if any of this would really help you, but oh well.

when we want to make recommendations that should apply to _all_ devices, that's when we get into trouble. that's incredibly hard to do, because the only answer we can agree on is: it depends.

> Don't we try to decouple layer 2 and 3 as much as possible, so we can slot in new layer 2s as they become available, and layer 3 hides those changes?
> 
> RFC7217 creates that addressing abstraction for stable addresses, as well as localising the IID meaning to a specific prefix, which is also the scope of an IID for the purposes of sending or receiving packets. Doing it once now means never having to do it again for IPv6-over-future-foo documents.

L2 and L3 are decoupled in the current model. an example of them being coupled would have been if we had used the IID to determine the MAC address instead of doing ND address resolution.

This is not an argument against 7217. I think the default should be to use 7217. If you want stable addresses. I don't want to make other schemes non-compliant. And I think we have to remember that these are just defaults. For SLAAC. People can and do configure IIDs any which way they like.

My point given that there is a level of uncomfortableness with this document was to try to do the reverse. Can we find some updates to 2464 there is consensus on?

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 26 May 2016 11:58:55 +0200

Le 26/05/2016 à 11:08, Mark Smith a écrit :
>
>
> On 26 May 2016 at 18:23,  <[email-masked]
> <mailto:[email-masked]>> wrote:
> document, I'm more and more leaning towards the opinion that we (as in
> the IETF) shouldn't have gotten into the business of trying to declare
> what people should put in the lower 64 bits. :-)
>>
>
>> Thought experiment. What if we abandon this document, and instead
> start work on updates to the IPv6 over foo documents? 2464bis specifically.
>>
>
> Don't we try to decouple layer 2 and 3 as much as possible, so we can
> slot in new layer 2s as they become available, and layer 3 hides those
> changes?

I can agree there can be a need to decouple layer 3 IDs from layer 2 
IDs.  One reason is this privacy concern.

Decoupling can be realized by offering a common interface between layer; 
and that's what IPv6-over-foo documents do: all link-layers look the 
same to an IP layer, because there is this interface described in an 
IPv6-over-foo document for each link-layer.

Such an interface should answer at least these questions:
- what is the MTU?  who fragments?
- what are the headers preceding and following the IP packet?
- how is the IID formed?
- how is a IP address mapped into that link-layer's address?
   (uni- and muti-cast).

Of these, only the IID formation has a privacy concern because of that 
layer2-in-3 aspect.

Without these multiple IPv6-over-foo documents the IP layer would not be 
that simple as it is.

> RFC7217 creates that addressing abstraction for stable addresses, as
> well as localising the IID meaning to a specific prefix, which is also
> the scope of an IID for the purposes of sending or receiving packets.
> Doing it once now means never having to do it again for
> IPv6-over-future-foo documents.

The notion of doing it once in a single place and impact positively many 
other parts of the system can be achieved with IPv6-over-Ethernet - most 
other IPv6-over-foo documents are more or less mirroring it.

Moreover, I would oppose discarding IPv6-over-foo documents.

The automaticity offered by an IPv6-over-foo tool in 
address-autoconfiguration is a very useful feature in IPv6 - it's great 
to have an IPv6 address there (LL) in the computer to start with, before 
thinking what address to manually configure, or what prefix to put in 
the RA.

It seems that if we used a random number in the IID (rather than a IEEE 
MAC address) then the privacy concern would be eased a bit.

But still the automaticity in address auto-configuration would be thus 
offered.

Additionally, there are other IDs shared between IPv6 addresses (see 
address mapping sections in IPv6-over-foo), which dont have privacy 
concerns.  I am thinking for example of the IDs in the multicast addresses.

As such, my thought is that updating RFC2464 to address the privacy 
concern in the IID can be a good idea.

Alex

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 May 2016 18:13:50 -0400

Hi, Ole,

On 05/26/2016 04:23 AM, [email-masked] wrote:
>> 
>> Since there *are* scenarios where stable addresses are required
>> and/or desirable (whether -only or in addition to temp addresses),
>> the work in this document is of value, and orthogonal to any
>> further advice regarding of when/where you do stable addresses
>> and/or temp addresses.
> 
> RFC7217 covers that.
> 
> document, I'm more and more leaning towards the opinion that we (as
> in the IETF) shouldn't have gotten into the business of trying to
> declare what people should put in the lower 64 bits. :-)

I disagree. For two different reasons:

1) We have already done so, recommending a, say, not so nice approach.
Hence we need to fix that.

2) At the end of the day, the folk implementing IPv6 has to make a
decision. And if we don't provide good advice, we have to plan for the
worst.

> 4 of RFC2464 as this document proposes.

We're changing the default to something that is sec&privacy better.

We cannot really claim that mass survelliance and the like is a threat,
and then keep this in "'cause we don't want to update the code of
existing implementations".

> start work on updates to the IPv6 over foo documents? 2464bis

default-iids already does this, for RFC2464 and other documents.

Thanks,

---

From: 神明達哉 <[email-masked]>
Date: Thu, 26 May 2016 16:22:21 -0700

At Mon, 23 May 2016 18:45:26 -0400,
Fernando Gont <[email-masked]> wrote:

> multiple prefixes, using the same IID?

Not really, partly because that's not my point in my response to the
WGLC.  I can answer that if you want to know what I think about it,
but I'll defer it to some different opportunity so we won't be
distracted about my main point.

> But that's one possible

[...]

> layer-3 protocols embedding link-layer addresses....

As I already explained in the cited text, my suggestion was to attempt
of making this document less controversial and, really, only focus on
"cases where implementations otherwise would have configured a stable
IPv6 IID containing a link layer address", explicitly stating other
cases are out of scope.  Since randomized link-layer addresses
wouldn't be considered stable, they should be obviously out of scope
of the document, hence my suggestion.

But (to me at least) your response actually proposes expanding (or
changing) the scope of the document.  Instead of:

   The recommendations in this document apply only in cases where
   implementations otherwise would have configured a stable IPv6 IID
   containing a link layer address.

it should actually be stated:

   The recommendations in this document apply only in cases where
   implementations otherwise would have configured an IPv6 IID
   containing a link layer address.

(i.e, whether it's stable or not is not the point).

That's certainly one option, but I'd expect this will involve a lot
more discussions.  If you don't mind that, I'm not opposed to that; we
should simply conclude it doesn't pass the WGLC, clearly re-stating
the actual intent of the draft (i.e., it's not about stability but
about embedding link-layer address in IPv6 addresses) with rationale,
discuss the matter to death in the wg, then hopefully have another
WGLC.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 May 2016 19:37:22 -0400

Hi, Jinmei,

> distracted about my main point.

You seem to be arguing against we saying that nodes must not embed
link-layer addresses in the IID (or at least asking us to explain
ourselves).

Would it help if we, say, explicitly include Brian's example of
multiple-layer-3 protocols and also note that if MAC addreses are
embedded, then addresses for multiple prefixes would employ the same
IID, and that that allows for traffic correlation?

> of the document, hence my suggestion.

Ok. Now I see where you were coming from. If anything, maybe we could
tweak your text and say that randomized MAC addresses would lead to
non-stable addresses, and hence their use is considered out of the scope
for this document? (I guess I could live with that)

> more discussions.

We certainly want to focus on stable addresses here, so yes I agree with
you. Please see my comment above -- I think we're starting to converge...

Thoughts?

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Fri, 27 May 2016 10:51:49 +1000

Hi Ole,

> > >> Since there *are* scenarios where stable addresses are required
and/or
> it was convenient at the time.

I completely understand the convenience of it, as I first operated IPX
before operating  IPv4. (From that experience, my view is that IPv6 has to
at least attain the operational convenience and usability that IPX and
AppleTalk were providing around 25 years ago.)

> it's still convenient in certain cases, but not as the default for _all_
devices.

Why not?

We should pick safe defaults. In terms of privacy, I think this is the
safest default for stable addresses. I also think it satisfies stable
address use cases that I can think of (mainly server and router interfaces).

I think it is better to avoid options, however an option to switch them off
or override them would not conflict with these being the out-of-the-box
default.

> the company I work for have tens of IPv6 implementations and hundreds of
different products with IPv6 stacks in them. it's unlikely I'm going to
champion making a change from EUI-64 to 7217 in cases where it doesn't
provide value.

I'd be curious to know what those cases are, and how RFC7217s might reduce
value.

One specific case related to what your company builds is the criticism that
swapping a router interface module results in a different LL address. They
address that issue by using either static LLs or globals (tying all of
their internal next hop addresses to an external prefix, something I think
should be avoided).

RFC7217s can automate LL address generation on routers that doesn't have
this issue, as the Net_Iface parameter can be something that is stable
across router interface swaps e.g. stable Ifindex or stable
slot/module/interface location ID.

Some people would still do static router interface addressing if RFC7217s
were available, however it would now be more of a choice of wanting to
rather than having to to achieve router interface address stability.

> there are 2^64 ways to generate an IID, we can only provide general
advice.

I think we go a little further than that and always try to recommend good
general defaults that are safe. In the past it has probably was just
operationally safe.

More recently we've been making security safe recommendations (e.g.
security considerations section mandatory).

Now I think we have to consider whether it is necessary to make a privacy
safe default recommendation. I think in this case we do, because these
addresses can be exposed to parties who might seek to violate privacy -
even LLs on public access networks such as cafe Wifi networks.

> but for those devices a lot of other things aren't good ideas either. if
you really care about privacy I'm not quite sure if any of this would
really help you, but oh well.

I think of it this way - it doesn't have to be perfect, just as long as it
is usefully better.

For stable address use cases, I think these addresses are better for
privacy than embedded MAC address IIDs that don't change across networks or
prefixes. They of course don't solve all privacy issues that can occur at
the IPv6 and other layers of the stack.

> when we want to make recommendations that should apply to _all_ devices,
that's when we get into trouble. that's incredibly hard to do, because the
only answer we can agree on is: it depends.
> > RFC7217 creates that addressing abstraction for stable addresses, as
well as localising the IID meaning to a specific prefix, which is also the
scope of an IID for the purposes of sending or receiving packets. Doing it
once now means never having to do it again for IPv6-over-future-foo
documents.
>
> L2 and L3 are decoupled in the current model. an example of them being
coupled would have been if we had used the IID to determine the MAC address
instead of doing ND address resolution.

Agree - coming from a distant past IPX background, I actually found the use
of MAC addresses in IIDs and continued use of ND initially confusing. I
think that shows that the choice of MAC based IIDs was purely a choice of
convenience, as there was an optimisation opportunity that wasn't taken.
(For those reading who don't know, IPX doesn't do any form of address
resolution, it takes the destination node ID in the IPX packet and uses it
as the layer 2 destination address).

> This is not an argument against 7217. I think the default should be to
use 7217. If you want stable addresses. I don't want to make other schemes
non-compliant. And I think we have to remember that these are just
defaults. For SLAAC. People can and do configure IIDs any which way they
like.
>
> My point given that there is a level of uncomfortableness with this
document was to try to do the reverse. Can we find some updates to 2464
there is consensus on?

I suppose the trouble is that there are all the other Ipv6 over foo
documents. Does updating RFC2464 make it an unexplained special case, or
does it make all the other IPv6 over foo document ignored or forgotten
cases?

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 27 May 2016 13:25:49 +0900

> I'd be curious to know what those cases are, and how RFC7217s might reduce
Here's a case where RFC7217 reduces value: an enterprise network that keeps
track of machines by MAC address and  hostname generates AAAA records
automatically for the EUI-64 address.

RFC7217 breaks that because you'd have to either predict the address -
which relies on knowing the implementation and ensuring that every machine
boots with the same secret key - or scrape the address once the machine has
booted, which introduces a bootstrapping problem. DHCPv6 could fix this -
assuming the implementations don't default to LL+T DUIDs, which can't be
predicted - but it involves provisioning and running new servers that might
not exist. Dynamic DNS updates could also fix that, but it also requires
building infrastructure that might not exist.

Privacy concerns can be almost completely mitigated by making all machines
run 4941 by default. I say "almost" because I'm sure Fernando can come up
with a contrived situation where the address will leak, but the enterprise
might have thought of those scenarios and decided to mitigate those
situations. One way to mitigate the impact of some of those situations
would be to drop all packets to/from EUI-64 addresses outside the
enterprise network.

---

From: [email-masked]
Date: Fri, 27 May 2016 08:04:34 +0200

Mark,

[...]

> We should pick safe defaults. In terms of privacy, I think this is the safest default for stable addresses. I also think it satisfies stable address use cases that I can think of (mainly server and router interfaces).

agree.

> I think it is better to avoid options, however an option to switch them off or override them would not conflict with these being the out-of-the-box default.

agree.

> I'd be curious to know what those cases are, and how RFC7217s might reduce value.
> 
> One specific case related to what your company builds is the criticism that swapping a router interface module results in a different LL address. They address that issue by using either static LLs or globals (tying all of their internal next hop addresses to an external prefix, something I think should be avoided).

for the implementations I'm aware of a block of MAC addresses (say about a 1000) is tied to the node itself, interfaces are assigned MAC addresses out of the block, so at least in theory changing an interface doesn't necessarily lead to a change in MAC address.

> RFC7217s can automate LL address generation on routers that doesn't have this issue, as the Net_Iface parameter can be something that is stable across router interface swaps e.g. stable Ifindex or stable slot/module/interface location ID.
> 
> Some people would still do static router interface addressing if RFC7217s were available, however it would now be more of a choice of wanting to rather than having to to achieve router interface address stability.
> 
> I think we go a little further than that and always try to recommend good general defaults that are safe. In the past it has probably was just operationally safe.

I agree 7217 should be the default.
I would have been a lot more comfortable if we had had experience with it.
My point was that removing the 2464 section 4 is problematic for existing implementations.
EUI-64 should be an available option if anyone wants that, just not the default.
It is too early to deprecate.

> More recently we've been making security safe recommendations (e.g. security considerations section mandatory).
> 
> Now I think we have to consider whether it is necessary to make a privacy safe default recommendation. I think in this case we do, because these addresses can be exposed to parties who might seek to violate privacy - even LLs on public access networks such as cafe Wifi networks.

on cafe WIFI networks you must have a random MAC as well.

> I think of it this way - it doesn't have to be perfect, just as long as it is usefully better.
> 
> For stable address use cases, I think these addresses are better for privacy than embedded MAC address IIDs that don't change across networks or prefixes. They of course don't solve all privacy issues that can occur at the IPv6 and other layers of the stack.

I'm not sure I agree with that.
What's the main use case for stable addresses? Typically because there is a service on the host that needs to be registered in DNS. Then instead of monitoring the address just monitor changes in the DNS.

[...]

> I suppose the trouble is that there are all the other Ipv6 over foo documents. Does updating RFC2464 make it an unexplained special case, or does it make all the other IPv6 over foo document ignored or forgotten cases?

Sorry I was unclear.
My suggestion was to do a bottoms-up approach by changing all the IPv6 over foo documents. Those are on the list to advance anyway. But instead of trying to do all of them at once, start with 2464.

Cheers,
Ole

---

From: 神明達哉 <[email-masked]>
Date: Fri, 27 May 2016 10:36:35 -0700

At Thu, 26 May 2016 19:37:22 -0400,

> for this document? (I guess I could live with that)

That works for me.

> you. Please see my comment above -- I think we're starting to converge...

Yes, this (and updating other part of the doc along with this sense)
will address my point perfectly: the resulting text would be much
clearer on the scope and more obviously consistent with what the
authors said about the scope.

> link-layer addresses in the IID (or at least asking us to explain

Not necessarily, but I guess we are now on the same page, so I won't
explain more on this.

> IID, and that that allows for traffic correlation?

Same here, but: this, and stating more clearly that this is not only
about stable addresses but rather mainly about embedding link-layer
addresses (stable or not), then this will be another way to address my
point.  But I thought this will be much more controversial and require
another round of WG discussions.  So, assuming the authors' intent was
really about stable cases, I suggested the less controversial
approach.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 May 2016 09:10:38 +1200

On 27/05/2016 16:25, Lorenzo Colitti wrote:
> track of machines by MAC address

Yes,standard practice on many sites (that will, I expect, forbid MAC address
randomization).

> and  hostname generates AAAA records

Why? Clients don't need AAAA records. Servers have stable addresses anyway,
usually with a small-integer IID.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 28 May 2016 15:25:32 +0900

On Sat, May 28, 2016 at 6:10 AM, Brian E Carpenter <
[email-masked]> wrote:

> Why? Clients don't need AAAA records. Servers have stable addresses
> anyway, usually with a small-integer IID.
>

DNS records for client machines can be useful if you want to manage them,
run development webservers on them, SSH into them, etc.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 29 May 2016 16:18:29 +1200

> run development webservers on them, SSH into them, etc.

Fair enough, for campus deployments, but of course there's no need to bind
that requirement to EUI-64.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 29 May 2016 13:49:15 +0900

Actually there is: the IPv6 addresses are predictable, so DNS records can
be generated without having to build any additional infrastructure. As I
said in the email you quoted:

=====
=====
On 29 May 2016 1:18 pm, "Brian E Carpenter" <[email-masked]>

---

From: joel jaeggli <[email-masked]>
Date: Sun, 29 May 2016 07:24:21 +0200

On 5/28/16 8:25 AM, Lorenzo Colitti wrote:
> On Sat, May 28, 2016 at 6:10 AM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> DNS records for client machines can be useful if you want to manage
> them, run development webservers on them, SSH into them, etc.

There's also this thing called dhcpv6 for applications where the users
or administrators prefer centrally managed address assignment,

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 29 May 2016 15:01:51 +0900

> or administrators prefer centrally managed address assignment,

Yep. Like I said, that one requires building and maintaining infrastructure
that might not exist. Also, the addresses are not predictable unless the
clients default to using LL DUIDs instead of LL+T.

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 29 May 2016 09:13:38 +0200

Sent from my iPhone

> On May 29, 2016, at 08:01, Lorenzo Colitti <[email-masked]> wrote:
> 
> 
> Yep. Like I said, that one requires building and maintaining infrastructure that might not exist. Also, the addresses are not predictable unless the clients default to using LL DUIDs instead of LL+T.
> 
Or use hostid because devices may have multiple interfaces anyway

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 May 2016 08:18:09 +1200

> Or use hostid because devices may have multiple interfaces anyway

So, I just don't see how we can claim to dictate any kind of general default
or BCP in this area. But I don't seee that draft-ietf-6man-default-iids does
that. Maybe it should be toned down to a SHOULD level, e.g.

Abstract

   This document changes the recommended scheme for generating stable
   Interface Identifiers with SLAAC to that specified in RFC7217, and
   recommends against embedding link-layer addresses in IPv6 Interface
   Identifiers.  It formally updates RFC2464, RFC2467, RFC2470, RFC2491,
   RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338,
   RFC4391, RFC5072, and RFC5121 accordingly.

and similar changes in the body of the draft.

Again, the 'bug' in 4941 is a separate issue.

   Brian

---

From: [email-masked]
Date: Mon, 30 May 2016 08:39:56 +0200

> Again, the 'bug' in 4941 is a separate issue.

agree, I think there is agreement that the default generation mechanism for stable addresses should be 7217.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 30 May 2016 15:58:31 +0900

On Mon, May 30, 2016 at 5:18 AM, Brian E Carpenter <
[email-masked]> wrote:

>    Identifiers.  It formally updates RFC2464, [...]

If this document makes RFC7217 IIDs a SHOULD, how should it formally update
the IPv6-over-foo RFCs? Currently it just blasts away any/all text in them
that talks about IIDs. If it's just a SHOULD, then it can't do that any
more.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 May 2016 11:55:46 +1200

> that talks about IIDs. If it's just a SHOULD, then it can't do that any

Yes, I'm suggesting a compromise which adds a SHOULD-level alternative to all
those over-foos, rather than making a MUST-level change. That would require
some wordsmithing in the body of the draft, as well as in the Abstract.

   Brian