nanog mailing list archives

Re: IPv6 Security


From: Owen DeLong <owen () delong com>
Date: Thu, 27 Mar 2014 23:17:35 -0700


On Mar 27, 2014, at 1:55 PM, Karl Auer <kauer () 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



Current thread: