nanog mailing list archives
Re: IPv6 Security
From: sthaug () nethelp no
Date: Thu, 27 Mar 2014 17:10:06 +0100 (CET)
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 ofmedia 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 () nethelp no
Current thread:
- Re: IPv6 Security [Was: Re: misunderstanding scale], (continued)
- Re: IPv6 Security [Was: Re: misunderstanding scale] Jack Bates (Mar 26)
- Re: IPv6 Security [Was: Re: misunderstanding scale] Mohacsi Janos (Mar 26)
- Re: IPv6 Security [Was: Re: misunderstanding scale] Matt Palmer (Mar 26)
- Re: IPv6 Security [Was: Re: misunderstanding scale] Luke S. Crawford (Mar 26)
- Re: IPv6 Security [Was: Re: misunderstanding scale] Timothy Morizot (Mar 26)
- Re: IPv6 Security [Was: Re: misunderstanding scale] Chuck Anderson (Mar 26)
- Re: IPv6 Security [Was: Re: misunderstanding scale] Owen DeLong (Mar 26)
- Re: IPv6 Security sthaug (Mar 27)
- Re: IPv6 Security Henri Wahl (Mar 27)
- Re: IPv6 Security Owen DeLong (Mar 27)
- Re: IPv6 Security sthaug (Mar 27)
- Re: IPv6 Security Karl Auer (Mar 27)
- Re: IPv6 Security Owen DeLong (Mar 27)
- Re: IPv6 Security [Was: Re: misunderstanding scale] Owen DeLong (Mar 26)
- Re: IPv6 Security [Was: Re: misunderstanding scale] Luke S. Crawford (Mar 27)
- Re: IPv6 Security [Was: Re: misunderstanding scale] Jack Bates (Mar 27)
- Re: IPv6 Security [Was: Re: misunderstanding scale] Owen DeLong (Mar 26)
- Re: IPv6 Security [Was: Re: misunderstanding scale] Luke S. Crawford (Mar 27)
- Re: misunderstanding scale bmanning (Mar 23)
- Re: misunderstanding scale Timothy Morizot (Mar 23)
- Re: misunderstanding scale Paul Ferguson (Mar 23)