[Kea-users] yet another question about multiple subnets %)

[Simon]

3 <babut at yandex.ru> wrote:

>> RA are absolutely needed for DHCPv6 to work.  Properly working clients won't do anything but sit there with an fe80:: address on its interface if no RA tells it what else to assign and how to do so (https://www.rfc-editor.org/rfc/rfc5175.html) leaving your only option to manually assign address information to the interface on the client.  
> seriously? i just killed rad and reconnected the client. shall i tell you what has changed? NOTHING! do you think the dhcp client in windows is wrong? if so, then will have to redo the rfc for windows, and not windows for rfc. lol

Did you tell the client to release its leased address ? No ? In that case, the DHCP client will continue to keep the address configured until it expires (or another network event causes it to become invalid).


> 
>> If there is no router, then there will be no upstream routing and you have no need of anything other than an fe80:: as clients on the local network will discover each other and happily talk to each other's fe80:: address.
> exactly, there may not be a router. do you know what the problem with link-local addresses is? they can be random!

They shouldn’t be random, on an ethernet network they will be based on the MAC address and will be stable as long as the MAC address is stable.

> and often this is not what we need. besides, if everything is so good with link-local, then why do local unicast addresses exist? ;)

Different address types have different uses.
You may have seen 169.254.n.n addresses in the IPv4 world when there is no DHCP server present. These self-assigned addresses fulfil a similar role to some of the uses for IPv6 link local addresses - specifically they allow a group of devices to use multicast DNS to find each other. mDNS underpins a number of discovery functions around finding printers, network shares, etc.
But in a managed network, you would normally prefer to manage the addresses you put into the internal DNS. So rather than use a link local address for your internal web server, you would setup a ULA prefix and use that internally. As it’s independent of any upstream connections, it’s stable and under your control.
For networks without a full time management team (even if that is a one person team), setting that up is usually “too hard” and not required. For a typical home network, the users don’t care about all that, they just want stuff “to work”.


>>> one more time: address allocation and traffic routing are completely different
>>> tasks that practically do not overlap. at least because there may not be a
>>> router on the network, but ip addresses will still needs
>> In the case of DHCPv6 prefix delegation, DHCPv6 and routing absolutely overlap.  Routes must be added to the upstream router telling said router that your client has been allocated such prefix or you won't be routing anywhere as the router will have no idea that said prefix exists on your local network behind your DHCPv6 client.
> who said that need to route something somewhere? O_o

If you have a prefix delegation, it’s (in most cases) not very useful unless the rest of the network knows how to reach that prefix. But even where there isn’t any routing involved, you still need RAs to tell devices what prefix(es) are available.


Simon