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:XXXX 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:xxxx 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
