Closed FelixJacobi closed 2 years ago
I also noticed that, if you have two colliding link-local addresses, that the client is identified wrong. My router is dual-homed in two subnets. In each, there is a host with a manually assigned link-local address fe80::2
(derived from global addresse like 2001:db8::2
or IPv4 addresses 192.168.1.2
to ease recognizing the hosts), but these are two different VLANs and also two different hosts with two different MAC addresses. When the first host requested and received the prefix, everything is fine. But the second host is also receiving the prefix of the first one instead of the prefix configured for it's MAC address. I saw that the Link-local address to MAC cache is just simple map. Would it make sense to include the interface name in the cache to avoid such situations?
Hi @FelixJacobi,
regrarding the first issue I think you are right - either the comment or the code is lying. But according to your investigations looks like the comment is true. Can you please prepare a PR?
Regarding the second - might be worth an issue on its own. I understand it might be practical to have a predefined Link Local Address for the routers on a first sight. But in theory they would not need it as the clients do not care about how the address of the router - which announces itself as router anyway - looks like. So in your place I would give them unique addresses even of a ULA-space but not try to change anything in the LLA-space. LLAs actually are a core element to make dhcpy6d work and to work around the DHCPv6 flaws. At least this might be a short-term fix. In the log run adding the interface to the cache sounds interesting, but should be proved carefully and thus will take some time.
Hi @FelixJacobi, is the interface in the class definition for class fixed_dmz_office at the bottom of your script missing?
regrarding the first issue I think you are right - either the comment or the code is lying. But according to your investigations looks like the comment is true. Can you please prepare a PR?
See #53.
Regarding the second - might be worth an issue on its own.
Yes. Definitely.
I understand it might be practical to have a predefined Link Local Address for the routers on a first sight.
But in theory they would not need it as the clients do not care about how the address of the router - which announces itself as router anyway - looks like.
Yeah, but not always. You probably have turned off the acceptance of RAs for security reasons (especially on servers) and configuring everything by hand. That's almost my setup currently, The only dynamic thing I am using on servers, is DHCPv6 to distribute the dynamic prefix by the ISP as there is no other way to receive it. ULA, (default) routes and everything else is configured by hand.
So in your place I would give them unique addresses even of a ULA-space but not try to change anything in the LLA-space.
Yes, this could work for the most systems, like Linux kernel-based ones (you can set every address there as gateway, and it works). But I already saw several systems which were only able to use link-local addresses as gateway - mostly a fe80::
prefix for the gateway address was forced on configuring and similar stuff. So I decided for strictly using link-local addresses for that case to keep things consistent.
LLAs actually are a core element to make dhcpy6d work and to work around the DHCPv6 flaws. At least this might be a short-term fix.
Yeah, it would be a sensitive area of dhcpy6d which must be changed. For now, I added a subnet number to the link local addresses. So, no need to change anything here yet.
In the log run adding Yes. the interface to the cache sounds interesting, but should be proved carefully and thus will take some time.
I will look if I will find some hours in the next time to work on this and to test and deploy it on several systems before it becomes part of the official dhcpy6d code base.
For the first issue please check latest packages at https://github.com/HenriWahl/dhcpy6d/releases/tag/latest
Hi,
I tried to set up prefix delegation with one Debian Bullseye machine acting as host running the dhcpy6d server and another one acting as a client using WIDE DHCPv6 client.
Server configuration
/etc/dhcpy6d.conf
:/etc/dhcpy6-clients.conf
:Client configuration
/etc/wide-dhcpv6/dhcp6c.conf
:My plans are to assign prefixes to particular clients. Therefor, I decided to assign prefixes only to clients, not on class level.
But: This does not work. The WIDE DHCPv6 client always reports that it received no addresses:
The log of dhcpy6d always says:
When I am removing the
send ia-pd 0;
on WIDE DHCPv6 side, everything works fine (except for that of course no prefixes are assigned then). I started with adding some debug statements around https://github.com/HenriWahl/dhcpy6d/blob/eb838bbb3e0bac513898a77f4f037ed2eed720b8/dhcpy6d/handler.py#L497 and their are confirmed, that prefixes are not assigned. After digging around in the code, I found, that the only place where prefixes from client configuration are added , which is located infrom_config.py
, which is only called fromclient/__init__.py
. Adding further statements there, it showed me that the correspondingif
/else
branch inclient
is never called when a prefix is requested. I finally found the following https://github.com/HenriWahl/dhcpy6d/blob/eb838bbb3e0bac513898a77f4f037ed2eed720b8/dhcpy6d/client/__init__.py#L222 statement. It looks a bit wrong to me, as the comment does not match to the real behavior of this statement. I changed it to look like the following way:Now, prefix delegation works with my configuration (the addresses and the prefix from client configuration entry are given to the client). Am I correct and the if statement is probably wrong? Or do I miss something in my configuration?