Re: [Dnsmasq-discuss] dnsmasq on an IPv4 /32 interface
On 22/9/20 4:22 pm, Nicolas Cavallari wrote: > On 21/09/2020 21:32, Paul Gear wrote: >> Hi all, >> >> I've been trying to solve the same problem described in this blog post: >> https://blog.fhrnet.eu/2020/03/07/dhcp-server-on-a-32-subnet/ >> >> In a nutshell, the situation is a VM host which performs routing and >> firewalling for all its guests, providing an isolated IPv4 /32 (and in >> my case an IPv6 /64 or /128 as well) to each VM guest, and using >> interface routes on the host to direct traffic to each guest, without >> wasting IPv4 addresses on /31 or /30 point-to-point links. >> ... > This sounds like the use case for shared-network: > > shared-network=virbr13,192.168.1.26 > > or > > shared-network=172.16.0.1,192.168.1.26 > > Alternatively, i sent this patch a while ago to be able to ignore any > matching, but my use case is different. I can send an updated version if > people are interested. > > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q1/012070.html Ah, perfect - thanks very much, Nicolas. I was doing my testing using the OS-packaged dnsmasq on my laptop, which was 2.79. Looks like shared-network was added in 2.81. I'll upgrade and do some testing, but it looks from the description like this is exactly what I'm looking for. Much appreciated. Regards, Paul ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq on an IPv4 /32 interface
On 21/09/2020 21:32, Paul Gear wrote: > Hi all, > > I've been trying to solve the same problem described in this blog post: > https://blog.fhrnet.eu/2020/03/07/dhcp-server-on-a-32-subnet/ > > In a nutshell, the situation is a VM host which performs routing and > firewalling for all its guests, providing an isolated IPv4 /32 (and in > my case an IPv6 /64 or /128 as well) to each VM guest, and using > interface routes on the host to direct traffic to each guest, without > wasting IPv4 addresses on /31 or /30 point-to-point links. > > The post claims that the configuration noted (a single /32 allocated to > the host which is configured on every client-facing interface) is only > possible at present with ISC DHCP. I've tested a number of different > configurations of dnsmasq, and this seems to be correct. I'm hoping > someone experienced in the dnsmasq code base can confirm or deny this. > > Assuming this is currently a limitation, I'd like to work on adding > support to dnsmasq for this scenario. I'm not experienced with the code > base (although I've read some of the relevant portions and believe it > should be possible), so I'm hoping also for some guidance on whether > this functionality would be accepted into the code base, and if so, how > it might appear in the configuration. > > My initial thought was that there wouldn't need to be any explicit > configuration; rather, if a DHCP request is received on an interface > with a /32 mask (or perhaps on an interface with a non-unique address on > the host), the usual restrictions around interface matching would be > relaxed, and an address would be given out either from the > statically-defined hosts, or from a pool which doesn't match any > interface on the host. When giving out IPv6 addresses, my thought was > that things would mostly work the same if a DHCPv6 request was received > on an interface with only link-local addressing configured. This sounds like the use case for shared-network: shared-network=virbr13,192.168.1.26 or shared-network=172.16.0.1,192.168.1.26 Alternatively, i sent this patch a while ago to be able to ignore any matching, but my use case is different. I can send an updated version if people are interested. http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q1/012070.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dnsmasq on an IPv4 /32 interface
Hi all, I've been trying to solve the same problem described in this blog post: https://blog.fhrnet.eu/2020/03/07/dhcp-server-on-a-32-subnet/ In a nutshell, the situation is a VM host which performs routing and firewalling for all its guests, providing an isolated IPv4 /32 (and in my case an IPv6 /64 or /128 as well) to each VM guest, and using interface routes on the host to direct traffic to each guest, without wasting IPv4 addresses on /31 or /30 point-to-point links. The post claims that the configuration noted (a single /32 allocated to the host which is configured on every client-facing interface) is only possible at present with ISC DHCP. I've tested a number of different configurations of dnsmasq, and this seems to be correct. I'm hoping someone experienced in the dnsmasq code base can confirm or deny this. Assuming this is currently a limitation, I'd like to work on adding support to dnsmasq for this scenario. I'm not experienced with the code base (although I've read some of the relevant portions and believe it should be possible), so I'm hoping also for some guidance on whether this functionality would be accepted into the code base, and if so, how it might appear in the configuration. My initial thought was that there wouldn't need to be any explicit configuration; rather, if a DHCP request is received on an interface with a /32 mask (or perhaps on an interface with a non-unique address on the host), the usual restrictions around interface matching would be relaxed, and an address would be given out either from the statically-defined hosts, or from a pool which doesn't match any interface on the host. When giving out IPv6 addresses, my thought was that things would mostly work the same if a DHCPv6 request was received on an interface with only link-local addressing configured. Thanks in advance - I hope all this makes sense and look forward to discussing it further with you. Regards, Paul ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq on an IPv4 /32 interface
On Tue, Sep 22, 2020 at 05:32:56AM +1000, Paul Gear wrote: > Hi all, > > I've been trying to solve the same problem described in this blog post: > https://blog.fhrnet.eu/2020/03/07/dhcp-server-on-a-32-subnet/ Interesting read, however I not sure how interesting the "problem" was. > In a nutshell, the situation is a VM host which performs routing and > firewalling for all its guests, providing an isolated IPv4 /32 (and in > my case an IPv6 /64 or /128 as well) to each VM guest, and using > interface routes on the host to direct traffic to each guest, without > wasting IPv4 addresses on /31 or /30 point-to-point links. > > The post claims that the configuration noted (a single /32 allocated to > the host which is configured on every client-facing interface) is only > possible at present with ISC DHCP. I've tested a number of different > configurations of dnsmasq, and this seems to be correct. I'm hoping > someone experienced in the dnsmasq code base can confirm or deny this. > > Assuming this is currently a limitation, I'd like to work on adding > support to dnsmasq for this scenario. I'm not experienced with the code > base (although I've read some of the relevant portions and believe it > should be possible), so I'm hoping also for some guidance on whether > this functionality would be accepted into the code base, and if so, how > it might appear in the configuration. > > My initial thought was that there wouldn't need to be any explicit > configuration; rather, if a DHCP request is received on an interface > with a /32 mask (or perhaps on an interface with a non-unique address on > the host), the usual restrictions around interface matching would be > relaxed, and an address would be given out either from the > statically-defined hosts, or from a pool which doesn't match any > interface on the host. When giving out IPv6 addresses, my thought was > that things would mostly work the same if a DHCPv6 request was received > on an interface with only link-local addressing configured. > > Thanks in advance - I hope all this makes sense and look forward to > discussing it further with you. I think that discussion will go quickly silent when only one person can reproduce the challenge. > Regards, > Paul Groeten Geert Stappers -- Silence is hard to parse ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
