[170465] in North American Network Operators' Group
Re: IPv6 Security
daemon@ATHENA.MIT.EDU (Karl Auer)
Thu Mar 27 16:56:11 2014
From: Karl Auer <kauer@biplane.com.au>
To: nanog@nanog.org
Date: Fri, 28 Mar 2014 07:55:38 +1100
In-Reply-To: <23D8163C-15ED-43CB-979F-68D87CD060F3@delong.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
Regards, K.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389
GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
