Subject: Re: I-D Action: draft-gont-6man-deprecate-eui64-based-addresses-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Nov 2013 07:59:20 +1300

Assuming we switch to a SHOULD NOT:

People need to remember that in the IETF, SHOULD NOT means
"SHOULD NOT unless you have a valid technical reason."

Yes, there are surely use cases where using Modified EUI-64
is technically useful. That door should be left open, as Erik
said at the microphone today, and SHOULD NOT does leave it
open.

Like all privacy-related issues, we may end with a requirement
that Modified EUI-64 MUST be configured off by default.

A question for me is whether we REQUIRE implementations
to support Modified EUI-64 as a configurable option. I don't
see a strong argument for that, although it might turn up
as an RFP requirement.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Mon, 4 Nov 2013 19:20:40 +0000

> see a strong argument for that, although it might turn up

So how is the type of address used toggled/selected?  How does that configurable option work?

Note that what a vendor wants, and what a site wants, may well be different.

We have at least, for the global address...

a) Modified EUI-64 (as per RFC)
b) Stable privacy (draft-ietf-6man-stable-privacy-addresses-14)
c) tokenised ID (draft-chown-6man-tokenised-ipv6-identifiers-02)
d) no global enabled (if device is solely a client with 4941 enabled)

Servers using EUI-64 is interesting. We’ve avoided that to avoid renumbering on hardware changes, and generally have manually configured addresses for servers.  On VM platforms you may be able to just randomly generate MAC addresses…

Tim

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Nov 2013 19:34:01 +0000

Hi Ole,

The answer to your question about the 1280/1500 MTUs and tunnels is
in the list archives: 

http://www.ietf.org/mail-archive/web/ipv6/current/msg19051.html

Thanks - Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Nov 2013 10:06:21 +1300

> So how is the type of address used toggled/selected?  How does that configurable option work?

That's an implementation issue. I'm not actually pushing for
this, but I can imagine some customers wanting it.

> Note that what a vendor wants, and what a site wants, may well be different.

Yes, but my understanding is that the customer is always right.

> Servers using EUI-64 is interesting. We’ve avoided that to avoid renumbering on hardware changes, and generally have manually configured addresses for servers.  On VM platforms you may be able to j…

I agree. There isn't, as far as I can see, any value in having
an opaque IID for a server, so any stable value seems reasonable.
(But see RFC 6866).

    Brian

---

From: Tim Chown <[email-masked]>
Date: Mon, 4 Nov 2013 21:14:54 +0000

> this, but I can imagine some customers wanting it.

We’ve seen RA option drafts put forward for similar things (and be rejected…).

> an opaque IID for a server, so any stable value seems reasonable.

So is it about the role of the device?

Client only 
Provides services to devices in same subnet
Provides services to devices in other subnets
Provides services globally 

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Nov 2013 10:26:38 +1300

> On 4 Nov 2013, at 21:06, Brian E Carpenter <[email-masked]> wrote:

<snip>

> Provides services globally 

Good point. I'd say that the first one needs an opaque IID for
privacy reasons, the next two will be fenced off by the site
firewall anyway, and fourth one just needs a stable value
and a stable DNS entry. (Typically the fourth one will be
in a DMZ in a large enterprise anyway.)

     Brian

---

From: Tim Chown <[email-masked]>
Date: Mon, 4 Nov 2013 21:30:17 +0000

On 4 Nov 2013, at 21:26, Brian E Carpenter <[email-masked]> wrote:

> privacy reasons,

Or it simply only has a temporary address for initiating communications. When I look at our NMS for my own office desktop, the only addresses seen from it are global IPv4, link-local IPv6 and a “few” RFC4941 temporary addresses.  Even though it has an EUI-64 global assigned, it doesn’t use it.  So it might as well not generate one if it remains client only.

> the next two will be fenced off by the site

Tim

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Nov 2013 12:24:10 -0800

Hi, Brian,

> Assuming we switch to a SHOULD NOT:

FWIW, and as previously noted, I'm fine with that.

> see a strong argument for that, although it might turn up

I think that, if anything, we could state "MAY support"?

But since we're saying "SHOULD NOT do modified eui-64", it's kind of
implicit that supporting it is kind of optional (only if you mean to go
against the aforementioned "SHOULD NOT")?

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Nov 2013 14:13:01 -0800

> an opaque IID for a server, so any stable value seems reasonable.

THere is: e.g. preventing device-specific exploitation, and preventing
an attacker from quickly finding all servers hosted by a specific ISP.

Thanks,

---

From: Scott Brim <[email-masked]>
Date: Mon, 4 Nov 2013 14:13:38 -0800

> against the aforementioned "SHOULD NOT")?

Have the courage of your conviction. If one is SHOULD NOT, the other is
SHOULD. With explanations.

---

From: Ole Troan <[email-masked]>
Date: Mon, 4 Nov 2013 23:29:43 +0100

<nohat>

> see a strong argument for that, although it might turn up

it seems I was in the rough for the hum against adopting this document today.

my reason was, that I think it is a policy choice which address(es) to use, and that it is
none of the IETF's business. I also think we should be cautious about changing fundamental parts of IPv6 addressing at this point.

that said, I believe we have certifications tests requiring a compliant IPv6 host stack to do SLAAC with an interface-id
based on EUI-64. I'm all for fixing that.
instead of jumping on the deprecation "gun", I'd rather see us develop a BCP with recommendations of what address type to use when. and I'd like to see input from apps people about the feasibility of this as well.

in any case I think we should see implementations and deployment before talking about deprecating EUI-64 based IIDs.

cheers,
Ole

</nohat>

---

From: Tim Chown <[email-masked]>
Date: Mon, 4 Nov 2013 22:39:32 +0000

> it seems I was in the rough for the hum against adopting this document today.

Yours was the loudest hum though, by some way… :)

> in any case I think we should see implementations and deployment before talking about deprecating EUI-64 based IIDs.

I think there’s a lot to be said for the “build it and they will come” approach.  Standardise stable privacy addresses.  Promote their merits in BCP documents, and Modified EUI-64 should slowly fade away.

If the “deprecate EUI-64” were rephrased to be a BCP on addressing, which may include some related topics, I think it would be far easier to support.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Nov 2013 15:03:59 -0800

> SHOULD. With explanations. 

One thing doesn't implied the other. Or does it?

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 04 Nov 2013 15:12:23 -0800

Hi, Ole,

On 11/04/2013 02:29 PM, Ole Troan wrote:
> my reason was, that I think it is a policy choice which
> address(es) to use, and that it is none of the IETF's business.

But we currently mandate Modified EUI-64. Besides, an implementer
needs guidance on the way to go.

> I also think we should be cautious about changing fundamental parts
> of IPv6 addressing at this point.

In this respect, I'd not that one of the most widely deployed
operating systems (Microsoft Windows) has deviated from Modified
EUI-64 IIDs for years now.

> that said, I believe we have certifications tests requiring a 
> compliant IPv6 host stack to do SLAAC with an interface-id based
> on EUI-64. I'm all for fixing that. instead of jumping on the 
> deprecation "gun",

My reading of the discussion is that we wouldn't be deprecating
Modified EUI-64, but rather making stable-privacy the default (which
you can override to use MODIFIED eui-64).

> I'd rather see us develop a BCP with recommendations of what
> address type to use when. and I'd like to see input from apps
> people about the feasibility of this as well.

I believe that's an interesting and valuable topic, but pretty much
orthogonal.

> in any case I think we should see implementations and deployment 
> before talking about deprecating EUI-64 based IIDs.

It looks like we'd not be deprecating them, but rather changing what's
the default scheme that we should use for IIDs.

Cheers,

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Nov 2013 19:22:18 -0500

Brian E Carpenter <[email-masked]> wrote:
    > People need to remember that in the IETF, SHOULD NOT means "SHOULD NOT
    > unless you have a valid technical reason."

    > Yes, there are surely use cases where using Modified EUI-64 is
    > technically useful. That door should be left open, as Erik said at the
    > microphone today, and SHOULD NOT does leave it open.

+1.

And, just to be clear, I think that everyone who prefers SHOULD NOT rather
than MUST NOT, also wants the default on all commodity machines that interact
with humans (laptops, desktops, smartphones, but not servers...) to do that.

    > Like all privacy-related issues, we may end with a requirement that
    > Modified EUI-64 MUST be configured off by default.

Assuming that there is a user interface other than a network, then I agree.
If it's a light bulb, there is no user interface.  Further, after the light
bulb joins the network (which it has to use it's full EUI-64 to do), then
it gets a new PAN controller allocated 16-bit MAC for actual traffic.
(I also hope that my light bulbs are not posting to facebook directly)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Nov 2013 13:15:50 +0100

Fernando,

<no-hat>

> needs guidance on the way to go.

I think there is a terminology issue here. _any_ 64 bit interface identifier in IPv6 is a Modified EUI-64 format interface identifier.
see http://tools.ietf.org/html/rfc4291#appendix-A

that includes a manually configured interface identifier, one with a serial number in it,
or the LocalTalk address for that matter.

implementers know their products much better than we do, I think the IETF should be careful in thinking it can specify products.

> EUI-64 IIDs for years now.

sure, that's still a Modified EUI-64.

> you can override to use MODIFIED eui-64).

I think we have a set of ways to generate interface identifiers, and we should give guidance
for how they are best used. that includes guidance to host implementers, applications developers etc.

> I believe that's an interesting and valuable topic, but pretty much

I think it would be quite callous of us to claim we have solved the "privacy problem", by
just deprecating hardware identifier based interface identifiers.

> the default scheme that we should use for IIDs.

I think draft-ietf-6man-ipv6-address-generation-privacy-00 is sufficient for that.

</nohat>

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Nov 2013 04:24:37 +1300

> see http://tools.ietf.org/html/rfc4291#appendix-A

Well yes, except that we are now in the process of standardising the
observation that _any_ 64 bit IID is an opaque string, which nullifies
that aspect of 4291.

    Brian

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Nov 2013 20:36:46 +0100

> Besides what Brian noted, I'd note that we (IETF) currently tell them to create such identifiers by embedding the underlying link-layer address.
> 
> It's not that all vendors came up with such idea themselves.
> 
> And we're trying to provide a more better recommendation that avoid the security/privacy issues we've discussed. That's it.

good, you don't think draft-ietf-6man-ipv6-address-generation-privacy-00 recommendation good enough?

more importantly, do people think we need to update RFC2464?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Nov 2013 21:40:51 +0100

Fernando,

> That I-D is informational. The recommendation to embed Mac addresses is std track. So I don't follow.
> 
> IETF-wise we're currently telling people to embed their MAC address in their ipv6 addresses. That's bad advise, and helps (among other things) tracking by even folks without the money or power the NSA has.

what I dislike most about this line of argument is that it seems implied that randomising your bottom 64 bits will solve the problem of IP address tracking. I'm typing this behind two network prefixes that I expect to have lifetimes matching the time frame I have a contract with my ISPs...

while I think we agree that hardware based IIDs shouldn't be the default for all devices, the choice of address is still a policy choice.

this isn't a problem we can solve. we can make it better, and I'm all for that, but to solve it we need something else than IPv6.

anyway, I don't quite see how we can do this without revising 2464 and friends.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Nov 2013 10:31:26 +1300

> more importantly, do people think we need to update RFC2464?

Not much. I really hate to keep repeating myself but I think this (and the
companion RFCs for Token Ring and FDDI, if we care) are all covered by
the "If" in draft-ietf-6man-ug-04:

   "For all unicast addresses, except those that start with the binary
    value 000, Interface IDs are required to be 64 bits long. If derived
    from an IEEE MAC-layer address, they must be constructed in Modified
    EUI-64 format."

However, 2464 and its cousins say

   The Interface Identifier for a <foo> interface is based
   on the EUI-64 identifier [EUI64] ...

and to be compatible with a SHOULD NOT deprecation they should say

   The Interface Identifier for a <foo> interface may be based
   on the EUI-64 identifier [EUI64] ...

Also RFC 6434 points to 2464 etc.

These points do need to be mentioned in the -deprecate- draft, IMHO.

Incidentally, we've never even bothered to write
"Transmission of IPv6 Packets over IEEE 802.11 networks".
(802.11 is not part of 802.3 and is not mentioned in 2464.)

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Nov 2013 05:27:45 +0100

Le 06/11/2013 22:31, Brian E Carpenter a écrit :
>>> Besides what Brian noted, I'd note that we (IETF) currently tell
>>> them to create such identifiers by embedding the underlying
>>> link-layer address.
>>>
>>> And we're trying to provide a more better recommendation that
>>> avoid the security/privacy issues we've discussed. That's it.
>>
>> good, you don't think
>> draft-ietf-6man-ipv6-address-generation-privacy-00 recommendation
>> good enough?
>>
> Not much. I really hate to keep repeating myself but I think this
> (and the companion RFCs for Token Ring and FDDI, if we care) are all
> covered by the "If" in draft-ietf-6man-ug-04:
>
> The Interface Identifier for a <foo> interface is based on the EUI-64
> identifier [EUI64] ...
>
> The Interface Identifier for a <foo> interface may be based on the
> EUI-64 identifier [EUI64] ...
>

I tend to agree with the points above.

> Incidentally, we've never even bothered to write "Transmission of
> IPv6 Packets over IEEE 802.11 networks". (802.11 is not part of 802.3
> and is not mentioned in 2464.)

Yes, and, when writing the IPv6-over-80211p individual proposal looking
for a home, we discovered by surprise that there is an intermediate
layer in the wireshark dumps ('Ethernet Adaptation Layer' would one dub
it?) xforming between Ethernet II and 802.11 headers.

An IPv6-over-80211 document would be good to cover many more specific
links like 802.11a/b/g/n/p even the 802.11ac at 1Gbps in current Samsung
smartphones (no affiliation).

Alex

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 06 Nov 2013 20:28:16 -0800

Hi, Brian,

> These points do need to be mentioned in the -deprecate- draft, IMHO.

Is there any change we'd need to apply to our I-D? If so, what would
that change be?

Thanks!

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Nov 2013 07:46:00 +1300

Good morning Fernando,

> Is there any change we'd need to apply to our I-D? If so, what would

Well, in the worst case you end up with something like this:

Updates: 2464, 2467, 2470, 2492, 2497, 2590, 3146, 3831, 4291, 4338, 4944, 5121, 6434

and the corresponding details in the text. Many IPv6-over-foo RFCs
need to be checked to see if they mandate Modified EUI-64 based on
hardware addresses (or equivalent) and if it matters.

I just checked 4944 and it uses 'may' not 'must' so in fact it's
OK, but all of them need to be checked, and I might have missed some.

Ideally there would also be a statement in RFC 6434 about this too,
because it points people directly to 2464 etc. You could do a formal
"updates" for that but maybe it can just wait for 6434bis?

   Brian

    Brian

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Fri, 15 Nov 2013 14:24:57 +0100

> in a DMZ in a large enterprise anyway.)

I think some security folks would like to go one step further than
"global" granularity e.g. by AS-number of the source traffic.

If you have a banking front end application for example, you might well
want users in your home country (with strong law enforcement) to be able
to connect to one service, whilst travelling users (in countries with a
less-than stellar reputation in following up on internet crime) are
directed to another.

We have DNS views to accomplish such things, but rotating IIDs, or use
of opaque IIDs, on servers could provide of some benefit in avoiding
DDoS impact e.g. for scripted attacks using hard coded targets.

-- 
Regards,
RayH