Score:0

ipv6 : same /64 prefix across multiple physical subnets / interfaces - in Linux

fj flag

I'm trying to figure out how to configure a single ipv6 /64 prefix that need to be routed across several different physical subnets interfaces. The problem illustration is like this:

                                      / Wi-Fi subnet 1
Internet - ISP -+ Router host (Linux) - LAN subnet 1
                                      \ Wi-Fi subnet 2

The illustration here is for 3 subnets, but that in practical terms there can be more subnets (for that matter a Wi-Fi subnet can consist of a Linux host that bridges Wi-Fi into LAN and a single port connects to 1 port on the main router) and the router host is multi-homed, with multi independent port.

The trouble is all the subnets need to share the same /64 prefix that is routed from the ISP.

While one way is to simply bridge all the subnets (layer 2), I'd prefer to do all the routing at layer 3 (i.e. ipv6), but with one single routable /64 prefix from the ISP across all subnets.

While searching / researching solutions, I stumbled into:

  • NDPPD github.com/DanielAdolfsson/ndppd

^ I'm actually trying this out but have not reached much success. a problem is how to define the ip routes such that all the different subnets use the same /64 prefix on different network interfaces (at the main router)

^ not yet tried

BIRD router supports it as well

^ this is one of the most promising solutions, but that I stumbled into the notion of

  1. how to configure routing / topology for multiple 'same prefix' ipv6 networks
  2. how to dynamically register the hosts with the Babel router as the same 64 bit interface ID can practically just roam and connect to any of the subnets. The trouble is I cannot make subnets smaller /64 as SLAAC (https://datatracker.ietf.org/doc/html/rfc4862) would automatically patch a 64 bit interface ID. All Android phones does that and I'd think most Iphones and other workstations (e.g. a laptop running Linux/Windows) mostly does SLAAC by default.
  • RFC 7421 Analysis of the 64-bit Boundary in IPv6 Addressing

^ one of the best RFC documents addressing this I stumbled into

Among the solutions NAT64 - Both stateless NAT64 [RFC6052] and stateful NAT64 [RFC6146] this is almost like the 'old' NAT practically used on 'all' the 'home' routers with a single ipv4 address.

I seemed to be left with NAT64 and NPTv6 for now to attempt to map that into a routable setup.

Kindly let me know your thoughts on the same, e.g. if there are other solutions as well.

vidarlo avatar
ar flag
Ask your ISP for a /56 or /48. Tell them that they're implementing IPv6 wrong by not allowing you to subnet. If that fails, set up a tunnel using a tunnelbroker.
A.B avatar
cl flag
A.B
If the ISP won't: ndppd doesn't appear to be able to do 1 to many NDP forwarding (even if it accepts it in the config, and binds to all interfaces, only the last defined appears to be used). You'd better use a bridge and nftables which has conntrack support in bridge path (for stateful firewalling) since kernel 5.3. You can still choose to bridge all the right side and use routing+ndppd between left and right.
user4433437 avatar
fj flag
@A.B at the moment I'm experimenting with ndppd, it has a feature which would patch static routes https://github.com/google/ndprbrd I'd guess in this present day this would be deemed 'experimental'
user4433437 avatar
fj flag
btw for linux there are a few rather cool NAT64 implementations https://ripe85.ripe.net/wp-content/uploads/presentations/78-ripe85-open-source-nat64.pdf among which Jool looks quite good https://nicmx.github.io/Jool/en/index.html and integrates into the Linux netfilter infrastructure
A.B avatar
cl flag
A.B
My test was with an packaged ("old") ndppd version, so from your link my test probably doesn't apply anymore.
Score:2
cn flag

Tell your ISP you need more /64s routed to you. At least a /56 is the convention for all sites with a router, including residential. More might be justified depending on your address plan.

If your ISP doesn't appreciate the use case for multiple /64s on business class service, get a better ISP.

Should there not be a better ISP available, consider bringing in sufficient address space from some other provider. Such as a 6in4 tunnel or a VPN. Perhaps some risk of performance hit for going through another hop and an overlay. But your address plan and IP routing will be easy.

You cited one of the better analysis of what deviating from /64 means to the standards, RFC 7421. "A subnet prefix longer than 64 bits is outside the current IPv6 specifications, so results may vary." For example, in practice, SLAAC might be the only reasonable address mechanism for certain hosts, but the implementation might not work if you try it with /80s.

Being absolutist on subnets/interface IDs are 64 bits may seem silly. However, I think it is bizarre to expect any network to make do with one subnet. The address space is so vast that every person on the planet could be issued several thousand /48s. Then IANA might need to start opening up the next eighth.

user4433437 avatar
fj flag
thanks, I think this is a 'common' scenario as many 'home' subscribers are given only a single /64 ipv6 prefix. for 'business' plans, the isp is possibly more flexible but that it may cost significantly more. I'm thinking that NAT64 is likely a 'simplest' while an attempt to map it with babeld could be 'revolutionary', i.e. bridging at the ipv6 level instead of at ethernet level. I've not figured how to do that with babeld though, the idea is to use babeld as like STP (spanning tree protocol) used in ethernet bridging
John Mahowald avatar
cn flag
My home connection is a /56, and a while ago I was routing maybe a /60 to a home lab with babel. Homenet group at the IETF considers only one /64 an error condition. RIRs will generally approve ISP address plans of a /56 or /48 per subscriber without question, and possibly without extra cost. I think advocating and possibly paying a premium for an easy to use address space is more productive than smaller subnets with unknown levels of technical maturity. For example, if using NPT, does the implementation you select even allow mapping smaller than a /64 ?
user4433437 avatar
fj flag
Thanks, at the moment it is rather unlikely in my circumstances as the local providers mostly provided only a /64, I may try, but an appeal is not likely to succeed. I'd think a feasible way that can map this is NAT64, I'd not call that 'mature', but that at least there are implementations out there. With NAT64, just like the NAT, which may even make do with a single IP address. But that the router host does a lot of work tracking all that connections. With NAT64, the subnets behind that NAT can be configured as desired, no limits.
user4433437 avatar
fj flag
I'm still trying ndppd which is 'not mature', experimental. A good thing here is that if that works it works without an NAT64. Hence, no additional tracking is needed at the main router, the ipv6 addresses are literally directly routable on the open internet. I'm thinking about 'homenet' using babeld, but I've not reviewed it in detail yet, e.g. how do I register the hosts with babeld or that it'd find them on its own and literally patch direct routes dynamically? This is the most preferred solution.
user4433437 avatar
fj flag
I'm starting to weigh NAT64 a little more, as it 'does away' with the /64 prefix restriction, it is practically a firewall on its own, the subnets behind it can practically take any shape, it keeps ipv6 addresses practically anonymous, the same station mapped by NAT64 can be remapped. The thing is NAT64 is 'not scalable', but works for a 'small' site, e.g. 'home' or 'small office'
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.