3 <[email protected]> wrote: >>> "shared network" is not about how to allocate multiple addresses(it doesn't >>> matter if we have one pool or several), but about how to combine several >>> pools into one. >> Almost - it’s about how to have multiple (IPv4) subnets/(IPv6) prefixes on >> one wire. > where do you see even a word about this in the documentation? in any > documentation, not only for kea, the "shared network" is referred to as a > pooled pool of addresses from which the dhcp server will take an address to > assign to the client. could you quote exactly the place where it says about > allocating multiple addresses at the same time from the pooled pool?
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”. 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. >> As has already been said, your client will need to ask for multiple >> addresses/prefixes. The client knows (for IPv6) the prefixes configured for >> any link from the RAs it receives. > no RA is needed for dhcpv6 to work. 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. This is different to IPv4 where DHCP is the primary means of client config, and clients will default to using DHCP unless configured not to. >> >> Having said that, if there is a GUA and a ULA advertised, then it would be >> logical for a client to request addresses from both and use them accordingly >> - ULA for communications with other ULA addresses, GUA for everything else. > do you want to talk about how this can be implemented? the answer is simple- > you do not need to tell the client how to live, especially since you do not > have any levers to force him to fulfill your requirements. the router can at > least block traffic from the rebel, but the dhcp server does not have such an > opportunity. therefore, all you can do as a dhcp server is to offer the > client all the prefixes that you have- the client will choose the ones he > needs and notify you of his choice in a reply message. you will only have to > keep track of this connection. it's obvious! dhcp is not a tool for political > repression of clients, like go here and don't go there %). a router should > deal with such repression- it exists for this very purpose. what makes you > think that dhcpv6 is being developed by mad people? :D > 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 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. 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. 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
