I am pretty sure the EUI-64 requirement has been dropped. If not I can't see
how the real world security practitioners are going to implement it.
The EUI-64 address reveals the hardware manufacturer and model of hardware that
I am using. There are no circumstances in which I am going to allow an attacker
to obtain that information without putting them to as much effort as I can.
Security through obscurity is bad strategy but good tactics. It is really bad
to rely on obscurity in a security architecture but good practice to employ
obscurity as an additional control in a layered architecture, particularly when
you are dealing with an imperfect security situation that you need to
remediate.
If it is a requirement it is not stated correctly. I do not see a MUST. In fact
if I was reviewing the text today I would bork it as stated as not being
compliant with the MUST/SHOULD/MAY language.
-----Original Message-----
From: Iljitsch van Beijnum [mailto:iljitsch(_at_)muada(_dot_)com]
This requires that all IPv6 nodes do DHCPv6 and there's a
DHCPv6 server. You won't see those two requirements met very
often in today's IPv6 deployments. However, you WILL see
stateless autoconfiguration everywhere, and that can only
work with /64 subnets. So you can't re-subnet a subnet in
practice. Also, RFC 3513
says:
For all unicast addresses, except those that start with
binary value
000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.
I have no idea why this sentence is in there, except possibly
to make sure that stateless autoconfig can work, which may
prove challenging with a prefix longer than /64.
BTW, I wonder how users will react to address
nickel-and-diming by ISPs with IPv6 when they can have a /48
with 6to4 tunneling.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf