IPv6 and its prefference in settings GUI and other GUI suggestions

@Jirka

  • same ISP
  • Turris v1.0
  • same problems :frowning:
  • not working IPv6 since 3 days
  • I received /62 but I donā€™t know how to configure it in Turris
    (we assigned to you non public IPv4 xx.xx.xx.xx/30 and based on this you get 2a00:ca8:xx:xx:xx::/62)

If you get some news or get it working - please share

Well am not sure the problem is on ISP sideā€¦

I tried to do factory reset of my Turris:

  1. rebooted and completed wizzard
  2. uploaded config backup
  3. IPv6 working on client side! :slight_smile:
  4. on Turris admin page I see message - kernel updated - your router has to be rebooted
  5. ok rebooted
  6. after reboot - IPv6 on client not working anymore ā€¦

I will try to reproduce the problem

What version of turris os you updated? I flashed 3.5.3 just after unboxing, and dont see any updates (at least yesterday, checked through opkg update, upkg list-upgradable)

What config did you use? I think only differences between us is static IPv4 assigned to me. Also Ive got only information about IPv6 prefix, nothing about ā€œbased on this you getā€).

OK i tried another router with brand new LEDE install - same behaviour as with turris.

Current status:
directly on router IPv6 works as expected
client get IPv6 address but unable to reach any IP

root@LEDE:~# ip addr sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP qlen 1000
link/ether 00:1e:8c:d0:78:dd brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
link/ether 00:90:4c:a1:00:2d brd ff:ff:ff:ff:ff:ff
inet 89.xx.xx.xx/24 brd 89.xx.xx.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 2a00:ca8:8000:c:290:4cff:fea1:2d/64 scope global dynamic
valid_lft 86389sec preferred_lft 14389sec
inet6 2a00:ca8:8000:c::100/128 scope global dynamic
valid_lft 15616sec preferred_lft 14016sec
inet6 fe80::290:4cff:fea1:2d/64 scope link
valid_lft forever preferred_lft forever
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:1e:8c:d0:78:dd brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 2a00:ca8:8000:e::1/64 scope global dynamic
valid_lft 15616sec preferred_lft 14016sec
inet6 fd27:ed5f:c56e::1/60 scope global
valid_lft forever preferred_lft forever
inet6 fe80::21e:8cff:fed0:78dd/64 scope link
valid_lft forever preferred_lft forever
6: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP qlen 1000
link/ether 00:1e:8c:d0:78:dd brd ff:ff:ff:ff:ff:ff
inet6 fe80::21e:8cff:fed0:78dd/64 scope link
valid_lft forever preferred_lft forever
root@LEDE:~#


root@LEDE:~# ip -6 route sh
default from 2a00:ca8:8000:c::100 via fe80::225:90ff:fea9:ec16 dev eth1 metric 384
default from 2a00:ca8:8000:c::/64 via fe80::225:90ff:fea9:ec16 dev eth1 metric 384
default from 2a00:ca8:8000:e::/64 via fe80::225:90ff:fea9:ec16 dev eth1 metric 384
2a00:ca8:8000:c::/64 dev eth1 metric 256
2a00:ca8:8000:e::/64 dev br-lan metric 1024
unreachable 2a00:ca8:8000:e::/64 dev lo metric 2147483647 error -148
fd27:ed5f:c56e::/64 dev br-lan metric 1024
unreachable fd27:ed5f:c56e::/48 dev lo metric 2147483647 error -148
fe80::/64 dev eth1 metric 256
fe80::/64 dev br-lan metric 256
fe80::/64 dev wlan0 metric 256
unreachable default dev lo metric -1 error -128
ff00::/8 dev br-lan metric 256
ff00::/8 dev eth1 metric 256
ff00::/8 dev wlan0 metric 256
unreachable default dev lo metric -1 error -128


Wireless LAN adapter Wi-Fi:

Connection-specific DNS Suffix . : lan
Description . . . . . . . . . . . : Dell Wireless 1820 802.11ac
Physical Address. . . . . . . . . : 90-CD-B6-1D-20-21
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2a00:ca8:8000:e:bd31:c783:df3a:b880(Preferred)
IPv6 Address. . . . . . . . . . . : fd27:ed5f:c56e:0:bd31:c783:df3a:b880(Preferred)
Temporary IPv6 Address. . . . . . : 2a00:ca8:8000:e:e890:2296:7742:fa8f(Preferred)
Temporary IPv6 Address. . . . . . : fd27:ed5f:c56e:0:e890:2296:7742:fa8f(Preferred)
Link-local IPv6 Address . . . . . : fe80::bd31:c783:df3a:b880%25(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.219(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Tuesday, March 7, 2017 11:10:10 AM
Lease Expires . . . . . . . . . . : Tuesday, March 7, 2017 11:10:10 PM
Default Gateway . . . . . . . . . : fe80::21e:8cff:fed0:78dd%25
192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DHCPv6 IAID . . . . . . . . . . . : 294702518
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1F-CF-34-59-F8-CA-B8-54-55-2B
DNS Servers . . . . . . . . . . . : 192.168.1.1
NetBIOS over Tcpip. . . . . . . . : Enabled


On client

ping www.root.cz -6

Pinging root.cz [2001:67c:68::76] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.

ping fe80::21e:8cff:fed0:78dd%25

Pinging fe80::21e:8cff:fed0:78dd%25 with 32 bytes of data:
Reply from fe80::21e:8cff:fed0:78dd%25: time=2ms
Reply from fe80::21e:8cff:fed0:78dd%25: time=5ms
Reply from fe80::21e:8cff:fed0:78dd%25: time=3ms
Reply from fe80::21e:8cff:fed0:78dd%25: time=2ms

Ping statistics for fe80::21e:8cff:fed0:78dd%25:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 5ms, Average = 3ms

So it seems that there is a routing issue in the network of your ISP. Either your default GW doesnā€™t have the route for root.cz or default, or your prefix is not in its routing table (more probable).

This usually happens when using dynamic allocation with ISC DHCP which doesnā€™t add routes it allocates into routing table. Please consult it with your ISP, they either had to use DHCPv6 relay agent which modifies the routing table or they had to set routes statically.

If I understand it right, with another router/LEDE you at least got correct 2a00 address.

And with the same settings (Can I assume just

config interface 'wan6'
    option ifname '@wan'
    option proto 'dhcpv6'

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

?) on Omnia, we didnt get IPv6 at all.

Is that correct?

I see possible problem - behavior is same on Turris v1 and LEDE@Asus VL500W.
Prefix I have assigned from ISP is 2a00:ca8:8000:c::/64 since 2 years (some problems were during that time but overall working).

I can see ip from this prefix on WAN6 and v6 connectivity is working OK when tested directly via ssh on router.

But on LAN interfaces I can see prefixes like 2a00:ca8:8000:e::/64 and 2a00:ca8:8000:f::/64 ?!
Strange - based on ISPā€™s policy as I know - this prefixes are from other customers.

Anybody can explain? Am I correct or is this expected?

How to set manualy v6 address to clients?

See my previous post. Those things you describe are consistent with hypothesis of broken routing.

Problem is that when DHCPv6 servers assigns you a prefix, it will not put that prefix into routing table in that AP.

Example:
Your WAN address: 2001:db8:123::100/64
Your prefix (by PD): 2001:db8:123:100::/56
APā€™s interface for that WAN range: eth0

So the AP does have a route:
2001:db8:123::/64 via eth0

So anything send from the WAN address would work just fine (there is route for that).

However there is no route for your prefix: 2001:db8:123:100::/56. So you will be able to send packets to the internet, but nothing would reach you. Result: broken connectivity for your network.

Changing your CPE would not help you in any way, it is broken on your ISP side. If you have changed your CPE you could even contribute to this problem, because if the route for your prefix has been set to your link-local address of WAN interface, it has changed and it sees to work. If it is the case inform your ISP about the change, they had to fix their routing table. There is nothing else you can do.

I can report my DHCPv6 problem was solved. One of ISPā€™s switch wasnt setuped to IPv6 traffic. Now router got correct IPv6 and I can continue to setup IPv6 on internal network.

And I have the same behauviour as ostravak. My WAN IPv6 is almost correct (it should be /62), lets say:

 inet6 addr: 2a00:ca8:a14:xxxx:....:....:....:..../64 Scope:Global
 inet6 addr: 2a00:ca8:a14:xxxx::100/128 Scope:Global

but br-lan and lan clients got wrong subnet

inet6 addr: fdfe:4a76:4994::1/60 Scope:Global
inet6 addr: 2a00:ca8:a14:**xxxx+3**::1/64 Scope:Global

maybe because this I have constantly spammed messages (like aevery few seconds) in log

2017-03-13 18:18:08 warning odhcpd[8063]: DHCPV6 SOLICIT IA_NA from XDUID on br-lan: ok 2a00:ca8:a14:xxxx+3::yyy/128 fdfe:4a76:4994::110/128
2017-03-13 18:18:08 warning odhcpd[8063]: DHCPV6 REQUEST IA_NA from XDUID on br-lan: ok 2a00:ca8:a14:xxxx+3::yyy/128 fdfe:4a76:4994::110/128

its quite frustratingā€¦ When I solved routers IPv6 problem, immediatelly hit to troubles in distributing correct IPv6 addresses to clients :frowning:

I dont have routing problems with IPv6 www from clients. But I would like to have all IPv6 adresses in ISP assigned prefix - I am not able to connect to router or clients from internetā€¦

You are wrong.

  1. If you have on WAN side /128 address which belongs into your /62 range. You have to allocate one of /64s to WAN interface, thatā€™s why there is /64 not /62. If you set it to /62, it would mean that all of your addresses are on WAN side - nothing would be left for LAN.

  2. It is OK to have prefix +3 in case of /62 on LAN. /62 means that you have 2b = 4 network ranges of /64 for you to use.

Example:
Your prefix: 2001:db8:1234:5678::/62
Can be split into: 2001:db8:1234:5678::/64, ā€¦:5679::/64, 567a::/64, 567b::/64

Some ISPs uses one addresses from customer pool for link between AP and CPE (your case) which renders the base /64 prefix unusable for customersā€™ LAN. In my opinion that is a poor network design, it is better to use either common prefix for CPEs or dedicated prefix outside of PD pool. One way or another this is the decision of your ISP.

When you cannot reach your clients from outside, it is due to stateful firewall somewhere in the path. It would be probably in your CPE, go to LuCi, firewall LAN zone and allow connection from outside (usually there is reject for incoming policy). Be advice to check every device for firewall (to allow outside access only to things that you really want to.

You seems to be czech so, may I suggest a literature?


Look for CIDR notation.

1 Like

Thank you sir for correction! I was learning new things all afternoon today, but according to your post I am on the good way after all. I will study some more.

Correct me if I am wrong: Because /62 I cant delegate subnets to different interfaces (LAN, VPNā€¦). Thats because I need to addres /64, and for that I need at least /60 prefix from ISP. Please tell me I am wrong :slight_smile: I desperatelly tried to make ip6hint works in my case but failed.

Actually you can, however you are limited to 3 usable subnets. The base one had to be reserved to AP/CPE link (/64, not /62), then 3 remaining /64s can be used as you see fit.

In theory you can help yourself by using only 2 of them and use the rest with prefixes longer then /64. This would make the SLAAC unusable (as it might brake other things too), but DHCPv6 as well as static would work. You would still need the RA for default route so you need to set its flags to: M=1, O=1, A=0.

Of course it would be better to convince the ISP to give you larger block. Then they should have /32 (RIPE NCC gives up to /29, when justified even larger), in such case they should have enough addresses to give an end user up to /56. However, it looks like there is something nasty going on in their records in RIPE database. It seems that they have made only 2 assignment (/48s type ASSIGNED - none of which is in the range you have provided). They should have made inet6num object type AGGREGATED-BY-LIR with assignment size /62, you should point that out while asking for more addresses. This way it seems that you are using unregistered space (ALLOCATED-BY-RIR /32 doesnā€™t count).

Actually, the three subnets is fine by me. And I am using dhcpv6 (afaik). One is for LAN, one for OpenVPN, and maybe in future third will be for Wifi. I dont need that much adresses by far, but at least OpenVPN should have different subnet, according documentation I read.

I havent much word to ISP work though., could you advise to me, how I could assign those 3 existing subnets in openwrt? I am reading pdf/openwrt wikis all afternoon, but still cant crack this :frowning: It seems to me, I should use only ip6assign and ip6hint within interface definitionsā€¦

My goal is simply transfer all services to IPv6 (that counts with VPN incoming connections), for the times when IPv4 (public) will be no more for me.

As I remember it should be visible LuCi as a hint in the interface tab. In your case the hint should be 1 to 3. Iā€™m not currently able to confirm that because Iā€™m on leave now and Iā€™m too paranoid to allow remote access to my box even to myself :slight_smile: .

I tried it, but it doesnt work :frowning: I tried ask ISP for /60 via email.

Wondering, if I could somehow propagate IPv6 from WAN to LAN/Wifi/VPN not via ip6assign, but some RA method or such. But my tests so far with Openwrt configuration in that sense was quite catastrophic so far :confused: