OpenWrt Forum Archive

Topic: Another IPV6 Issue - Chaos Calmer 15.05

The content of this topic has been archived on 28 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello everyone! I'm trying to setup native IPV6 on Chaos Calmer 15.05 (TP-LINK TL-WRN710). My ISP is VOO. The router itself manages to get an IPV6 connection and pings IPV6 addresses successfully, LAN clients can also speak to each other using IPV6, however they can't access external ipv6 sites. My ISP provides a /128 single IPV6 address and has a prefix delegation of /64.

See here:

IPV6 VOO

Keeping this in mind, i made a wan6 interface, set it to be a dhcpv6 client, set request ipv6 address to 'try' and set request ipv6-prefix of length to automatic (i also tried settting it to 64). As for the wan interface, i didn't make any changes (DHCP server is disabled on the wan interface though, should i enable it?). I have ticked 'Use builtin IPV6 managment' for all interfaces. As for the lan interface, i have the dhcp server enabled, however it is set to not be dynamic. IPV6 Router Advertisement-Service is set to enabled, and DHCPv6-Service is also set to enabled and DHCPv6-Mode is stateless + stateful. I also set IPv6 assignment length to 64, there is no IPV6 assignment hint set (i did try setting it though). I tried setting these settings both using the interface and ssh.

My VOO modem is not in bridge mode.

WAN and WAN6 show '2A02:2788:74:119B:16CC:20FF:FEFF:67AE/128' as IPV6 address (i assume this is the private IPV6 address), and LAN shows '2A02:2788:854:DDD::1/64' as the private IPV6 address.

I also tried disabling the IPV6 firewall with ip6tables -F.

Here is my /etc/config/network:

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

config globals 'globals'
        option ula_prefix '2A02:2788:854:DDD::/64'

config interface 'lan'
        option ifname 'eth1'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option gateway '192.168.0.1'
        option ip6assign '64' 
config interface 'wan'
        option ifname 'eth0'
        option _orig_ifname 'eth0'
        option _orig_bridge 'false'
        option proto 'static'
        option ipv6 '1'
        option ipaddr '192.168.0.2'
        option netmask '255.255.255.0'
        option gateway '192.168.0.1'

config interface 'wan6'
        option ifname 'eth0'
        option _orig_ifname 'eth0'
        option _orig_bridge 'false'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'

config route

I also tried setting iphint to 10, ipassign to 60, removing the global ULA prefix, etc.


Here is the result of 'ip -6 route':

default from 2a02:2788:74:119b:16cc:20ff:feff:67ae via fe80::6eb0:ceff:fe34:beb3 dev eth0  proto static  metric 512
2a02:2788:74:119b::/64 dev eth0  proto static  metric 256
2a02:2788:74:119b::/64 via fe80::6eb0:ceff:fe34:beb3 dev eth0  proto static  metric 512
2a02:2788:854:ddd::/64 dev br-lan  proto static  metric 1024
fe80::/64 dev eth0  proto kernel  metric 256
fe80::/64 dev br-lan  proto kernel  metric 256
fe80::/64 dev wlan0  proto kernel  metric 256

and here is the result of 'ifstatus wan6':

{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "uptime": 1211,
        "l3_device": "eth0",
        "proto": "dhcpv6",
        "device": "eth0",
        "metric": 0,
        "delegation": true,
        "ipv4-address": [

        ],
        "ipv6-address": [
                {
                        "address": "2a02:2788:74:119b:16cc:20ff:feff:67ae",
                        "mask": 128,
                        "preferred": 19,
                        "valid": 49
                }
        ],
        "ipv6-prefix": [

        ],
        "ipv6-prefix-assignment": [

        ],
        "route": [
                {
                        "target": "2a02:2788:74:119b::",
                        "mask": 64,
                        "nexthop": "::",
                        "metric": 256,
                        "valid": 1209569,
                        "source": "::\/0"
                },
                {
                        "target": "2a02:2788:74:119b::",
                        "mask": 64,
                        "nexthop": "fe80::6eb0:ceff:fe34:beb3",
                        "metric": 512,
                        "valid": 3182,
                        "source": "::\/0"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::6eb0:ceff:fe34:beb3",
                        "metric": 512,
                        "valid": 1769,
                        "source": "2a02:2788:74:119b:16cc:20ff:feff:67ae\/128"
                }
        ],
        "dns-server": [
                "2a02:2788:fff0:7::3",
                "2a02:2788:fff0:5::140"
        ],
        "dns-search": [
                "voo.be"
        ],
        "inactive": {
                "ipv4-address": [

                ],
                "ipv6-address": [

                ],
                "route": [

                ],
                "dns-server": [

                ],
                "dns-search": [

                ]
        },
        "data": {
                "passthru": "001700202a022788fff0000700000000000000032a022788fff0000500000000000001400018000803766f6f02626500"
        }
}

logread -f doesn't complain about this configuration, it says it will use the  nameserver 2a02:2788:fff0:7::3#53 and the nameserver  2a02:2788:fff0:5::140#53, and then says that wan6 is up.

As i said, pinging works from the router:

PING ipv6.google.com (2a00:1450:400c:c0c::65): 56 data bytes
64 bytes from 2a00:1450:400c:c0c::65: seq=0 ttl=50 time=20.618 ms
....

On a linux client, i did ifdown eth0 && ifup eth0 to refresh the config, and then tried pinging the same address:

PING ipv6.google.com(par03s15-in-x0e.1e100.net) 56 data bytes
From par03s15-in-x0e.1e100.net icmp_seq=1 Destination unreachable: Unknown code 5
....

traceroute ipv6.google.com

traceroute to ipv6.google.com (2a00:1450:4007:80c::200e), 30 hops max, 80 byte packets
 1  2a02:2788:854:ddd::1 (2a02:2788:854:ddd::1)  0.492 ms !<5>  0.602 ms !<5>  0.710 ms !<5>

Here is the ifconfig of the linux box:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.6  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2a02:2788:854:ddd:feaa:14ff:feb0:297f  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::feaa:14ff:feb0:297f  prefixlen 64  scopeid 0x20<link>
        ether fc:aa:14:b0:29:7f  txqueuelen 1000  (Ethernet)
        RX packets 78550  bytes 21606717 (20.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 34630  bytes 11798813 (11.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 54628  bytes 13144922 (12.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 54628  bytes 13144922 (12.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Windows client's don't work either (but pinging LAN ipv6 does, for example ping -6  2a02:2788:854:ddd:feaa:14ff:feb0:297f works).

I'm sure i'm missing something obvious (I'm new to IPV6), so can someone help me?

Thanks a lot wink

(Last edited by laci420 on 5 Feb 2016, 23:56)

Looks like your ISP is giving you nothing other than /128 - single IPV6 address.
They do not delegate routed subnet with DHCP6.

option ula_prefix '2A02:2788:854:DDD::/64'
Where did you take it from ?
Is it supposed to be statically configured internal subnet your ISP gave you ?
Note that ULA is not globally routable : https://en.wikipedia.org/wiki/Unique_local_address
Look at here : https://wiki.openwrt.org/doc/uci/network6
in the section "Static IPV6 connection".
In ipv6 case you need routed, not NATed network, so you dont need any local addresses.
IPV6 autoassign link-local addresses already.
What you really need is routed subnet. In most cases it will be /64.

(Last edited by bolvan on 6 Feb 2016, 08:59)

laci420 wrote:

Keeping this in mind, i made a wan6 interface, set it to be a dhcpv6 client, set request ipv6 address to 'try' and set request ipv6-prefix of length to automatic (i also tried settting it to 64). As for the wan interface, i didn't make any changes (DHCP server is disabled on the wan interface though, should i enable it?).
...
I also tried disabling the IPV6 firewall with ip6tables -F.
...
config globals 'globals'
        option ula_prefix '2A02:2788:854:DDD::/64'

Some comments:
* As the router has ipv6 connection but clients do not, the problem is in providing addresses & routing to LAN. Thus the dhcp, odhcpc settings are probably the ones with problems.
* You seem to have some kind of double-NAT connection (both modem and router NAT?) That might cause some effects, but as your router seems to get connectivity, I don't see the problem there.
* ULA is a separate issue (and like bolvan said, is non-routable). You should not set it manually to the routable prefix. Set a random one from the fd00::/8 space if you want ULA. (see bolvan's link)
* Firewall takes also care of the routing rules between different interfaces, so do not disable it. Make sure that wan6 is part of the wan zone. (default config including the several icmpv6 rules is otherwise ok)
* Network config: reqaddress and reqprefis options are probably not needed. ipv6 option in the main wan looks also strange, as you define wan6 for the ipv6 traffic.
* Dhcp config also has a few ipv6 sections (odchpd, additional dhcpv6+ra settings in lan).


I have a native ipv6 with PD and below are the relevant parts of my config as a model:
(network, dhcp and firewall)

/etc/config/network

config interface 'lan'
        option ifname 'eth0.1'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option ifname 'eth1'
        option proto 'dhcp'

config interface 'wan6'
        option ifname 'eth1'
        option proto 'dhcpv6'

config globals 'globals'
        option ula_prefix 'fd1b:7654:3210::/48'

/etc/config/dhcp

config 'dhcp' 'lan'
        option 'interface' 'lan'
        option 'start' '100'
        option 'limit' '150'
        option 'leasetime' '12h'
        option 'force' '1'
        option dhcpv6 'server'
        option ra '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'

/etc/config/firewall

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config forwarding
        option src 'lan'
        option dest 'wan'
...
config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

(Last edited by hnyman on 6 Feb 2016, 09:40)

Thank you all, however this doesn't seem to work. Now, all clients just get 'network unreachable' error, while running ip -6 route using ssh returns this:

default from 2a02:2788:74:119b:16cc:20ff:feff:67ae via fe80::6eb0:ceff:fe34:beb3 dev eth0  proto static  metric 512
2a02:2788:74:119b::/64 dev eth0  proto static  metric 256
2a02:2788:74:119b::/64 via fe80::6eb0:ceff:fe34:beb3 dev eth0  proto static  metric 512
fd1b:7654:3210::/64 dev br-lan  proto static  metric 1024
unreachable fd1b:7654:3210::/48 dev lo  proto static  metric 2147483647  error -128
fe80::/64 dev eth0  proto kernel  metric 256
fe80::/64 dev br-lan  proto kernel  metric 256
fe80::/64 dev wlan0  proto kernel  metric 256

I have found a similar post here:

Cannot route ipv6 from lan

Could this be really my ISP fault? As in the document linked earlier it clearly states there is a prefix delegation of /64

Can you enable Prefix Delegation on your modem (or check if it's enabled)?

Well there isn't really an option there, i can either enable or disable ipv6 and enable or disabled ipv6 firewall.

Then it looks like you don't have many options left. You could either use the bridge mode of your modem or use NAT6 as described in this howto.

Thank you so much guys! Nat'ed ipv6 works great! I'm so happy tongue. One more question though, how can i port forward with this configuration? Is it as simple as putting the ipv6 local address into the 'Internal IP address' in luci?

I just realized i probably can't without bridge mode because my modem can only forward to IPV4 addresses, so i may need to set it to bridge mode. Thanks everyone!

The discussion might have continued from here.