How to route each device a /64 subnet?

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi,

I have a routed /64 and /56 and a single ipv4 address. I'm trying to split the /56 to 256 /64 subnets and assign them to end devices, with ipv4 NAT. So each device will be in the same ipv4 subnet and different ipv6 subnet
For example,
The ipv4 subnet is 10.123.123.0/24
The ipv6 subnet is 2a00:a:b:ab00::/56

Device 10.123.123.1 will get 2a00:a:b:ab01::/64
Device 10.123.123.2 will get 2a00:a:b:ab02::/64
...
Device 10.123.123.10 will get 2a00:a:b:ab0a::/64
...

Is it possible to achieve something like this in openwrt? Thank you very much

2

This doesn't make much sense. Your router gets a delegated prefix /56. That means that you can have 256 interfaces on the router, each with its own /64, or you can have one /64 on the lan and the other 255 /64 prefixes can be delegated to lan hosts who request them by DHCP. Alternatively you can do it with static settings.

2 Likes
3

this.
You can setup up to 256 vlans and each can have a /64. Or you reserving some and do the routing static or dynamically in your lan.
As far as I know IPv6 ransport over IPv4 is not possible but Linux is able to route IPv4 over an IPv6 underlay.

1 Like
4

You can always create a tunnel over one protocol and transport the other.

5

No, No Tunnel. just add a route for IPv4 with an IPv6 next hop. Iproute2 and bgp do that... Bgp needs mp-bgp iirc...

6

That doesn't sound right. I have never seen mixing the protocols of the prefix and the next hop. The IP header doesn't support such a thing. There is some transition mechanism under the hood, like SIIT, NAT64, DNS64, etc.
Regarding MP-BGP now, it is enabling to use other protocols (like multicast and IPv6) in comparison to unicast IPv4 that was the only protocol supported in BGP. But again this is for the prefix advertisement between the ASes and is not connected to routing decisions like in the scenario here.

7

https://www.rfc-editor.org/rfc/rfc5549

8

You're mixing many things. The example is for the prefix announcement in BGP, not for the routing. For the latter you'd still need a Address Family Translation Border Router, which translates the packet headers from one protocol to another.
And this is really not applicable here.

1 Like
9

Thank you for your replies trendy and _bernd. I think I got it. I will try to setup multiple interfaces or vlans and assign each to a device.

Just out of curiosity. What would be the difference between delegation and a "routed" prefix? According to my upstream I got a routed /56. Does that mean I got a delegated /56?

10

Yes. Your ISP is routing a /56 to you to split up as you like. As @trendy says this is usually divided into /64 subnets which are allocated to individual networks on the router. This allows the router to allocate addresses to hosts connected within those networks. Alternatively, you can delegate some of those /64 subnets to downstream routers for them to use on their own connected LANs. What shouldn't happen, however, is that individual host devices (i.e. desktops, laptops, phones etc) get allocated a /64.

3 Likes
11

In generell, No you are totally fine to route IPv4 over an IPv6 only backbone network. Been there, done that.
Like I said, and please consolte the iproute2 man page . Ipv4 routes can be set with an IPv6 nexthop. With bird and frr you just need to enable MP bgp and it just works and makes no difference. Yes the edge or border routers needs to have v4 reachability but the transport or routing of v4 happens over V6 only routers.

12

Post an example here please.

13

As posted before: https://www.rfc-editor.org/rfc/rfc8950

14

If you cannot provide a simple example and you ask me to read a whole RFP, I'll stick to my opinion that it doesn't work. :slight_smile:

16

ok...

We have two devices, and a router....

root@cpe:~# ip route get 192.0.2.17
192.0.2.17 via inet6 fe80::6cec:83db:265b:a6f2 dev br-vlan64 src 192.168.64.1 uid 0
    cache
root@cpe:~# ip route get 192.0.2.23
192.0.2.23 via inet6 fe80::ae1f:6bff:fed1:225c dev br-vlan24 src 192.168.24.1 uid 0
    cache

As you see, two interfaces on the router. Routes got added with:

root@cpe:~# ip -4 route add 192.0.2.23/32 via inet6 fe80::ae1f:6bff:fed1:225c dev br-vlan24
root@cpe:~# ip -4 route add 192.0.2.17/32 via inet6 fe80::6cec:83db:265b:a6f2 dev br-vlan64

Link local on the router:

root@cpe:~# ip -6 -br addr show scope link | grep -Ee 'vlan(24|64)'
br-vlan24        UP             fe80::1ff:fe01:18/64
br-vlan64        UP             fe80::1ff:fe01:40/64

Both test-devices:

root@margot:~# ip link add test type dummy
root@margot:~# ip link set test up
root@margot:~# ip addr add 192.0.2.23/32 dev test
root@margot:~# ip -br a
...
eno1             UP             ... fe80::ae1f:6bff:fed1:225c/64
test             UNKNOWN        192.0.2.23/32 fe80::2cfc:17ff:fe2f:7f94/64

root@margot:~# ip route add 192.0.2.17/32 via inet6 fe80::1ff:fe01:18 dev eno1

root@hiten ~ # ip link add test type dummy
root@hiten ~ # ip addr 192.0.2.17/32 dev test
root@hiten ~ # ip link set test up
root@hiten ~ # ip -4 route add 192.0.2.23 via inet6 fe80::1ff:fe01:40
root@hiten ~ # ip -br a
...
eno1             UP             ... fe80::6cec:83db:265b:a6f2/64
...
test             UNKNOWN        192.0.2.17/32 fe80::1475:fbff:fe5f:9a42/64

root@hiten ~ # ping -I 192.0.2.17 -c 3 192.0.2.23
PING 192.0.2.23 (192.0.2.23) from 192.0.2.17 : 56(84) bytes of data.
64 bytes from 192.0.2.23: icmp_seq=1 ttl=63 time=0.478 ms
64 bytes from 192.0.2.23: icmp_seq=2 ttl=63 time=0.472 ms
64 bytes from 192.0.2.23: icmp_seq=3 ttl=63 time=0.438 ms

--- 192.0.2.23 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2015ms
rtt min/avg/max/mdev = 0.438/0.462/0.478/0.017 ms


root@margot:~# tcpdump -i any -enN icmp or icmp6
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes


20:57:33.904096 eno1  In  ifindex 2 02:00:01:01:00:18 ethertype IPv4 (0x0800), length 104: 192.0.2.17 > 192.0.2.23: ICMP echo request, id 5, seq 1, length 64
20:57:33.904118 eno1  Out ifindex 2 ac:1f:6b:d1:22:5c ethertype IPv4 (0x0800), length 104: 192.0.2.23 > 192.0.2.17: ICMP echo reply, id 5, seq 1, length 64
20:57:34.906189 eno1  In  ifindex 2 02:00:01:01:00:18 ethertype IPv4 (0x0800), length 104: 192.0.2.17 > 192.0.2.23: ICMP echo request, id 5, seq 2, length 64
20:57:34.906211 eno1  Out ifindex 2 ac:1f:6b:d1:22:5c ethertype IPv4 (0x0800), length 104: 192.0.2.23 > 192.0.2.17: ICMP echo reply, id 5, seq 2, length 64
20:57:35.919519 eno1  In  ifindex 2 02:00:01:01:00:18 ethertype IPv4 (0x0800), length 104: 192.0.2.17 > 192.0.2.23: ICMP echo request, id 5, seq 3, length 64
20:57:35.919541 eno1  Out ifindex 2 ac:1f:6b:d1:22:5c ethertype IPv4 (0x0800), length 104: 192.0.2.23 > 192.0.2.17: ICMP echo reply, id 5, seq 3, length 64
^C
6 packets captured
8 packets received by filter
0 packets dropped by kernel

And again, just read RFC 8950 and the earlier version RFC 5549.
It's already in the title!

Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop

1 Like
17

RFC 8273 (Unique IPv6 Prefix per Host) might also be useful.

And there is an old topic about the RFC in this forum: Unique IPv6 Prefix per Host RFC8273

1 Like
18

Just to be clear:

I am able to configure prefixes larger than /64 on interfaces - and in turn, capable devices can receive a Prefix Delegation from the OpenWrt.

19

Thank you for the example and the explanation, it makes sense now!

1 Like
20

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.