Re: [Dnsmasq-discuss] Announce: dnsmasq-2.81

2020-04-12 Thread Matthias Andree
Am 12.04.20 um 00:28 schrieb Simon Kelley:
> After 18 long months, tonight I released dnsmasq 2.81.
>
> The next release should happen to a shorter timescale.
>
> http://thekelleys.org.uk/dnsmasq/dnsmasq-2.81.tar.gz
>
Simon thank you,

I have updated FreeBSD's ports last night, the update should have
propagated.

By convention, the FreeBSD binary packages are derived from the 2020Q2
quarterly branch, which was using 2.80 + some fixes.

Up-to-date packages will soon (normally a few days) available from
FreeBSD's "latest" builds, for a configuration example, see "man
pkg.conf" and look for "latest", or can be built from the ports system now.

Regards,
Matthias



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq

2020-04-12 Thread Uwe Schindler
Hi,

although this is no longer fully related to dnsmasq, just a few sentences on 
top:

> >> There's a slightly more special case for us: We have one central firewall
> (which
> >> gets the full /56 net on the upstream interface routed to it) and most
> gateways
> >> are separate nodes
> >> (i.e. most VLANs are not connected to the central FW).
> >> So I believe in that case I just need an ip6tables rule (per /64 subnet) 
> >> on the
> >> central firewall to redirect all traffic to the gateway for the /64 subnet,
> right?
> >
> > It's important to don't have the /56 or /64 network assigned to an interface
> on the router (otherwise you would need proxyNDP)!
> 
> Noted. Indeed, that's reasonable, and achieved by design for those VLANs not
> connected to the central router ;-).
> 
> > If it's prefix delegation, don't assign the 64 or 54 subnet to any 
> > interface on
> the main router, just bring interfaces up and assign link-local-addresses to
> them! On the central firewall just do routing with link-local addresses
> (basically, this subnet goes to this adaptor and this mac address - as link 
> local
> addresses are basically MAC addresses). Of course the packet filtering uses 
> the
> global addresses, but the routing is done with link-local.
> >
> > The router box gets the packets from the provider all delegated to its own
> link-local address of the upstream interface (that's what most providers do,
> including DSL providers with PPP or servers in data centers like Hetzner). So 
> all
> incoming packets are sent to the same fe80: address based on the MAC
> known to upstream or negotiated via PPP and the router just forwards them
> based on the global address inside of the packets.
> 
> In our case, they waste a dedicated /64 global address network for the
> connection network between our firewall and their endpoint... That also works,
> but it's rather wasteful of course ;-).

That's not so bad, because you get a global IPv6 address on the upstream 
router, so it can appear on traceroutes (see below). So that's not too bad. If 
you won't have that, to correctly make the router inbetween appear in 
traceroutes, you would have to assign some other IPv6 from another /64 subnet. 
Now you have that one on the upstream interface, the router can respond with 
ICMPv6 messages as reply on traceroute or unroutable addresses. Otherwise the 
response from e.g., traceroute would get lost.

> > In the routing table of the main firewall you just add entries like global
> subnetA/64 goes to link-local address fe80: on interface XY, and so on. If
> you don't like the automatic assigned link-local-addresses based on the mac
> interface you can easily change them. In my office I have the router assigned
> fe80::1, you could assign fe80::2, fe80::3 to the secondary routers's network
> interfaces and then routing tables look easy:
> >
> > 2001:abcd:1234:1::/64 => fe80::2@en1
> > 2001:abcd:1234:2::/64 => fe80::3@en1
> > 2001:abcd:1234:3::/64 => fe80::4@en1.24 (a VLAN #24 on en1)
> > 2001:abcd:1234:3::/64 => fe80::4@en2 (other network interface)
> >
> > Fe80::2, 3, 4 are the separate boxes which route the traffic and have the
> dnsmasq. If you don't want to use fe80 link-local addresses, you can use ULAs,
> but for routing purposes the link-local ones with interface name are the 
> easiest.
> 
> Thanks, that example clarified it for me. Good thinking in using the 
> link-local
> addresses here, that's completely sufficient. It really helps to talk about 
> these
> things to clear up my mind from the IPv4 legacy of thinking.

This is generally known as "next-hop routing". A router just gives the correct 
link-local address, so the packet with a global address can get closer to its 
target. This makes routing tables easy to maintain.

The general recommendation is to always only use link-local addresses in 
routing tables (because otherwise the router would need to send NDP packets on 
its own, just to find the next-hop target!

Nevertheless, each router should have a global address, too (so it can be 
pinged). You can assign it to the interface with the corresponding prefix. On 
the upstream router / firewall it would be the one from the "wasted network" 
(see above); on the client-facing router one from the target /64 network 
(2001:xx::1). Between upstream router and client facing routers, only 
link-local addresses are used.

> > Another idea is to use one of the /64 subnets as the "inter-router"
> communication, but that's not needed for IPv6, because we have link-local-
> addresses for that purpose!

As noted before, nevertheless all nodes on the route *should* have a global 
address, too (but those should not be used in the routing table). The 
global/routeable address is needed to transfer ICMPv6 messages. The router 
can't otherwise be pinged by traceroute or tell the client that a route is not 
working via ICMP.

> > On the internal routers you only assign the full global 64 subnet to the 
> > client
> 

[Dnsmasq-discuss] ignore mac address for one of the dhcp

2020-04-12 Thread John Siu
I am running dnsmasq on a multiple port box. Following are dhcp config for
the lan and dmz ports:

---

## LAN
dhcp-range=tag:lan,::1,constructor:lan,ra-names,72h # IPv6
dhcp-range=tag:lan,172.16.168.130,172.16.168.250,72h # IPv4
dhcp-option=tag:lan,option:router,172.16.168.1 # option 3 default gw
dhcp-option=tag:lan,option:dns-server,172.16.168.1

## DMZ
dhcp-range=tag:dmz,::1,constructor:dmz,ra-names,72h # IPv6
dhcp-range=tag:dmz,10.10.10.100,10.10.10.120,72h # IPv4
dhcp-option=tag:dmz,option:router,10.10.10.1 # option 3 default gw
dhcp-option=tag:dmz,option:dns-server,10.10.10.1

---

They work correctly for network connected to those ports. However, I am
having issue with the switch which connect to both dmz and lan ports with
different VLANs. As those VLAN ports share the same mac address, sometimes
the switch will pick up IP from the lan side, and sometimes from the dmz
side.

How can I make dnsmasq only serve IP on the lan side for this specific mac
address?

Thank you!
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq

2020-04-12 Thread Uwe Schindler
Hi,

> thanks for the elaborate reply!

No problem!

> There's a slightly more special case for us: We have one central firewall 
> (which
> gets the full /56 net on the upstream interface routed to it) and most 
> gateways
> are separate nodes
> (i.e. most VLANs are not connected to the central FW).
> So I believe in that case I just need an ip6tables rule (per /64 subnet) on 
> the
> central firewall to redirect all traffic to the gateway for the /64 subnet, 
> right?

It's important to don't have the /56 or /64 network assigned to an interface on 
the router (otherwise you would need proxyNDP)! 

If it's prefix delegation, don't assign the 64 or 54 subnet to any interface on 
the main router, just bring interfaces up and assign link-local-addresses to 
them! On the central firewall just do routing with link-local addresses 
(basically, this subnet goes to this adaptor and this mac address - as link 
local addresses are basically MAC addresses). Of course the packet filtering 
uses the global addresses, but the routing is done with link-local.

The router box gets the packets from the provider all delegated to its own 
link-local address of the upstream interface (that's what most providers do, 
including DSL providers with PPP or servers in data centers like Hetzner). So 
all incoming packets are sent to the same fe80: address based on the MAC 
known to upstream or negotiated via PPP and the router just forwards them based 
on the global address inside of the packets.

In the routing table of the main firewall you just add entries like global 
subnetA/64 goes to link-local address fe80: on interface XY, and so on. If 
you don't like the automatic assigned link-local-addresses based on the mac 
interface you can easily change them. In my office I have the router assigned 
fe80::1, you could assign fe80::2, fe80::3 to the secondary routers's network 
interfaces and then routing tables look easy:

2001:abcd:1234:1::/64 => fe80::2@en1
2001:abcd:1234:2::/64 => fe80::3@en1
2001:abcd:1234:3::/64 => fe80::4@en1.24 (a VLAN #24 on en1)
2001:abcd:1234:3::/64 => fe80::4@en2 (other network interface)

Fe80::2, 3, 4 are the separate boxes which route the traffic and have the 
dnsmasq. If you don't want to use fe80 link-local addresses, you can use ULAs, 
but for routing purposes the link-local ones with interface name are the 
easiest.

Another idea is to use one of the /64 subnets as the "inter-router" 
communication, but that's not needed for IPv6, because we have 
link-local-addresses for that purpose!

On the internal routers you only assign the full global 64 subnet to the client 
facing network adaptors. The connection to the router uses a link-local address 
only (as described before). No additional firewalling is needed, you just need 
to setup routing entries like above (the other way round).

> > Just some recommendation: I'd NOT go with DHCPv6, as no Chromebook or
> Android device supports it. I'd go for SLAAC. Very easy. As you can setup a
> separate /64 subnet (up to 256 of them), you have enough flexibility to handle
> all of them in a separate network with full /64 SLAAC address space. Each of
> those networks have firewalling on the router box and are delegate to the
> network switch .e.g, via VLANs.
> 
> I know (while I knew about Android, good point about the Chromebooks!). Our
> main usecase is addressing of Linux servers (i.e. there will only be "DHCP
> reserved" entries).
> Indeed, for a general purpose network (one of those /64s), we need to think
> whether we'll go with DHCPv6 (and lose Android and Chromebooks) or really
> stay with DHCPv6. For now, I'll plan with DHCPv6 ;-).

No problem. You can have both, depending on subnet.

Uwe


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq

2020-04-12 Thread Oliver Freyermuth
Hi,

Am 12.04.20 um 20:12 schrieb Uwe Schindler:
> Hi,
> 
>> thanks for the elaborate reply!
> 
> No problem!

and thanks again :-). 

> 
>> There's a slightly more special case for us: We have one central firewall 
>> (which
>> gets the full /56 net on the upstream interface routed to it) and most 
>> gateways
>> are separate nodes
>> (i.e. most VLANs are not connected to the central FW).
>> So I believe in that case I just need an ip6tables rule (per /64 subnet) on 
>> the
>> central firewall to redirect all traffic to the gateway for the /64 subnet, 
>> right?
> 
> It's important to don't have the /56 or /64 network assigned to an interface 
> on the router (otherwise you would need proxyNDP)! 

Noted. Indeed, that's reasonable, and achieved by design for those VLANs not 
connected to the central router ;-). 

> If it's prefix delegation, don't assign the 64 or 54 subnet to any interface 
> on the main router, just bring interfaces up and assign link-local-addresses 
> to them! On the central firewall just do routing with link-local addresses 
> (basically, this subnet goes to this adaptor and this mac address - as link 
> local addresses are basically MAC addresses). Of course the packet filtering 
> uses the global addresses, but the routing is done with link-local.
> 
> The router box gets the packets from the provider all delegated to its own 
> link-local address of the upstream interface (that's what most providers do, 
> including DSL providers with PPP or servers in data centers like Hetzner). So 
> all incoming packets are sent to the same fe80: address based on the MAC 
> known to upstream or negotiated via PPP and the router just forwards them 
> based on the global address inside of the packets.

In our case, they waste a dedicated /64 global address network for the 
connection network between our firewall and their endpoint... That also works, 
but it's rather wasteful of course ;-). 

> In the routing table of the main firewall you just add entries like global 
> subnetA/64 goes to link-local address fe80: on interface XY, and so on. 
> If you don't like the automatic assigned link-local-addresses based on the 
> mac interface you can easily change them. In my office I have the router 
> assigned fe80::1, you could assign fe80::2, fe80::3 to the secondary 
> routers's network interfaces and then routing tables look easy:
> 
> 2001:abcd:1234:1::/64 => fe80::2@en1
> 2001:abcd:1234:2::/64 => fe80::3@en1
> 2001:abcd:1234:3::/64 => fe80::4@en1.24 (a VLAN #24 on en1)
> 2001:abcd:1234:3::/64 => fe80::4@en2 (other network interface)
> 
> Fe80::2, 3, 4 are the separate boxes which route the traffic and have the 
> dnsmasq. If you don't want to use fe80 link-local addresses, you can use 
> ULAs, but for routing purposes the link-local ones with interface name are 
> the easiest.

Thanks, that example clarified it for me. Good thinking in using the link-local 
addresses here, that's completely sufficient. It really helps to talk about 
these things to clear up my mind from the IPv4 legacy of thinking. 

> 
> Another idea is to use one of the /64 subnets as the "inter-router" 
> communication, but that's not needed for IPv6, because we have 
> link-local-addresses for that purpose!
> 
> On the internal routers you only assign the full global 64 subnet to the 
> client facing network adaptors. The connection to the router uses a 
> link-local address only (as described before). No additional firewalling is 
> needed, you just need to setup routing entries like above (the other way 
> round).

Thanks, that cleared up my last question completely. Now I just have to explain 
my colleagues and we can start implementing that in the next weeks (in slow 
steps, but it seems much more straightforward than I thought) :-). 

>>> Just some recommendation: I'd NOT go with DHCPv6, as no Chromebook or
>> Android device supports it. I'd go for SLAAC. Very easy. As you can setup a
>> separate /64 subnet (up to 256 of them), you have enough flexibility to 
>> handle
>> all of them in a separate network with full /64 SLAAC address space. Each of
>> those networks have firewalling on the router box and are delegate to the
>> network switch .e.g, via VLANs.
>>
>> I know (while I knew about Android, good point about the Chromebooks!). Our
>> main usecase is addressing of Linux servers (i.e. there will only be "DHCP
>> reserved" entries).
>> Indeed, for a general purpose network (one of those /64s), we need to think
>> whether we'll go with DHCPv6 (and lose Android and Chromebooks) or really
>> stay with DHCPv6. For now, I'll plan with DHCPv6 ;-).
> 
> No problem. You can have both, depending on subnet.
> 
> Uwe
> 

Cheers and thanks again,
Oliver

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq

2020-04-12 Thread Oliver Freyermuth
Am 12.04.20 um 19:25 schrieb Simon Kelley:
> I'd split your /56 into as many /64s as you need, and set up routing as
> required (either static or using some routing daemon). Run dnsmasq
> centrally, and use DHCpv6 relays to proxy DHCPv6 requests from the
> router on each /64 network back to the central dnsmasq instance.

Thanks!
I presume the DHCPv6 relay on the gateway nodes (Linux servers in my case) 
could also be dnsmasqs with "zero configuration" apart from the dhcp-relay 
option, and enable-ra to force the local subnet
to use DHCPv6, right? 

Cheers,
Oliver

> 
> Simon.
> 
> 
> On 12/04/2020 18:20, Oliver Freyermuth wrote:
>> Am 12.04.20 um 19:01 schrieb Simon Kelley:
>>> The first question is, how static are your global addresses? Making a
>>> network which can survive renumbering is a lot more difficult than one
>>> with known and fixed addresses.
>>
>> Luckily, they are completely static :-). 
>>
>> Cheers,
>>  Oliver
>>
>>>
>>>
>>> Simon.
>>>
>>>
>>>
>>> On 12/04/2020 17:20, Oliver Freyermuth wrote:
 Dear DNSmasqers,

 I have a setup in mind and wonder whether dnsmasq is the correct tool 
 (since I have not found the necessary functionality in the documentation 
 yet). 

 We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless 
 autoconfiguration) in several /64 networks. 
 There are several subnets (currently NATed IPv4), such as — for example — 
 a WireGuard VPN network, or a local isolated subnet. 
 While with IPv4, the answer was the use of private addresses and NAT every 
 time, potentially using a DHCP fowarder, for IPv6, the answer should be to 
 use Global Unicast addresses everywhere (right?). 
 How do I approach this correctly? 

 Three options come to mind to handle such subnets:
 - Use ULAs and NAT (but that does not feel like IPv6...). 
 - Delegate a prefix from the large network (where we'd use dnsmasq) to the 
 "gateway" machine, which then would be a router. 
   However, I am not aware if dnsmasq can delegate prefixes? 
 - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure 
 if that scales well to a larger number of machines? 
 - Use static routes on the central machine which send the /64 subnet to 
 the "gateways" and use dnsmasq on the gateways. 
   Am I missing something here, or should that "just work"?

 Is anybody aware of a best-practice guide here (please RTFM me)? Is 
 dnsmasq the correct tool? 

 Cheers and thanks for any guidance,
Oliver

 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

>>>
>>> ___
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss@lists.thekelleys.org.uk
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>
>>

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq

2020-04-12 Thread Oliver Freyermuth
Hi,

thanks for the elaborate reply! 

Am 12.04.20 um 19:33 schrieb Uwe Schindler:
> Hi
>  
>> I have a setup in mind and wonder whether dnsmasq is the correct tool (since 
>> I
>> have not found the necessary functionality in the documentation yet).
>>
>> We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless
>> autoconfiguration) in several /64 networks.
> 
> That's perfect. Looks much like a standard German DSL account. 

In our case, even better, since the prefix is completely fixed and will never 
change ;-). 

> 
>> There are several subnets (currently NATed IPv4), such as — for example — a
>> WireGuard VPN network, or a local isolated subnet.
>> While with IPv4, the answer was the use of private addresses and NAT every
>> time, potentially using a DHCP fowarder, for IPv6, the answer should be to 
>> use
>> Global Unicast addresses everywhere (right?).
>> How do I approach this correctly?
> 
> That's very easy because you have a /56 net.
> 
>> Three options come to mind to handle such subnets:
>> - Use ULAs and NAT (but that does not feel like IPv6...).
> 
> No no no, bad idea and very stupid for such a large network.

That's what I thought :-). 

> 
>> - Delegate a prefix from the large network (where we'd use dnsmasq) to the
>> "gateway" machine, which then would be a router.
>>   However, I am not aware if dnsmasq can delegate prefixes?
> 
> This should all be done on the central router. For each subnet you have a 
> separate dnsmasq.

Since we already have gateway nodes for IPv4, we'd rather scale the dnsmasqs 
out, but that does not seem to interfere with the proposed solution. 

> 
>> - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure if
>> that scales well to a larger number of machines?
> 
> No need to do that (see below). ProxyNDP is only needed if you want delegate 
> some global addresses to devices that are in the same subnet but behind 
> another machine (MAC address). You don't need this. All can be done with 
> plain simple routing.

I see :-). 

> 
>> - Use static routes on the central machine which send the /64 subnet to the
>> "gateways" and use dnsmasq on the gateways.
> 
> That's the way to go and it will just work! Explanation:
> 
> The provider delegates a /56 prefix to you. How this is done depends, but for 
> DSL (dynamic) or also at Hetzner (static) the whole thing works on the link 
> level addresses. For DSL you have the PPP-Daemon wo gets a link local address 
> on the end point assigned. For DSL you get a prefix delegated using DHCP-PD 
> (prefix delegation), for static roulds (e.g., Hetzner) you get all traffic 
> routed to the link-local address of your router (that's coming from the mac 
> address of router known to provider).
> 
> On the router you just assign the subnets and their primary address (:1) 
> to a separate interface or VLAN in portions of /64. The linux kernel will 
> then just automatically route all incoming packets from the WAN interface 
> (PPP or Ethernet) to the correct (virtual) network adaptor. On each of those 
> network adaptors you have a dnsmasq listening.

There's a slightly more special case for us: We have one central firewall 
(which gets the full /56 net on the upstream interface routed to it) and most 
gateways are separate nodes
(i.e. most VLANs are not connected to the central FW). 
So I believe in that case I just need an ip6tables rule (per /64 subnet) on the 
central firewall to redirect all traffic to the gateway for the /64 subnet, 
right? 

> Just some recommendation: I'd NOT go with DHCPv6, as no Chromebook or Android 
> device supports it. I'd go for SLAAC. Very easy. As you can setup a separate 
> /64 subnet (up to 256 of them), you have enough flexibility to handle all of 
> them in a separate network with full /64 SLAAC address space. Each of those 
> networks have firewalling on the router box and are delegate to the network 
> switch .e.g, via VLANs.

I know (while I knew about Android, good point about the Chromebooks!). Our 
main usecase is addressing of Linux servers (i.e. there will only be "DHCP 
reserved" entries). 
Indeed, for a general purpose network (one of those /64s), we need to think 
whether we'll go with DHCPv6 (and lose Android and Chromebooks) or really stay 
with DHCPv6. For now, I'll plan with DHCPv6 ;-). 

Cheers and thanks,
Oliver

> If you are interested how to setup the Prefix Delegation with PPP, just ask. 
> The usual howtos seen on internet with wide-dhcpd are outdated and not very 
> modern and relying on a broken tool which should not be used anymore. The 
> correct way for that is "dhcpcd" client daemon listening on the PPP interface 
> and waiting for DHCP-PD packets. The dhcpcd config file can then 
> automatically split the delegated /56 network and assign it to various 
> real/virtual interfaces each with a /64 subnet, where a separate dnsmasq is 
> handling everything. No hacks needed, just plain routing on the bx (its 
> enough to 

Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq

2020-04-12 Thread Oliver Freyermuth
Am 12.04.20 um 19:01 schrieb Simon Kelley:
> The first question is, how static are your global addresses? Making a
> network which can survive renumbering is a lot more difficult than one
> with known and fixed addresses.

Luckily, they are completely static :-). 

Cheers,
Oliver

> 
> 
> Simon.
> 
> 
> 
> On 12/04/2020 17:20, Oliver Freyermuth wrote:
>> Dear DNSmasqers,
>>
>> I have a setup in mind and wonder whether dnsmasq is the correct tool (since 
>> I have not found the necessary functionality in the documentation yet). 
>>
>> We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless 
>> autoconfiguration) in several /64 networks. 
>> There are several subnets (currently NATed IPv4), such as — for example — a 
>> WireGuard VPN network, or a local isolated subnet. 
>> While with IPv4, the answer was the use of private addresses and NAT every 
>> time, potentially using a DHCP fowarder, for IPv6, the answer should be to 
>> use Global Unicast addresses everywhere (right?). 
>> How do I approach this correctly? 
>>
>> Three options come to mind to handle such subnets:
>> - Use ULAs and NAT (but that does not feel like IPv6...). 
>> - Delegate a prefix from the large network (where we'd use dnsmasq) to the 
>> "gateway" machine, which then would be a router. 
>>   However, I am not aware if dnsmasq can delegate prefixes? 
>> - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure 
>> if that scales well to a larger number of machines? 
>> - Use static routes on the central machine which send the /64 subnet to the 
>> "gateways" and use dnsmasq on the gateways. 
>>   Am I missing something here, or should that "just work"?
>>
>> Is anybody aware of a best-practice guide here (please RTFM me)? Is dnsmasq 
>> the correct tool? 
>>
>> Cheers and thanks for any guidance,
>>  Oliver
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq

2020-04-12 Thread Simon Kelley
I'd split your /56 into as many /64s as you need, and set up routing as
required (either static or using some routing daemon). Run dnsmasq
centrally, and use DHCpv6 relays to proxy DHCPv6 requests from the
router on each /64 network back to the central dnsmasq instance.

Simon.


On 12/04/2020 18:20, Oliver Freyermuth wrote:
> Am 12.04.20 um 19:01 schrieb Simon Kelley:
>> The first question is, how static are your global addresses? Making a
>> network which can survive renumbering is a lot more difficult than one
>> with known and fixed addresses.
> 
> Luckily, they are completely static :-). 
> 
> Cheers,
>   Oliver
> 
>>
>>
>> Simon.
>>
>>
>>
>> On 12/04/2020 17:20, Oliver Freyermuth wrote:
>>> Dear DNSmasqers,
>>>
>>> I have a setup in mind and wonder whether dnsmasq is the correct tool 
>>> (since I have not found the necessary functionality in the documentation 
>>> yet). 
>>>
>>> We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless 
>>> autoconfiguration) in several /64 networks. 
>>> There are several subnets (currently NATed IPv4), such as — for example — a 
>>> WireGuard VPN network, or a local isolated subnet. 
>>> While with IPv4, the answer was the use of private addresses and NAT every 
>>> time, potentially using a DHCP fowarder, for IPv6, the answer should be to 
>>> use Global Unicast addresses everywhere (right?). 
>>> How do I approach this correctly? 
>>>
>>> Three options come to mind to handle such subnets:
>>> - Use ULAs and NAT (but that does not feel like IPv6...). 
>>> - Delegate a prefix from the large network (where we'd use dnsmasq) to the 
>>> "gateway" machine, which then would be a router. 
>>>   However, I am not aware if dnsmasq can delegate prefixes? 
>>> - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure 
>>> if that scales well to a larger number of machines? 
>>> - Use static routes on the central machine which send the /64 subnet to the 
>>> "gateways" and use dnsmasq on the gateways. 
>>>   Am I missing something here, or should that "just work"?
>>>
>>> Is anybody aware of a best-practice guide here (please RTFM me)? Is dnsmasq 
>>> the correct tool? 
>>>
>>> Cheers and thanks for any guidance,
>>> Oliver
>>>
>>> ___
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss@lists.thekelleys.org.uk
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
> 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq

2020-04-12 Thread Uwe Schindler
Hi
 
> I have a setup in mind and wonder whether dnsmasq is the correct tool (since I
> have not found the necessary functionality in the documentation yet).
> 
> We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless
> autoconfiguration) in several /64 networks.

That's perfect. Looks much like a standard German DSL account. 

> There are several subnets (currently NATed IPv4), such as — for example — a
> WireGuard VPN network, or a local isolated subnet.
> While with IPv4, the answer was the use of private addresses and NAT every
> time, potentially using a DHCP fowarder, for IPv6, the answer should be to use
> Global Unicast addresses everywhere (right?).
> How do I approach this correctly?

That's very easy because you have a /56 net.

> Three options come to mind to handle such subnets:
> - Use ULAs and NAT (but that does not feel like IPv6...).

No no no, bad idea and very stupid for such a large network.

> - Delegate a prefix from the large network (where we'd use dnsmasq) to the
> "gateway" machine, which then would be a router.
>   However, I am not aware if dnsmasq can delegate prefixes?

This should all be done on the central router. For each subnet you have a 
separate dnsmasq.

> - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure if
> that scales well to a larger number of machines?

No need to do that (see below). ProxyNDP is only needed if you want delegate 
some global addresses to devices that are in the same subnet but behind another 
machine (MAC address). You don't need this. All can be done with plain simple 
routing.

> - Use static routes on the central machine which send the /64 subnet to the
> "gateways" and use dnsmasq on the gateways.

That's the way to go and it will just work! Explanation:

The provider delegates a /56 prefix to you. How this is done depends, but for 
DSL (dynamic) or also at Hetzner (static) the whole thing works on the link 
level addresses. For DSL you have the PPP-Daemon wo gets a link local address 
on the end point assigned. For DSL you get a prefix delegated using DHCP-PD 
(prefix delegation), for static roulds (e.g., Hetzner) you get all traffic 
routed to the link-local address of your router (that's coming from the mac 
address of router known to provider).

On the router you just assign the subnets and their primary address (:1) to 
a separate interface or VLAN in portions of /64. The linux kernel will then 
just automatically route all incoming packets from the WAN interface (PPP or 
Ethernet) to the correct (virtual) network adaptor. On each of those network 
adaptors you have a dnsmasq listening.

Just some recommendation: I'd NOT go with DHCPv6, as no Chromebook or Android 
device supports it. I'd go for SLAAC. Very easy. As you can setup a separate 
/64 subnet (up to 256 of them), you have enough flexibility to handle all of 
them in a separate network with full /64 SLAAC address space. Each of those 
networks have firewalling on the router box and are delegate to the network 
switch .e.g, via VLANs.

If you are interested how to setup the Prefix Delegation with PPP, just ask. 
The usual howtos seen on internet with wide-dhcpd are outdated and not very 
modern and relying on a broken tool which should not be used anymore. The 
correct way for that is "dhcpcd" client daemon listening on the PPP interface 
and waiting for DHCP-PD packets. The dhcpcd config file can then automatically 
split the delegated /56 network and assign it to various real/virtual 
interfaces each with a /64 subnet, where a separate dnsmasq is handling 
everything. No hacks needed, just plain routing on the bx (its enough to enable 
ip forwarding unless you want to firewall). All on a single box. I have set 
this up multiple times.

Uwe


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Prefix delegation with DNSmasq

2020-04-12 Thread Simon Kelley
The first question is, how static are your global addresses? Making a
network which can survive renumbering is a lot more difficult than one
with known and fixed addresses.


Simon.



On 12/04/2020 17:20, Oliver Freyermuth wrote:
> Dear DNSmasqers,
> 
> I have a setup in mind and wonder whether dnsmasq is the correct tool (since 
> I have not found the necessary functionality in the documentation yet). 
> 
> We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless 
> autoconfiguration) in several /64 networks. 
> There are several subnets (currently NATed IPv4), such as — for example — a 
> WireGuard VPN network, or a local isolated subnet. 
> While with IPv4, the answer was the use of private addresses and NAT every 
> time, potentially using a DHCP fowarder, for IPv6, the answer should be to 
> use Global Unicast addresses everywhere (right?). 
> How do I approach this correctly? 
> 
> Three options come to mind to handle such subnets:
> - Use ULAs and NAT (but that does not feel like IPv6...). 
> - Delegate a prefix from the large network (where we'd use dnsmasq) to the 
> "gateway" machine, which then would be a router. 
>   However, I am not aware if dnsmasq can delegate prefixes? 
> - Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure if 
> that scales well to a larger number of machines? 
> - Use static routes on the central machine which send the /64 subnet to the 
> "gateways" and use dnsmasq on the gateways. 
>   Am I missing something here, or should that "just work"?
> 
> Is anybody aware of a best-practice guide here (please RTFM me)? Is dnsmasq 
> the correct tool? 
> 
> Cheers and thanks for any guidance,
>   Oliver
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] Prefix delegation with DNSmasq

2020-04-12 Thread Oliver Freyermuth
Dear DNSmasqers,

I have a setup in mind and wonder whether dnsmasq is the correct tool (since I 
have not found the necessary functionality in the documentation yet). 

We have a /56 IPv6 network, and plan to use pure DHCPv6 (no stateless 
autoconfiguration) in several /64 networks. 
There are several subnets (currently NATed IPv4), such as — for example — a 
WireGuard VPN network, or a local isolated subnet. 
While with IPv4, the answer was the use of private addresses and NAT every 
time, potentially using a DHCP fowarder, for IPv6, the answer should be to use 
Global Unicast addresses everywhere (right?). 
How do I approach this correctly? 

Three options come to mind to handle such subnets:
- Use ULAs and NAT (but that does not feel like IPv6...). 
- Delegate a prefix from the large network (where we'd use dnsmasq) to the 
"gateway" machine, which then would be a router. 
  However, I am not aware if dnsmasq can delegate prefixes? 
- Use ProxyNDP (via npdpd or Linux kernel functionality). But I'm not sure if 
that scales well to a larger number of machines? 
- Use static routes on the central machine which send the /64 subnet to the 
"gateways" and use dnsmasq on the gateways. 
  Am I missing something here, or should that "just work"?

Is anybody aware of a best-practice guide here (please RTFM me)? Is dnsmasq the 
correct tool? 

Cheers and thanks for any guidance,
Oliver

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Announce: dnsmasq-2.81

2020-04-12 Thread Geert Stappers
On Sat, Apr 11, 2020 at 11:28:25PM +0100, Simon Kelley wrote:
> After 18 long months, tonight I released dnsmasq 2.81.
> 
> The next release should happen to a shorter timescale.
> 
> http://thekelleys.org.uk/dnsmasq/dnsmasq-2.81.tar.gz
> 
> 
> Enjoy.
> Simon.
> 

Thanks



Is the release date hinting https://eeggs.com/tree/153.html ?




Regards
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