Send dhcp-users mailing list submissions to
        [email protected]
To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."


Today's Topics:

   1. dhcp6.client-linklayer-addr (Kristof Van Doorsselaere)
   2. Re: dhcp6.client-linklayer-addr (Simon Hobson)
   3. Re: dhcp6.client-linklayer-addr (Enno Rey)
   4. Re: dhcp6.client-linklayer-addr (Kristof Van Doorsselaere)


----------------------------------------------------------------------

Message: 1
Date: Tue, 8 Sep 2015 08:51:25 +0000
From: Kristof Van Doorsselaere <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: dhcp6.client-linklayer-addr
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

Dear dhcp mailing list,

I?m testing latest dhcpd 4.3.3 to replace our current production dhcp server, 
the new server will run dual stack (ipv4/ipv6). On our current dhcp server, 
(for wired, non 802.1x  enabled networks), we currently implement: deny unknown 
clients, so only known mac addresses will get an ip. I already read, on several 
places, this is not possible for ipv6. But last week I found out about  RFC 
6939, and now I was trying to figure  out if my ipv6 relay (fortigate firewall) 
supports this.

Based on the logs below it looks like, this rfc is supported, since the mac 
address is logged correctly (using the log statement below)

Logs:

Sep  8 10:00:38 komo dhcpd: Lease for 2001:xxxx:xxxx:3d98:aaaa:8624:d059:50be 
leased to 40:6c:8f:a:2e:1a

Sep  8 10:00:38 komo dhcpd: did not find: 
(&(objectClass=dhcpHost)(dhcpClientId=00:01:00:01:1c:e4:9b:70:40:6c:8f:0a:2e:1a))

Sep  8 10:00:38 komo dhcpd: did not find clientid: 
(&(objectClass=dhcpHost)(dhcpClientId=00:01:00:01:1c:e4:9b:70:40:6c:8f:0a:2e:1a))

Sep  8 10:00:38 komo dhcpd: Lease for 2001:xxxx:xxxx:3d98:aaaa:8624:d059:50be 
leased to 40:6c:8f:a:2e:1a

Sep  8 10:00:38 komo dhcpd: Reply NA: address 
2001:xxxx:xxxx:3d98:aaaa:8624:d059:50be to client with duid 
00:01:00:01:1c:e4:9b:70:40:6c:8f:0a:2e:1a iaid = 0 valid for 2592000 seconds

Sep  8 10:00:38 komo dhcpd: Sending Relay-reply to 
2001:xxxx:xxxx:ab00:ffff:ffff:ffff:ffff port 547




So now I?m trying to find out if there is any possibility to deny unknown 
clients based on there mac addresses in a pool6 configuration? Is this 
something on the roadmap? Or will it never be implemented? (For us this would 
mean: stop using mac address based allow/deny rules and go for 802.1x all the 
way (we currently implement this on wifi and a few wired networks) 

Remark: Our mac addresses are stored in ldap, and based on the logs (above) it 
looks like dhcpv6 is searching for DUID rather then mac adress,  do we have any 
options here?

Below some more info about my setup:

OS: Debian 8.1

Subnet cfg:

subnet6 2001:xxxx:xxxx:3d98::/64  {

        pool6 {

option dhcp6.name-servers 2001:xxxx:xxxx:ab00::1, 2001:xxxx:xxxx:ab00::2; 

option dhcp6.domain-search ?example.com"; 

ignore unknown-clients;

range6  2001:xxxx:xxxx:3d98:aaaa::/80; 

range6  2001:xxxx:xxxx:3d98:bbbb::/80 temporary;

}

}



Rfc 6939 specific cfg:

## RFC  6939

option dhcp6.macaddr code 193 = string;

option dhcp6.leased-address code 194 = string;

option dhcp6.macaddr = binary-to-ascii(16, 8, ":", suffix(option 
dhcp6.client-id, 6));

option dhcp6.leased-address = binary-to-ascii(16,16, ":", 
substring(suffix(option dhcp6.ia-na, 24),0,16));

log (info, concat ("Lease for ",config-option dhcp6.leased-address, " leased to 
", config-option dhcp6.macaddr));



Thanks for your reply,

Kristof van Doorsselaere

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<https://lists.isc.org/pipermail/dhcp-users/attachments/20150908/add5c682/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: not available
URL: 
<https://lists.isc.org/pipermail/dhcp-users/attachments/20150908/add5c682/attachment-0001.bin>

------------------------------

Message: 2
Date: Tue, 8 Sep 2015 10:01:06 +0100
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: dhcp6.client-linklayer-addr
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252

Kristof Van Doorsselaere <[email protected]> wrote:

> So now I?m trying to find out if there is any possibility to deny unknown 
> clients based on there mac addresses in a pool6 configuration?

If you can write a class (& subclasses) that match, you can always use an 
"allow members of ..." in a pool declaration. I'm assuming classes are 
implemented for IP6 ?





------------------------------

Message: 3
Date: Tue, 8 Sep 2015 11:06:43 +0200
From: Enno Rey <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: dhcp6.client-linklayer-addr
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Hi Kristof,

you might find 

https://www.insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/

helpful.

good luck with your setup ;-)

best

Enno

On Tue, Sep 08, 2015 at 08:51:25AM +0000, Kristof Van Doorsselaere wrote:
> Dear dhcp mailing list,
> 
> I???m testing latest dhcpd 4.3.3 to replace our current production dhcp 
> server, the new server will run dual stack (ipv4/ipv6). On our current dhcp 
> server, (for wired, non 802.1x  enabled networks), we currently implement: 
> deny unknown clients, so only known mac addresses will get an ip. I already 
> read, on several places, this is not possible for ipv6. But last week I found 
> out about  RFC 6939, and now I was trying to figure  out if my ipv6 relay 
> (fortigate firewall) supports this.
> 
> Based on the logs below it looks like, this rfc is supported, since the mac 
> address is logged correctly (using the log statement below)
> 
> Logs:
> 
> Sep  8 10:00:38 komo dhcpd: Lease for 2001:xxxx:xxxx:3d98:aaaa:8624:d059:50be 
> leased to 40:6c:8f:a:2e:1a
> 
> Sep  8 10:00:38 komo dhcpd: did not find: 
> (&(objectClass=dhcpHost)(dhcpClientId=00:01:00:01:1c:e4:9b:70:40:6c:8f:0a:2e:1a))
> 
> Sep  8 10:00:38 komo dhcpd: did not find clientid: 
> (&(objectClass=dhcpHost)(dhcpClientId=00:01:00:01:1c:e4:9b:70:40:6c:8f:0a:2e:1a))
> 
> Sep  8 10:00:38 komo dhcpd: Lease for 2001:xxxx:xxxx:3d98:aaaa:8624:d059:50be 
> leased to 40:6c:8f:a:2e:1a
> 
> Sep  8 10:00:38 komo dhcpd: Reply NA: address 
> 2001:xxxx:xxxx:3d98:aaaa:8624:d059:50be to client with duid 
> 00:01:00:01:1c:e4:9b:70:40:6c:8f:0a:2e:1a iaid = 0 valid for 2592000 seconds
> 
> Sep  8 10:00:38 komo dhcpd: Sending Relay-reply to 
> 2001:xxxx:xxxx:ab00:ffff:ffff:ffff:ffff port 547
> 
> 
> 
> 
> So now I???m trying to find out if there is any possibility to deny unknown 
> clients based on there mac addresses in a pool6 configuration? Is this 
> something on the roadmap? Or will it never be implemented? (For us this would 
> mean: stop using mac address based allow/deny rules and go for 802.1x all the 
> way (we currently implement this on wifi and a few wired networks) 
> 
> Remark: Our mac addresses are stored in ldap, and based on the logs (above) 
> it looks like dhcpv6 is searching for DUID rather then mac adress,  do we 
> have any options here?
> 
> Below some more info about my setup:
> 
> OS: Debian 8.1
> 
> Subnet cfg:
> 
> subnet6 2001:xxxx:xxxx:3d98::/64  {
> 
>         pool6 {
> 
> option dhcp6.name-servers 2001:xxxx:xxxx:ab00::1, 2001:xxxx:xxxx:ab00::2; 
> 
> option dhcp6.domain-search ???example.com"; 
> 
> ignore unknown-clients;
> 
> range6  2001:xxxx:xxxx:3d98:aaaa::/80; 
> 
> range6  2001:xxxx:xxxx:3d98:bbbb::/80 temporary;
> 
> }
> 
> }
> 
> 
> 
> Rfc 6939 specific cfg:
> 
> ## RFC  6939
> 
> option dhcp6.macaddr code 193 = string;
> 
> option dhcp6.leased-address code 194 = string;
> 
> option dhcp6.macaddr = binary-to-ascii(16, 8, ":", suffix(option 
> dhcp6.client-id, 6));
> 
> option dhcp6.leased-address = binary-to-ascii(16,16, ":", 
> substring(suffix(option dhcp6.ia-na, 24),0,16));
> 
> log (info, concat ("Lease for ",config-option dhcp6.leased-address, " leased 
> to ", config-option dhcp6.macaddr));
> 
> 
> 
> Thanks for your reply,
> 
> Kristof van Doorsselaere
> 



> _______________________________________________
> dhcp-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/dhcp-users


-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================


------------------------------

Message: 4
Date: Tue, 8 Sep 2015 09:34:35 +0000
From: Kristof Van Doorsselaere <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: dhcp6.client-linklayer-addr
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"

Ello,

Thanks for the link, but I already read that article, it was the trigger for me 
to test out RFC 6939.

In your config, you are using static ipv6 assignments based on the mac address. 
Since I?m setting up a dhcp for a high school, (we have more then 1000 devices, 
and lots of vlans, and devices are often moving from 1 place to another = other 
vlan) So I prefer to assign a dynamic address by using the range6 option. But 
so far I don?t see how to implement this.

Is there any way to specify a class that matches known clients (based on mac 
address found in ldap)??

Kristof Van Doorsselaere
hoofdmedewerker server- en netwerkbeheer 
----------------------------------


Hogeschool Gent
Directie Financi?n en ICT
Valentin Vaerwijckweg 1
BE-9000 Gent
T +32 9 243 35 20
HoGent.be






On 08/09/15 11:06, "[email protected] on behalf of Enno Rey" 
<[email protected] on behalf of [email protected]> wrote:

>Hi Kristof,
>
>you might find 
>
>https://www.insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/
>
>helpful.
>
>good luck with your setup ;-)
>
>best
>
>Enno
>
>On Tue, Sep 08, 2015 at 08:51:25AM +0000, Kristof Van Doorsselaere wrote:
>> Dear dhcp mailing list,
>> 
>> I???m testing latest dhcpd 4.3.3 to replace our current production dhcp 
>> server, the new server will run dual stack (ipv4/ipv6). On our current dhcp 
>> server, (for wired, non 802.1x  enabled networks), we currently implement: 
>> deny unknown clients, so only known mac addresses will get an ip. I already 
>> read, on several places, this is not possible for ipv6. But last week I 
>> found out about  RFC 6939, and now I was trying to figure  out if my ipv6 
>> relay (fortigate firewall) supports this.
>> 
>> Based on the logs below it looks like, this rfc is supported, since the mac 
>> address is logged correctly (using the log statement below)
>> 
>> Logs:
>> 
>> Sep  8 10:00:38 komo dhcpd: Lease for 
>> 2001:xxxx:xxxx:3d98:aaaa:8624:d059:50be leased to 40:6c:8f:a:2e:1a
>> 
>> Sep  8 10:00:38 komo dhcpd: did not find: 
>> (&(objectClass=dhcpHost)(dhcpClientId=00:01:00:01:1c:e4:9b:70:40:6c:8f:0a:2e:1a))
>> 
>> Sep  8 10:00:38 komo dhcpd: did not find clientid: 
>> (&(objectClass=dhcpHost)(dhcpClientId=00:01:00:01:1c:e4:9b:70:40:6c:8f:0a:2e:1a))
>> 
>> Sep  8 10:00:38 komo dhcpd: Lease for 
>> 2001:xxxx:xxxx:3d98:aaaa:8624:d059:50be leased to 40:6c:8f:a:2e:1a
>> 
>> Sep  8 10:00:38 komo dhcpd: Reply NA: address 
>> 2001:xxxx:xxxx:3d98:aaaa:8624:d059:50be to client with duid 
>> 00:01:00:01:1c:e4:9b:70:40:6c:8f:0a:2e:1a iaid = 0 valid for 2592000 seconds
>> 
>> Sep  8 10:00:38 komo dhcpd: Sending Relay-reply to 
>> 2001:xxxx:xxxx:ab00:ffff:ffff:ffff:ffff port 547
>> 
>> 
>> 
>> 
>> So now I???m trying to find out if there is any possibility to deny unknown 
>> clients based on there mac addresses in a pool6 configuration? Is this 
>> something on the roadmap? Or will it never be implemented? (For us this 
>> would mean: stop using mac address based allow/deny rules and go for 802.1x 
>> all the way (we currently implement this on wifi and a few wired networks) 
>> 
>> Remark: Our mac addresses are stored in ldap, and based on the logs (above) 
>> it looks like dhcpv6 is searching for DUID rather then mac adress,  do we 
>> have any options here?
>> 
>> Below some more info about my setup:
>> 
>> OS: Debian 8.1
>> 
>> Subnet cfg:
>> 
>> subnet6 2001:xxxx:xxxx:3d98::/64  {
>> 
>>         pool6 {
>> 
>> option dhcp6.name-servers 2001:xxxx:xxxx:ab00::1, 2001:xxxx:xxxx:ab00::2; 
>> 
>> option dhcp6.domain-search ???example.com"; 
>> 
>> ignore unknown-clients;
>> 
>> range6  2001:xxxx:xxxx:3d98:aaaa::/80; 
>> 
>> range6  2001:xxxx:xxxx:3d98:bbbb::/80 temporary;
>> 
>> }
>> 
>> }
>> 
>> 
>> 
>> Rfc 6939 specific cfg:
>> 
>> ## RFC  6939
>> 
>> option dhcp6.macaddr code 193 = string;
>> 
>> option dhcp6.leased-address code 194 = string;
>> 
>> option dhcp6.macaddr = binary-to-ascii(16, 8, ":", suffix(option 
>> dhcp6.client-id, 6));
>> 
>> option dhcp6.leased-address = binary-to-ascii(16,16, ":", 
>> substring(suffix(option dhcp6.ia-na, 24),0,16));
>> 
>> log (info, concat ("Lease for ",config-option dhcp6.leased-address, " leased 
>> to ", config-option dhcp6.macaddr));
>> 
>> 
>> 
>> Thanks for your reply,
>> 
>> Kristof van Doorsselaere
>> 
>
>
>
>> _______________________________________________
>> dhcp-users mailing list
>> [email protected]
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>
>
>-- 
>Enno Rey
>
>ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
>Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 
>
>Handelsregister Mannheim: HRB 337135
>Geschaeftsfuehrer: Enno Rey
>
>=======================================================
>Blog: www.insinuator.net || Conference: www.troopers.de
>Twitter: @Enno_Insinuator
>=======================================================
>_______________________________________________
>dhcp-users mailing list
>[email protected]
>https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: not available
URL: 
<https://lists.isc.org/pipermail/dhcp-users/attachments/20150908/a8805c36/attachment.bin>

------------------------------

_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users

End of dhcp-users Digest, Vol 83, Issue 6
*****************************************

Reply via email to