RE: 6MAN Adoption call on draft-gont-6man-deprecate-eui64-based-addresses-00

[Greg Daley <[e-mail]>]

Dear WG chairs & 6man, 

I think that changing the _default_ behaviour away from EUI-64/MAC should be undertaken since we have a number of privacy preserving schemes which are feasible today without it.

I've noted and support most of the concerns of Jean-Michel, Ole, Ralph and others regarding operational flexibility.

There is a significant advantage in testing a platform with MAC based addressing, and I think that it is useful to retain the capability to use the addresses in some cases (especially for Link-Local, or test scenarios).

I do not think that the current draft revision reflects every case, and if it is adopted the treatment for EUI-64 would likely require:

1/ Discussion of EUI-64/MAC behaviour (were it retained in any flavour, with SHOULD NOT be used by default, MAY be used but SHOULD be configurable).
2/ Be clear that any of the (global) privacy preserving addressing schemes (4941, stable and CGA) are equivalent, but defaulting to one for minimum compliance when EUI-64/MAC not in use.
3/ Consideration for Link-Local addresses, and low powered communication schemes. i.e. does not apply to 6lowpan.

In sensor networks particularly, there may be no specific end-user tied to a device: so why would we preclude use of a functional address format for the sake of privacy?

So my response is that I have no objection to this being adopted as a working-group document, but I'm interested to make sure that the document doesn't go past WG stage without addressing some of the key issues above.

Greg Daley
[e-mail]
[phone]


From: ipv6 [mailto:[e-mail]] On Behalf Of Jean-Michel Combes
Sent: Tuesday, 26 November 2013 4:14 AM
To: Ole Troan
Cc: 6man Chairs; 6man WG
Subject: Re: 6MAN Adoption call on draft-gont-6man-deprecate-eui64-based-addresses-00

Hi,
I don't support the adoption of this document as WG document in its current format.
o "Nodes MUST NOT employ IPv6 address generation schemes that embed the underlying hardware address in the Interface Identifier."
At first, as Ole said, privacy is policy and I don't see why IETF should dictate its rules to a network admin. If I want to set up an IPv6 node, in _my_ network, using SLAAC with EUI-64, it is my decision (BTW, maybe based on my security policy).
IMHO,  
- "MUST NOT" should be replaced by "SHOULD NOT"
- Title should be replaced by "Recommendations for generation of IPv6 IIDs"
- Intended status should be replaced by "Informational"

o "Nodes SHOULD implement and employ [I-D.ietf-6man-stable-privacy-addresses] as the default scheme"
Why should I employ, by default, this method? Why not RFC4941 based one? Why not CGA? Why not a proprietary one?
IMHO, this sentence should be replaced by "Nodes SHOULD implement and employ alternative schemes providing a better privacy like [I-D.ietf-6man-stable-privacy-addresses], [RFC4941] and [RFC3972]."
Best regards,
JMC.


2013/11/21 Ole Troan <[e-mail]>
<nochair>

to give my reasons for the hum against during the meeting.

- privacy (and security) are policy. I think it is unlikely that the IETF is prescient enough to get this right for all cases
- I think draft-ietf-6man-ipv6-address-generation-privacy-00 is enough to explain the privacy considerations to give
  implementors and users enough background to make a qualified choice
- deprecating EUI-64 based interface-identifiers is way too strong, there are many cases where those are unproblematic to use

I do think there is a problem with the IPv6 over Foo documents (e.g. RFC2464) requiring the interface-ids based on EUI-64,
and leading to certification tests requiring implementations supporting it.

I would be much more supportive of a document that updated those documents stating that there are alternative
ways of generating the interface-id, and refer to the generation-privacy document for considerations.
it could have text stating that unless there are link-specific considerations, stable privacy addresses should be the default interface-id for addresses larger than link-local scope.

cheers,
Ole

</nochair>


> All,
>
> There was strong support to adopt this draft at the working group meeting in Vancouver.
> This is an adoption call to confirm the result of the hum at the meeting.
>
> Please provide a view with reasons as to whether the WG should adopt this or not.
>
> This message starts a one week 6MAN Working Group call on adopting:
>
>       Title           : Deprecating EUI-64 Based IPv6 Addresses
>       Author(s)    : F. Gont, A. Cooper, D. Thaler, W. Liu
>       Filename    : draft-gont-6man-deprecate-eui64-based-addresses-00
>       Pages        : 5
>       Date          : 2013-10-22
>
>   http://tools.ietf.org/html/draft-gont-6man-deprecate-eui64-based-addresses-00
>
> The call ends on November 26th, 2013.
>
> Regards,
>
> Bob Hinden & Ole Trøan

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