IPv6 Security

sthaug at nethelp.no sthaug at nethelp.no
Thu Mar 27 07:52:06 UTC 2014


> > No, it is LESS robust, because the client identifier changes when the
> > SOFTWARE changes.  Around here, software changes MUCH more often than
> > hardware.  Heck, even a dual-boot scenario breaks the client
> > identifier stability.  Worse yet, DHCPv6 has created a scenario where
> > a client's IPv4 connectivity and IPv6 connectivity break under
> > /different/ scenarios, causing difficult-to-troubleshoot
> > half-connectivity issues when either the hardware is replaced or the
> > software is reloaded.
> 
> Any client whose DUID changes on software re-install has a very poor choice of default DUID and should be configurable for a better choice of DUID. That is not DHCPv6’s fault.

It is reality. DHCPv6 needs to take reality into account.

DHCPv6 as defined in RFC 3315 does not offer client MAC address at all
(thus making the job more difficult for a number of organizations).
All I've seen so far indicates that this was a deliberate choice by
the DHCPv6 designers, and in my opinion a very poor one. Fortunately
we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and
we're waiting for vendors to implement this. That solves one half of
the problem.

The other half is to actually let the DHCPv6 lease be based directly
on the MAC address. The language in RFC 3315, as I read it, makes this
difficult or impossible.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no





More information about the NANOG mailing list