Re: IPv6 Security

[Owen DeLong <owen () delong com>]

On Mar 27, 2014, at 12:52 AM, sthaug () nethelp no wrote:

> > > 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.FN"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).

Yes it does$B!D(B

What do you think $B!H(BLink Layer Address$B!I(B (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,
but I don.FN"t see that as being a problem.


> 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.

Clients failing to implement DUID-LL as defined in RFC-3315 can hardly be
blamed on DHCPv6.

> 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.

Reread section 9.4$B!D(B It seems not only possible, but recommended from my reading.

The problem isn.FN"t that the MAC address isnN"t allowed. The problem is that the clients
aren.FN"t properly using permanent MAC addresses as DUID.

Owen