nanog mailing list archives

Previous By Date Next
Previous By Thread Next

Re: How are you doing DHCPv6 ?

From: Ray Soucy <rps () maine edu>
Date: Tue, 24 Jan 2012 12:09:56 -0500
As we're talking about "the exception, not the rule" I'll note that
the majority of systems generate their DUID based on the MAC address
of their adapter.

ISC DHCPd does in fact allow you to configure static assignments using
MAC and will match a DUID that was generated for that MAC.

Assuming the MAC of 01:23:45:67:89:ab, and a DUID of
00:03:00:01:01:23:45:67:89:ab

The ISC DHCPd configuration for a static host using a DUID:
----8<----
host my-pc.example.com {
  host-identifier option dhcp6.client-id 00:03:00:01:01:23:45:67:89:ab;
  fixed-address6 2001:db8:1:2::3;
}
----8<----

For a MAC:
----8<----
host my-pc.example.com {
  host-identifier option dhcp6.client-id 00:03:00:01:01:23:45:67:89:ab;
  hardware ethernet 01:23:45:67:89:ab;
}
----8<----

As with DHCPd for IPv4, you can make multiple entries to support both
the MAC and DUID method by using the option host-name directive for
additional entries:
----8<----
host my-pc.example.com {
  host-identifier option dhcp6.client-id 00:03:00:01:01:23:45:67:89:ab;
  fixed-address6 2001:db8:1:2::3;
}
host my-pc.example.com-1 {
  option host-name "my-pc.example.com";
  hardware ethernet 01:23:45:67:89:ab;
  fixed-address6 2001:db8:1:2::3;
}
----8<----

Note that this is checking the MAC address used in DUID type 1 or type
3, not the actual MAC address of the system.

What we do right now (as a transition mechanism) in our IPAM is say
that if we see a DUID that is based on a known MAC, then it's probably
the same host, and add the association in the database.

Generating a DHCPv6 configuration file using the "hardware ethernet"
directive will get the majority of systems a v6 address in a dual
stack environment.

On a side note, DHCPv6 isn't the only place to address concerns.

Before DHCPv6 was an option, we implemented a system that polls
network routers and switches for ARP tables, IPv6 neighbor tables, and
MAC address tables, then throws the full association (IP, MAC, Device,
Port) into a MySQL database.  Data is compressed into rows with "first
seen" and "last seen" timestamps to save on table sizes (along with
monthly rotation of tables).  This provides us with the ability to see
what MAC had what IP (or IPv6) address and where it was connected.
Mainly for incident response.  We also poll for IPv6 routers seen to
catch rogue RA, though that has mostly gone away since putting PACLs
in place to filter unauthorized RA.

This database allows us to make the association of IPv4 and IPv6, even
in a SLAAC environment; it also provides us with the history of that
association (and even logs link-local addresses).

When we disable a host, the database is checked so both IPv4 and IPv6
address can be disabled.

As far as DUID discovery, though.  It would be nice if logging changes
previously mentioned were made to ISC DHCPd so we can see the DUIDs
attempting to get an address along with the MAC requesting it.




On Tue, Jan 24, 2012 at 11:18 AM, Randy Carpenter <rcarpen () network1 net> wrote:


I understand that MACs can be changed/spoofed. But that is the exception, not the rule.

That isn't the biggest issue, though. The biggest issue is how to correlate the MAC and the DUID. That is the only 
way to properly authenticate and account for users that have both v4 and v6 (which is everyone)

I don't care if their MAC changes, if that happens, they just need to reauthenticate. But, not having any way to know 
what their DUID is going to be, makes it impossible to also give them v6.


-Randy

----- Original Message -----

"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.  Our 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.  It would be simple to create a DUID sticker at
that
point, even retroactively.  I 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> wrote:


Controlled by software = not constant.

It is also not likely to be something that is knowable on a piece
of electronic 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.  If 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/




--
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/
Previous By Date Next
Previous By Thread Next

Current thread: