Obtaining ipv6 address for client on a tagged vlan with a /64 prefix

Hi there,

My network topology as below:
nevertopology.png
ISP optic modem (bridged)---WAN---openwrt router 21.02 snapshot ---LAN2 trunk vlan57 ---Linux box running docker containers

ISP only assigns a /64 prefix for me, there is PD available, so with the modem bridged my lan clients behind openwrt router can obtain v6 addresses.

I have some docker containers running on a small Linux box, my intention: Separate these containers from my LAN network with vlan and setup separate firewall zones for security reason, while obtaining ipv6 addresses for them so they can have global ipv6 addresses.

I have created trunk ports on LAN2 and the Linux box successfully, docker containers can work on macvlan57 created, everything is OK for ipv4. However I cannot get ipv6 working. My normal LAN clients on br-lan can obtain ipv6 addresses, and if I switch the docker container to use untagged network, it can also have ipv6 network (manually assigned v6 address, docker is not very smart on this).

summary.png
If I setup the LANWX (vlan57) interface with the same setting of my br-lan and reboot, then LANWX can get a /64 address but my br-lan loses ipv6 access. I completely understand this is because I only have /64 prefix and with that I can only have one subnet of ipv6.

So my question for you geniuses is: can I achieve my goal with merely a /64 prefix? I just want ipv6 access for containers while separating them from the main network

My knowledge on network is not much, maybe using NDP? Or subdividing a /64 subnet against the standard? I am aware this will break SLAAC ipv6 on android devices but that is trivial right now.

My network and dhcp config attached (sensitive filtered, no firewall rules ATM, I can figure that out later):

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan1'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.66.218'
	option ip6ifaceid 'eui64'
	option ip6assign '64'

config interface 'wan'
	option device 'wan'
	option proto 'pppoe'
	option username 'namehere'
	option password 'passhere'
	option ipv6 'auto'

config interface 'wan6'
	option device 'wan'
	option proto 'dhcpv6'
	option reqaddress 'try'
	option reqprefix 'auto'

config device
	option type '8021q'
	option ifname 'lan2'
	option vid '57'
	option name 'lan2.57'

config interface 'LANex'
	option proto 'static'
	option device 'lan2.57'
	option ipaddr '192.168.57.99'
	option netmask '255.255.255.0'
	list dns '1.2.3.4'

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option localservice '1'
	option dns_redirect '1'
	option ednspacket_max '1232'
	option authoritative '1'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option ra_management '1'
	option ra 'server'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'
	option dhcpv6 'server'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config dhcp 'LANex'
	option interface 'LANex'
	option start '100'
	option limit '150'
	option leasetime '12h'
	list ra_flags 'none'
	option ndp 'relay'
	option ndproxy_slave '1'

And pls don't ask me to change the ISP, because:

  1. My family members' phone numbers are also included in the internet plan, which would be a pain to change
  2. At least this ISP has a "rare" public v4 address assigned with /64 v6 PD, other ISP around even do not have public v4 address available, yeah, talking about the bottom-line these days :crazy_face:

Pressure your ISP to hand out a proper /56

A /64 means one network segment so no you can't really get a second network segment for your VLAN. this is a broken config that lots of ISPs who haven't got their shit together are doing.

Thx for the reply. But this is a "global" policy in my city for the ISP, to change it either I move to another city or switch ISP. And other ISP have no public ipv4 address, which is more terrible :expressionless:

Is it possible for me to further divide a /64 into two maybe /96 subnets? If so how to do it?

You don't want to be subnetting a /64, it can be done, but wouldn't be recommended. It will break things like SLAAC, possibly cause issues with other devices not expecting such a setup and you're ultimately hacking around an ISP problem. While I get the impression you have limited options, letting ISPs get away with such practices is equally bad, so you should use this as a prime example of why a single /64 isn't correct.

Your alternative option is getting your IPv6 transit from somewhere else who are willing to provide a proper prefix to you, how feasible that is for your situation, I don't know.

it's not possible while preserving compatibility with Android. I think also iPhone has troubles. I'm not sure about stuff like xbox. It will work fine as long as you're running only devices that can be configured to use DHCPv6. I think Windows and Linux should be fine.

Please note this is a BROKEN config. It's just not correct to hand out /64 however it's extremely common. we really need an international treaty on this.

Thank you for the opinions, so I will either add another lane or stick to this damn ISP
Happy new year anyway :grinning:

Happy New Year!

There's a few ways to get IPv6 through someone else without necessarily taking out a whole new internet line so to speak.

  • 6in4 through Hurricane Electric (not ideal because really we should be thinking about native IPv6 these days, not relying on transitional methods)
  • IPv6 through a VPS i.e. Linode, Digital Ocean etc using something like Wireguard.
  • Completely separate IPv6 transit from another provider but using something like L2TP or a tunnel to connect while still using your main WAN.

Of course, technically this is still working around an ISP problem, but if IPv6 is critical, they are options to consider. The advantage with the exception of 6in4 is you'll have native IPv6 and likely the ability to have a prefix much larger than /64, a /56 or possibly a /48 which would give you plenty of subnets for VLANs and such.

I myself do this, so I'm probably a bit of a bad example calling out ISPs but then equally working around their mess, but that's my choice because I wanted to learn IPv6 and without doing so wouldn't have had the ability to test it years ago, given some providers in the UK still don't have IPv6 yet.

Admittedly however, the solution is for ISPs to stop doing bad ISP things, but easier said than done, I know!

Understood. I have another line from different ISP in another place with no public v4 but a /60 v6 prefix, I thought about "borrowing" IPV6 from there using maybe Wireguard method, but the programs running on local docker expect IPs from the same ISP, so....

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