[Dibbler] MAC/Link address Client Scope
thomson at klub.com.pl
Wed Jul 4 15:30:52 CEST 2012
On 04.07.2012 14:23, Marc Warne wrote:
> I'm trying to use Dibbler probably in a way it shouldn't, but I'm
> wondering if a) my request makes sense, and b) whether this is something
> that could be incorporated into Dibbler. I noted in the plan for 0.9.0
> that we have 'Better client classification support', so I'm hopeful.
> My problem is that I have a /48 (native or tunneled - shouldn't matter)
> going to eth0. There are many virtualised instances running, which are
> bridged against eth0. I want to assign a unique /64 prefix and initial
> IP address to each of these, so based on the client's IPv6 link or MAC
> address. The reason I need to do it based on these as opposed to the
> DUID is because I don't know the DUID of each virtualised instance, but
> I can easily keep track of a MAC/link -> prefix setup.
Virtualization is not a factor from the server perspective. I assume
that in your virtualization environment, each client will have a
different MAC, thus differnt link-layer address.
> It seems like Diddler, and all other DHCPv6 servers I know of, can only
> perform client-specific lookups based on a DUID (or remote ID), and I
> notice this also with Diddler's Client scope. I know DUIDs are the IPv6
> 'done thing', but because these are generated on the client side, I need
> a way to base things on MAC address, something I can control in
> virtualised setups.
> My questions to you:
> 1. Does this even make sense from an IPv6 perspective.
Yes, but some people may object. In a general case, the reservation
could be done using link-layer address.
> 2. Is there any reason Diddler couldn't be extended to have something
> like a 'client mac 00:00:00:00:00:00' client scope?
Yes, many. The first reason is that is couldn't be extended, because MAC
address is often not available. This was beaten to death, but let's go
over it quickly again. There are 3 possible ways a server could possibly
learn client's MAC address:
a) from Ethernet frame. That won't work if traffic goes through relay
b) from DUID-LL or DUID-LLT. RFC3315 forbids looking into the DUID.
Besides of being a wrong thing to do, that also won't work, because
client with a given MAC address can use different DUID type, e.g.
DUID-EN or DUID-UUID (or others, I saw on the wire some device with DUID
type 14. Strange, uncommon, but valid).
c) using source address and extracting MAC from EUI-64. That should be
available for direct traffic (simply src address of the UDP packet) or
relayed (peer addr field in RELAY-FORW message). This would usually
work, but there are cases when it won't. First, if client uses privacy
extensions (RFC4941). The other one if client and server support
unicast, some traffic will be sent from client global address.
So instead of doing MAC based reservations, I plan to implement
link-layer based reservations. In most cases it will be equivalent to
MAC reservations. The only case where it won't work will be with
unicast, but that can be solved (server could refuse to start when both
link-layer reservations and unicast are enabled). Despite those
shortcomings, I plan to implement such a feature, because many people
> 3. Has any work been started on better client classification support?
There was some work done. It helped a lot that there was someone who
implemented it and donated a patch (thanks, Mickael Marchand!). See
doc/examples/server-per-client.conf in GIT code. There's commented out
section that has client classification support, based on link-local
address. You can try this. Server will parse that clause correctly, but
I have not checked if it will actually use it. You are more than welcome
to try it. I would appreciate if you could report if it is working and
if it fails, provide details how it failed (logs, traffic capture,
coredump if it crashed, etc.) As we are talking about development code,
I think dibbler-devel would be more appropriate list to discuss this.
It is true that work towards 0.9.0 progresses slowly. I'm currently busy
with other things. I'm working on DHCP implementation in BIND10
infrastructure, also occasionally touching ISC DHCP code. Upcoming IETF
preparation takes a lot of time. As a result, Dibbler work is slow. But
it is not stalled. Dibbler was not able to do secure DNS Updates, which
was a huge flaw in my opinion. I managed to implement support for TSIG,
so it is now able to do secure updates. Dibbler now also compiles on
Solaris 11 (it doesn't work yet, but it is close). Dibbler is now able
to reserve prefixes for specific clients.
I'd like to make a brief comment about 0.9.0 roadmap. By saying "better
client classification support" I originally planned to work on class
support, as described in section 4.7 "Introduction to client
classification". Note that it is a slightly different feature compared
to what was discussed here. Currently it supports only vendor-spec and
vendor-class options, because that was what the patch contributor cared
about. It would be nice to make this feature more useful by extending it
to other fields. Unfortunately, this feature is a low priority for me.
Finally, it really helps a lot if people are contributing patches.
It's Dibbler, not Diddler.
More information about the Dibbler