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

["Leaf Yeh" <[e-mail]>]

The draft under discussion sounds like a draft only having one sentence,
while my reading is 
   ' Nodes SHOULD implement and employ 
   [I-D.ietf-6man-stable-privacy-addresses] as the default scheme for
   generating stable IPv6 addresses with SLAAC. '
in the case of end-user's GUA for the sake of privacy.

I am curious why this sentence (or the relevant topic) can't be included in
[I-D.ietf-6man-stable-privacy-addresses].


Best Regards,
Leaf



-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Greg Daley
Sent: Wednesday, November 27, 2013 1:23 PM
To: 'Jean-Michel Combes'; Ole Troan
Cc: 6man Chairs; 6man WG
Subject: RE: 6MAN Adoption call on
draft-gont-6man-deprecate-eui64-based-addresses-00

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-addre
> sses-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
--------------------------------------------------------------------

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