> Allocating multiple addresses from one pool or multiple pools is a different > question to shared networks. > You can have multiple pools within one prefix; you can have a single pool in > each of multiple prefixes; or any combination (e.g. multiple pools from > multiple prefixes). One reason you might want multiple pools within a single > prefix could be, for example, so that you can group certain types of clients > into address ranges. For example, you might want to put VoIP phones into > their own address range (defined by a pool) so that you can limit their > access to anything but the phone service they connect to. > One reason you might want multiple prefixes on one link is if you want to use > ULA addresses internally (which would make internal services still work if > your upstream connectivity goes down and your global address prefix(es) > disappear) and use GUA addresses for everything else. > The shared network declaration is how you tell the DHCP server that all the > prefixes configured in the shared network are on the same wire. It’s not > something I’ve used with IPv6, nor with KEA, but in the IPv4 world it can > work like this : > Suppose you have a server connected to a shared network with 192.168.1.0/24 > and 192.168.2.0/24 in use, and the server had the address 192.168.1.1. If you > didn’t tell the server that it’s a shared network, then not only would it not > allocate addresses from the 192.168.2.0 subnet, it would NACK any requests > from clients for those addresses. The shared network statement tells the > server “all these addresses should be considered equal”. what i told you about it. in general, prefixes are not important, the dhcp server operates with pools. you can generally specify the prefix "::/0" and forget about prefixes.
> And in the IPv4 world it is possible for a client to ask for multiple > addresses - it just needs to make multiple requests using a different > client-ID for each one, and the server will handle them individually. in the world of dhcpv6, this cannot be done, since the rfc directly requires that one client has one identifier(windows follows this requirement strictly). ps: i see that you don't know ipv6 very well either ;) > No RAs will result in no prefixes (other than fe80 link local) being > available on the link. For DHCPv6 to be used at all, there must be an RA for > at least one prefix, and it must (IIRC) set the M flag to indicate to devices > that this is a managed network offering DHCP - without this, the clients will > NOT even ask for an address. You can also optionally turn off the A flag to > tell clients that they should not auto-configure (SLAAC) addresses in the > prefix. why don't you just test this statement in practice? ;) if you are not confused at least by the fact that in windows and *nix, different daemons are engaged in processing RA and dhcp, not communicating with each other in any way %\ > As I have pointed out, this is a known issue and there isn’t a simple answer. > As to devices using ULA and GUA addresses, once they have them both then > there are routing rules (priorities) which will prefer ULA over GUA where the > other end of the connection is a GUA address. As to how the device knows to > talk to something at a GUA address, that would either be via multicast DNS, > or via regular DNS for things like internal web servers at fixed addresses. > And as I’ve already said, AT THE MOMENT there isn’t a way to signal to > clients that they need to ask for multiple address in multiple prefixes. I > haven’t looked, but I would not be surprised if at least some clients will > default to asking for at least one ULA and at least one GUA when it detects > the two different types of prefix. > And while DHCP is not able to control what traffic any device can engage in, > it can manage the addresses issued - see the note above about putting (e.g.) > VoIP phones into their own range of addresses so different router/firewall > rules can be applied. In this respect, it’s not much different to IPv4 where > such techniques have been used for a long time. yes, there is a problem(at least on win 10) of the client choosing the suitable address(when he has several of them) in each case, but this is not a problem of the dhcp server, this is a problem of the dhcp client, we cannot and should not save all kittens. i'm not an engineer or an admin, i'm a simple home user, but if to think about this problem for a day or two, i think can find a solution %D at least the problem doesn't look complicated with the available start data. > I have a feeling that you do not understand IPv6 too well, that’s > understandable as some aspects are quite different to IPv4 - IPv6 is not just > IPv4 with more address bits. > Two resources that come to mind are : > https://ipv6.he.net/certification/ > You don’t need to go all the way through and get certified - just working > through the stages which introduces concepts at a controlled rate making it > easy to learn about them will help. When I wore it to my local LUG, the tee > short was described as the "geekiest tee shirt ever” :D > https://github.com/becarpenter/book6/blob/main/Contents.md > While this is incomplete and there are whole chapters still to be written, > there is some stuff in there which you should find helpful. It’s written by > people who really do know IPv6 and have mostly been involved in it’s design > over the years. actually, to understand something just read the source documentation, but the rfc for dhcpv6 is not easy reading :\ but there is no alternative to this. so refer to the places in the rfc(give quotes), and not someone's free narrative. you've never done that ;) -- 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 Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
