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

[Alexandru Petrescu <[e-mail]>]

Le 24/10/2013 21:59, Brian E Carpenter a écrit :
> Unfortunately I feel that this is operationally unacceptable.

I agree.

Not only operationally it may prove difficult to upgrade everything from
RFC2464, but all the IPv6-over-foo specs of future deployment may need
to accept it as well.

E.g. will this 48bit prohibition also include prohibiting the 'short'
16bit of 802.15.4?  Or is that less of risk given it's a shorter address
and thus less unique?

(in detail:
it cites [RFC2464] Ethernet, [RFC2467] FDDI, and [RFC2470] Token Ring,
but would one go ammend also other IPv6 over foo documents such as:
RFC2492 ATM,
RFC4944 802.15.4,
RFC5072 PPP using Ethernet hardware IDs,
RFC5692 802.16,
draft-ietf-6lowpan-btle-12,
draft-ietf-6man-6lobac-01,
draft-brandt-6man-lowpanz-02,
IPv6-over-USB unspecified, but using hardware IDs.

and why not the methods of forming IPv6 addresses containing an IPv4 
address which may be related in other ways to other privacy aspects like 
geographical localization.)

Alex

>
> There are many (I suppose thousands) of sites that rely on MAC
> addresses to manage their assets, and in many cases to trace
> malicious users. It's certainly true that in theory, they can do
> this by using ND or DHCPv6 logging, as today they use ARP cache or
> DHCP logging to trace IPv4 users, and they may have to do this anyway
> when some users implement some form of obscure IID generation. But I
> just don't see site managers in general (and therefore vendors)
> accepting this:
>
> "Nodes MUST NOT employ IPv6 address generation schemes that embed the
> underlying hardware address in the Interface Identifier."
>
> I would suggest that this might fly:
>
> "Nodes SHOULD NOT employ IPv6 address generation schemes that embed
> the underlying hardware address in the Interface Identifier, and
> such schemes MUST NOT be enabled by default in any implementation."
>
> Even that might prove unrealistic.
>
> Incidentally, your case would be strengthened by referring to
> draft-ietf-6man-ug, which makes it plain that the case for EUI64 is
> weaker than was originally thought.
>
> Brian
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>