[170490] in North American Network Operators' Group
Re: IPv6 Security
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Mar 28 02:23:05 2014
From: Owen DeLong <owen@delong.com>
In-Reply-To: <1395953738.7560.28.camel@karl>
Date: Thu, 27 Mar 2014 23:17:35 -0700
To: Karl Auer <kauer@biplane.com.au>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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 =93Link Layer Address=94 (RFC 3315, Section 9.1 =
Type 3)
>> is? =46rom 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=92t see that as being a problem.
>=20
> Though to be fair 3315 also says that the DUID should be treated as an
> opaque blob, not parsed and bits extracted from it. =46rom section 9:
>=20
> "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."
>=20
> 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.
>=20
> DUID's *are* different and *do* require new ways of doing things. =
People
> will work it out.
Right=85 The comment wasn=92t 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=92t see much practical purpose for other =
than by the hostname
which could easily be handled in the DDNS registration process.
Owen
