IPv6 Security

Thu Mar 27 16:10:06 UTC 2014

> > 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).
> 
> Yes it does…
> 
> What do you think “Link Layer Address” (RFC 3315, Section 9.1 Type 3)
> is? From RFC-3315 Section 9.4, it seems pretty clear that is exactly what
> this is intended to be. True, it includes an additional 16 bits of
> > media type,

- I cannot a priori know which DUID type a particular client will use.
Of the three DUID types in RFC 3315 section 9.1, type 1 and 3 include
link layer address while type 2 does not.

- As has already been pointed out, the same physical hardware may use
different DUID types when booted with different operating systems.

- The language in RFC 3315 is pretty explicit in saying that a server
*must* treat the DUID as an opaque value - in other words, you are not
allowed to "inspect" it in any way to find the presumed MAC address
and take any action based on the MAC address.

> > 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.
> 
> Yes and no.
> 
> At the time RFC3315 was written, network cards changed independent of
> motherboards on a regular basis and this fact was a source of great
> consternation for DHCPv4 operators. Over time, that changed AFTER
> RFC3315 was written, but if you read section 9.4, it seems pretty clear that
> this change was anticipated by the authors and that DUID-LL was intended
> for the situation we have today.

I think understand the well-meant intentions of the RFC 3315 authors.
However, my claim is that the actual end result for IPv6 leaves us in
a *worse* situation than for IPv4. And one which, among others, makes
it very difficult to correlate IPv4 and IPv6 leases (something which
I have no need for today, but which I could easily see a need for in
the future).

Steinar Haug, Nethelp consulting, sthaug at nethelp.no