MAC addresses in DHCPv6

Angelo Failla pallotron at fb.com
Tue Jun 24 05:54:31 UTC 2014


On 6/23/14, 11:27 AM, "Tomek Mrugalski" <tomasz at isc.org> wrote:


>PROPOSED SOLUTION
>
>[Š]
>It seems that we need to do the following tasks:
>
>a) we will pick which mechanisms we want to support first. It seems that
>1 (extract from DUID) and 4 (RFC6939, client link address option) are
>reasonable first choices. Hopefully, we'll work on the remaining ones at
>some later time.

FWIW in FB we actually use option 1 (as our internal inventory system as
info on all MAC addresses for all server interfaces and our NIC firmwares
are configured to use DUID-LL[T]); option 4 is not supported by our relay
agents.
What I do in my hook is getting DuidPtr structure, then get the uint8_t
vector and extract the mac address field from it. An utility method in
Pkt6 would be really appreciated and would make my hook code simpler :)

>b) we will extend Pkt6 with 2 extra fields:
>- MAC address (will keep the MAC) - probably varchar(20) will be the
>format here (in some access technologies MAC may be up to 20 bytes
>long).
>- MAC source - that will be an enum value that will specify where the
>MAC info came from.

Ditto.

>Once those tasks are completed, we will make MAC addresses accessible in
>DHCPv6. The server will not be able to do anything useful with them on
>its own, but it will be possible to write hooks that will use them.
>Also, this will lay solid foundation for the next feature: host
>reservation. I'll send out a mail about that soon.

Host reservation is actually our main application in FB, we do not use
dynamic allocation in our infra.

>Thoughts? Comments? Volunteers?

Let me know when you guys have implemented this and I can test it in our
environment.



More information about the kea-dev mailing list