IPv6 Security

Fri Mar 28 06:17:35 UTC 2014

On Mar 27, 2014, at 1:55 PM, Karl Auer <kauer at biplane.com.au> wrote:

> On Thu, 2014-03-27 at 05:34 -0700, Owen DeLong wrote:
>> 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,
>> but I don’t see that as being a problem.
> 
> Though to be fair 3315 also says that the DUID should be treated as an
> opaque blob, not parsed and bits extracted from it. From section 9:
> 
>   "Clients and servers MUST treat DUIDs as opaque values
>    and MUST only compare DUIDs for equality. Clients and
>    servers MUST NOT in any other way interpret DUIDs."
> 
> Regarding section 9.4, which you refer to: 3315 only uses MACs to
> *construct* useful DUIDs, not as a means of communicating MACs to
> clients or servers. Also, an operator cannot RELY on getting a MAC
> address in a DUID.
> 
> DUID's *are* different and *do* require new ways of doing things. People
> will work it out.

Right… The comment wasn’t about getting the Mac address, the comment was about
having a DUID that remains the same across reboots and software installations.

Using LL (type 3) DUIDs should accomplish that.

Linking your IPv4 DHCP System ID and your IPv6 DHCP System ID is a completely
different problem which I don’t see much practical purpose for other than by the hostname
which could easily be handled in the DDNS registration process.

Owen