3 <[email protected]> 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 -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
