DHCPv6 client classification based on DUID.

[Рязанцев Андрей]

Greetings, everyone.

I'm trying to configure isc-dhcp daemon on my new router (it runs OpenWRT codenamed Attitude Adjustment). My main idea is quite simple. I have one internal network interface and a couple of IPv6 subnetworks on it (for example). Lets say those subnets are 2001:db8::a:0/112 and 2001:db8::b:0/112. All I want for DHCPv6 server is to assign network A addresses to real interfaces, and network B addresses for clients whose DUID contains substring "080027" (that's VirtualBox vendor code (or whatever that part of MAC address called) for its interfaces).
My first configuration attempt was as simple as that:

########################################################################
subnet6 2001:db8::a:0/112
{
        range6 2001:db8::a:10 2001:db8::a:ffff;
}

class "virtualbox"
{
    match if substring(option6 dhcp6.client-id, 16, 6) = "080027"; # client-id is DUID type 0x1
}

subnet6 2001:db8::b:0/112
{
        range6 2001:db8::b:10 2001:db8::b:ffff;
        allow members of "virtualbox";
};
########################################################################

Of course it's all wrong when applying to isc-dhcpd, but still it describes my idea.
What I'm getting after that is "WARNING: class declarations are not supported for DHCPv6." :(

I was able to get really close to that with dnsmasq. It was just about 2 config lines:

########################################################################
dhcp-match=set:virtualbox,option:client-id,*:08:00:27:*
dhcp-range=tag:virtualbox,2001:db8::b:10,2001:db8::b:ffff,112,15m
########################################################################

Unfortunately dnsmasq just doesn't understand client-id option. Which can be confirmed by issuing command "dnsmasq --help dhcp6".
So my question is: Can I somehow achieve behavior mentioned above with isc-dhcpd? And of course how can I do that?

Thanks in advance to any respon

[Chris Buxton]

No.

DHCPv6 does not support classes. Period. (Not yet, anyway...)

Also, parsing the DUID looking for (part of) a MAC address is a protocol violation. DHCPv6 should never even see the MAC address, let alone act upon it. (Not yet, anyway...)

DHCPv6 was never designed to behave at all like DHCP (v4). It was designed to learn from the "mistakes" of DHCP and improve the design. Of course, a lot of people don't like change, and see this as a flaw in the design of DHCPv6. I personally expect DHCPv6 to gain a lot of the capabilities of DHCP over the next couple of years, because (for example) the ability to ban a particular MAC address is kind of important. Doing this in the switch configuration often involves a different organization within the IT departments of a lot of enterprises. Enterprises will hold back on deploying IPv6 until this gets sorted out.

Of course, it may also happen that my employer and our competitors get more into switch management, obviating the whole issue...

Chris Buxton
BlueCat Networks

On Sep 18, 2012, at 10:08 AM, РязаМцев АМЎрей wrote:

> Greetings, everyone.
>
> I'm trying to configure isc-dhcp daemon on my new router (it runs OpenWRT codenamed Attitude Adjustment). My main idea is quite simple. I have one internal network interface and a couple of IPv6 subnetworks on it (for example). Lets say those subnets are 2001:db8::a:0/112 and 2001:db8::b:0/112. All I want for DHCPv6 server is to assign network A addresses to real interfaces, and network B addresses for clients whose DUID contains substring "080027" (that's VirtualBox vendor code (or whatever that part of MAC address called) for its interfaces).
> My first configuration attempt was as simple as that:
>
> ########################################################################
> subnet6 2001:db8::a:0/112
> {
> range6 2001:db8::a:10 2001:db8::a:ffff;
> }
>
> class "virtualbox"
> {
> match if substring(option6 dhcp6.client-id, 16, 6) = "080027"; # client-id is DUID type 0x1
> }
>
> subnet6 2001:db8::b:0/112
> {
> range6 2001:db8::b:10 2001:db8::b:ffff;
> allow members of "virtualbox";
> };
> ########################################################################
>
> Of course it's all wrong when applying to isc-dhcpd, but still it describes my idea.
> What I'm getting after that is "WARNING: class declarations are not supported for DHCPv6." :(
>
> I was able to get really close to that with dnsmasq. It was just about 2 config lines:
>
> ########################################################################
> dhcp-match=set:virtualbox,option:client-id,*:08:00:27:*
> dhcp-range=tag:virtualbox,2001:db8::b:10,2001:db8::b:ffff,112,15m
> ########################################################################
>
> Unfortunately dnsmasq just doesn't understand client-id option. Which can be confirmed by issuing command "dnsmasq --help dhcp6".
> So my question is: Can I somehow achieve behavior mentioned above with isc-dhcpd? And of course how can I do that?
>
> Thanks in advance to any responders.
> _______________________________________________
> dhcp-users mailing list
> dhcp-***@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

[Ted Lemon]

On Sep 19, 2012, at 4:51 PM, Chris Buxton <***@gmail.com> wrote:
> Also, parsing the DUID looking for (part of) a MAC address is a protocol violation. DHCPv6 should never even see the MAC address, let alone act upon it. (Not yet, anyway...)

No, it's not. This wasn't well worded, but the key point of that bit of the specification was that the DUID be used as an opaque key when looking up bindings, not that the server isn't allowed to look at what's in the DUID at all ever.

[Chris Buxton]

On Sep 19, 2012, at 2:06 PM, Ted Lemon wrote:
> On Sep 19, 2012, at 4:51 PM, Chris Buxton <***@gmail.com> wrote:
>> Also, parsing the DUID looking for (part of) a MAC address is a protocol violation. DHCPv6 should never even see the MAC address, let alone act upon it. (Not yet, anyway...)
>
> No, it's not. This wasn't well worded, but the key point of that bit of the specification was that the DUID be used as an opaque key when looking up bindings, not that the server isn't allowed to look at what's in the DUID at all ever.

Always happy to be corrected. Thank you for that.

Let me state the problem differently, as I understand it: The client ID doesn't have to contain the client's MAC address, and does not reliably follow any pattern whatsoever across all implementations. Therefore, parsing the client ID to find the MAC address is not a reliable method.

Chris Buxton
BlueCat Networks

[Ted Lemon]

On Sep 19, 2012, at 6:47 PM, Chris Buxton <***@gmail.com> wrote:
> Let me state the problem differently, as I understand it: The client ID doesn't have to contain the client's MAC address, and does not reliably follow any pattern whatsoever across all implementations. Therefore, parsing the client ID to find the MAC address is not a reliable method.

Yes, this captures the issue perfectly. :)

[Рязанцев Андрей]

>
>
>
>Let me state the problem differently, as I understand it: The client ID doesn't have to contain the client's MAC address, and does not reliably follow any pattern whatsoever across all implementations. Therefore, parsing the client ID to find the MAC address is not a reliable method.
>
>
Chris Buxton
>
BlueCat Networks
>

>_______________________________________________
>
dhcp-users mailing list
>dhcp-***@lists.isc.org
>https://lists.isc.org/mailman/listinfo/dhcp-users
>





Well thats confusing a little bit. I was hoping that most of the clients should obey dhcpv6 protocol as stated in RFC 3315. And that document says that DUID types 0x1 and 0x3 are containing link-layer address. That's why I think that following wildcards like "0001*080027*" and "0003*080027*" should do the trick. Or in case of isc-dhcpd we can still use character offsets because DUID has a few types only, it has a structured header and all conditions like:

1) for DUID-LLT string, containing its hex-representation comparing substring @[1:4]* with "0001" AND substring@[16:6]* with "080027";
2) for DUID-LL string, containing its hex-representation comparing substring @[1:4]* with "0003" AND substring@[8:6]* with "080027";
// * - @[offset, length]

should separate clients based on  network device's vendor-code in MAC. Or maybe something changed since that RFC 3315 was written?

And as for DUID-EN - there is always should be IANA assigned enterprise number. Which also can be extracted and matched.
And those clients who put some random stuff in solicit packets or overriden their manufacturer's hardware addresses - I think should be discarded or assigned some general class and general ipv6 address.

So am I saying the right things? Or I am missing something?

[Ted Lemon]

On Sep 20, 2012, at 1:28 AM, "Рязанцев Андрей" <***@mail.ru> wrote:
> Well thats confusing a little bit. I was hoping that most of the clients should obey dhcpv6 protocol as stated in RFC 3315. And that document says that DUID types 0x1 and 0x3 are containing link-layer address. That's why I think that following wildcards like "0001*080027*" and "0003*080027*" should do the trick. Or in case of isc-dhcpd we can still use character offsets because DUID has a few types only, it has a structured header and all conditions like:
>
> 1) for DUID-LLT string, containing its hex-representation comparing substring @[1:4]* with "0001" AND substring@[16:6]* with "080027";
> 2) for DUID-LL string, containing its hex-representation comparing substring @[1:4]* with "0003" AND substring@[8:6]* with "080027";
> // * - @[offset, length]
>
> should separate clients based on network device's vendor-code in MAC. Or maybe something changed since that RFC 3315 was written?
>
> And as for DUID-EN - there is always should be IANA assigned enterprise number. Which also can be extracted and matched.
> And those clients who put some random stuff in solicit packets or overriden their manufacturer's hardware addresses - I think should be discarded or assigned some general class and general ipv6 address.
>
> So am I saying the right things? Or I am missing something?

What you are proposing to do here is exactly what "opaque" is intended to forbid you doing. Your server's behavior would be wrong, because you are attributing meaning to fields in a packet for which

[Simon Hobson]

êþÁý̖’ Ä̔•ÂÈ wrote:

>Well thats confusing a little bit. I was hoping
>that most of the clients should obey dhcpv6
>protocol as stated in RFC 3315. And that
>document says that DUID types 0x1 and 0x3 are
>containing link-layer address.

Yes, *A* MAC address, not necessarily *THE* MAC
address of the interface you are configuring, nor
even of a MAC address still installed in the
device. As long as the device has persistent
(which is most systems), it should generate a
DUID the first time one is needed (or at system
startup) - and then store it 'forever' even if
the interface(s) change later. If it has multiple
interfaces, the DUID (note the singular) will
only use the MAC address from one of them, and
the DUID should not change if the interface it
took the MAC address from is removed from the
system.

Thus you a) have no guarantee that a device
encodes a MAC address in the DUID, and b) where
it does, you have no guarantee that it's from the
interface you are interested in.

If you've followed this list for a while, there
has been some "intense" discussion regarding the
lack of MAC address from the interface being
configured and how this impacts on various
operating setups (work flows) already in place.
Mainly, for many, the MAC address is considered
the least bad persistent identifier we have
available - and is usually known before even
plugging in the system, where any DUID generally
won't be.

--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

[Alex Bligh]

--On 20 September 2012 08:11:45 +0100 Simon Hobson <***@thehobsons.co.uk>
wrote:

> Mainly, for many, the MAC address is considered the least bad persistent
> identifier we have available - and is usually known before even plugging
> in the system, where any DUID generally won't be.

Has anyone worked out how (e.g.) PXEboot would work with IPv6? I presume
it would need to generate the DUID and some how magically pass this to
the host OS.

--
Alex Bligh

[Ted Lemon]

On Sep 20, 2012, at 2:37 PM, "Alex Bligh" <***@alex.org.uk> wrote:
> Has anyone worked out how (e.g.) PXEboot would work with IPv6? I presume
> it would need to generate the DUID and some how magically pass this to
> the host OS.

Section 7 of RFC4361 speaks to this question.

[Ralph Droms (rdroms)]

On Sep 20, 2012, at 2:51 PM, "Ted Lemon" <***@nominum.com> wrote:

> On Sep 20, 2012, at 2:37 PM, "Alex Bligh" <***@alex.org.uk> wrote:
>> Has anyone worked out how (e.g.) PXEboot would work with IPv6? I presume
>> it would need to generate the DUID and some how magically pass this to
>> the host OS.
>
> Section 7 of RFC4361 speaks to this question.
> _______________________________________________
> dhcp-users mailing list
> dhcp-***@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Ted Lemon wrote:
>On Sep 20, 2012, at 2:37 PM, "Alex Bligh" <***@alex.org.uk> wrote:
>> Has anyone worked out how (e.g.) PXEboot would work with IPv6? I presume
>> it would need to generate the DUID and some how magically pass this to
>> the host OS.
>
>Section 7 of RFC4361 speaks to this question.

Well sort of, but it's not really that specific - nor can it be
unless you can get multiple hardware and software vendors to
co-operate. In the general case, the first stage boot is likely to
not have access to an OS specific DUID - and vice-versa.

That's only likely to change if hardware vendors start providing a
specific place to store a device-wide DUID, and software vendors
support using it. I don't see that happening soon.

[Randall C Grimshaw]

>That's only likely to change if hardware vendors start providing a
>specific place to store a device-wide DUID, and software vendors
>support using it. I don't see that happening soon.

from an operational point of view, wireless 802.1x supplicants with their common use of certificates could be used to drive NAC processes such as vlan steering. So one generalized solution would be to get OS vendors to treat the wired networks in the same way. Frankly, I don't see DHCP stepping up the the plate on this one. It is disappointing.

Randall Grimshaw

[Simon Hobson]

Randall C Grimshaw wrote:
> >That's only likely to change if hardware vendors start providing a
>>specific place to store a device-wide DUID, and software vendors
>>support using it. I don't see that happening soon.
>
>from an operational point of view, wireless 802.1x supplicants with
>their common use of certificates could be used to drive NAC
>processes such as vlan steering. So one generalized solution would
>be to get OS vendors to treat the wired networks in the same way.

I know almost nothing about 802.11x, but I can't help thinking it
just moves the problem. I'm assuming any certificate would be stored
in storage managed by the OS - which for devices capable of PXE
booting is fairly likely to be disk (or a network volume mounted in
much the same way). Thus the network boot client still won't have
access to it without there being system wide and environment agnostic
storage for it.

Ie, when PXE boots, it doesn't (in the general case) have access to
the storage containing the later OS's key - whether DUID or 802.11x
certificate - and so cannot use the later OS's key. Chances are it'll
have little to no storage of it's own, and hence won't be able to
store a key of it's own that the OS could (theoretically) also use.

--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

[Christian Bösch]

On Sep 20, 2012, at 23:13 , Simon Hobson <***@thehobsons.co.uk> wrote:

> Randall C Grimshaw wrote:
>> >That's only likely to change if hardware vendors start providing a
>>> specific place to store a device-wide DUID, and software vendors
>>> support using it. I don't see that happening soon.
>>
>> from an operational point of view, wireless 802.1x supplicants with their common use of certificates could be used to drive NAC processes such as vlan steering. So one generalized solution would be to get OS vendors to treat the wired networks in the same way.
>
> I know almost nothing about 802.11x, but I can't help thinking it just moves the problem. I'm assuming any certificate would be stored in storage managed by the OS - which for devices capable of PXE booting is fairly likely to be disk (or a network volume mounted in much the same way). Thus the network boot client still won't have access to it without there being system wide and environment agnostic storage for it.

Intel's vPro Technology does this:
http://www.intel.com/technology/itj/2008/v12i4/5-paper/4-embedded-2.htm

chris

>
> Ie, when PXE boots, it doesn't (in the general case) have access to the storage containing the later OS's key - whether DUID or 802.11x certificate - and so cannot use the later OS's key. Chances are it'll have little to no storage of it's own, and hence won't be able to store a key of it's own that the OS could (theoretically) also use.
>
> --
> Simon Hobson
>
> Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
> author Gladys Hobson. Novels - poetry - short stories - ideal as
> Christmas stocking fillers. Some available as e-books.
> _______________________________________________
> dhcp-users mailing list
> dhcp-***@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Christian Bösch wrote:

>>I know almost nothing about 802.11x, but I
>>can't help thinking it just moves the problem.
>>I'm assuming any certificate would be stored in
>>storage managed by the OS - which for devices
>>capable of PXE booting is fairly likely to be
>>disk (or a network volume mounted in much the
>>same way). Thus the network boot client still
>>won't have access to it without there being
>>system wide and environment agnostic storage
>>for it.
>>
>
>Intel's vPro Technology does this:
>http://www.intel.com/technology/itj/2008/v12i4/5-paper/4-embedded-2.htm

Interesting, but hardly ubiquitous.
Until it's ubiquitous (or at least very widely
available) then it's not a great deal of use in
the general case. Until it's useful to support
it, it's not going to be widely supported by
software. Until it's supported by software, it's
of little use and there'll be little demand. And
so round and round we go.

Same goes for system wide DUID support. What
would be ideal would be if **EVERY** device came
with a system wide DUID pre-assigned at the
factory, easily available to every environment/OS
the system runs, marked on the device ID label
and marked on the packaging (like the MAC address
quite often is now). That would eliminate all
these discussions about what is and isn't a good
identifier.

So *all* that's needed is to define a standard
for it, persuade every hardware manufacturer to
support it, and persuade every software vendor to
support it :-/

--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.

[Alex Bligh]

--On 21 September 2012 08:05:20 +0100 Simon Hobson <***@thehobsons.co.uk>
wrote:

> So *all* that's needed is to define a standard for it, persuade every
> hardware manufacturer to support it, and persuade every software vendor
> to support it :-/

Or the MAC address could be supplied as an option, for people to use
if DUIDs do not work for them.

--
Alex Bligh

[Alex Bligh]

--On 20 September 2012 18:50:06 +0000 Ted Lemon <***@nominum.com>
wrote:

> On Sep 20, 2012, at 2:37 PM, "Alex Bligh" <***@alex.org.uk> wrote:
>> Has anyone worked out how (e.g.) PXEboot would work with IPv6? I presume
>> it would need to generate the DUID and some how magically pass this to
>> the host OS.
>
> Section 7 of RFC4361 speaks to this question.

As far as I can tell, its two proposed solutions are:
1. Use short lease times ("Firstly")
2. Boot using IPv4 instead ("Secondly")

The second is not 'PXEboot working with DHCP+IPv6' - I'd have thought
the obvious answer would be to use IPv6+stateless configuration if
solutions avoiding using DHCPv6 are to be permitted!

(1) does not help much if one is trying to work out what to serve
to the server concerned based on IP address (which is normally the
only thing you have).

--
Alex Bligh