[148840] in North American Network Operators' Group
Re: How are you doing DHCPv6 ?
daemon@ATHENA.MIT.EDU (Ray Soucy)
Tue Jan 24 08:52:05 2012
In-Reply-To: <CALFTrnO0Jaa48dYszNeSon+6JdkMQg1Bf+872zPpifUQ1Jrcfg@mail.gmail.com>
Date: Tue, 24 Jan 2012 08:51:20 -0500
From: Ray Soucy <rps@maine.edu>
To: Randy Carpenter <rcarpen@network1.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
"You shouldn't assume a MAC isn't constant" should read "is", double
negative failure.
On Tue, Jan 24, 2012 at 8:49 AM, Ray Soucy <rps@maine.edu> wrote:
> You shouldn't assume a MAC isn't constant. =A0Our students spoof their
> MACs all the time (thinking it will save them from getting a DMCA
> notice).
>
> The RFC suggests that DUIDs are stored in non-volatile memory or that
> an algorithm be used that can consistently reproduce the DUID (and
> IAID) for a system in the absence of persistent storage.
>
> For fixed hardware devices, I suspect most would opt for the use of
> DUID-LL type, which essentially the MAC with a DUID preamble, and
> doesn't need to be stored in memory since it's based on a MAC that can
> not be changed. =A0It would be simple to create a DUID sticker at that
> point, even retroactively. =A0I think the idea that DUID is random and
> getting worked up that it's not written on the side of the device is a
> little more FUD than fact.
>
> There _are_ things we need to address to make DHCPv6 easier to roll
> out (mainly on the server side), but just making bogus nitpick attacks
> distracts from the real issues, IMHO.
>
>
>
>
> On Mon, Jan 23, 2012 at 6:12 PM, Randy Carpenter <rcarpen@network1.net> w=
rote:
>>
>> Controlled by software =3D not constant.
>>
>> It is also not likely to be something that is knowable on a piece of ele=
ctronic gear that is not a PC, nor will it be something that can be printed=
on the outside of the device, like most today.
>>
>> -Randy
>>
>>
>> ----- Original Message -----
>>> Yes, DUID and IAID should be persistent on systems. =A0If they are not
>>> then they are not following the RFC.
>>>
>>> Note that bad practices, though, can remove that persistence (e.g.
>>> deleting the DUID, or replicating the DUID on other systems).
>>>
>>> On Mon, Jan 23, 2012 at 5:56 PM, Karl Auer <kauer@biplane.com.au>
>>> wrote:
>>> > On Mon, 2012-01-23 at 17:26 -0500, Randy Carpenter wrote:
>>> >> One major issue is that there is no way to associate a user's MAC
>>> >> (for
>>> >> IPv4) with their DUID. I haven't been able to find a way to
>>> >> account
>>> >> for this without making the user authenticate once for IPv4, and
>>> >> then
>>> >> again for IPv6. This is cumbersome to the user. Also, in the past
>>> >> there have been various reason why we want to pre-authenticate a
>>> >> client's MAC address (mostly for game consoles, and such, which
>>> >> have
>>> >> the MAC written on the outside of the machine). How can this be
>>> >> done
>>> >> with IPv6, which the DUID is not constant?
>>> >
>>> > Perhaps I misunderstand you (or the RFCs) but it seems to me that
>>> > the
>>> > DUID *is* constant. Reading section 9 of RFC 3315, it's pretty
>>> > clear
>>> > that a DUID is generated once, according to simple rules, and does
>>> > not
>>> > change once it has been generated. Barring intervention, of course.
>>> >
>>> > The problem is how to either find out ahead of time what DUID a
>>> > client
>>> > has OR how to impose a specific DUID on a client as part of
>>> > provisioning
>>> > it. Neither of those issues looks particularly intractable,
>>> > especially
>>> > if vendors start shipping with pre-configured DUIDs that are
>>> > written on
>>> > the boxes.
>>> >
>>> > What do you mean by "authenticate"? Do you mean something like
>>> > 802.1x?
>>> >
>>> > Regards, K.
>>> >
>>> > --
>>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=
~~
>>> > Karl Auer (kauer@biplane.com.au)
>>> > http://www.biplane.com.au/kauer
>>> >
>>> > GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
>>> > Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
>>>
>>>
>>>
>>> --
>>> Ray Soucy
>>>
>>> Epic Communications Specialist
>>>
>>> Phone: +1 (207) 561-3526
>>>
>>> Networkmaine, a Unit of the University of Maine System
>>> http://www.networkmaine.net/
>>>
>>>
>>>
>
>
>
> --
> Ray Soucy
>
> Epic Communications Specialist
>
> Phone: +1 (207) 561-3526
>
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/
--=20
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/
