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 <otroan@employees.org>

> <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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>