OpenWrt Forum Archive

Topic: 6rd and ipv6-support

The content of this topic has been archived between 12 Jul 2015 and 30 Apr 2018. Unfortunately there are posts – most likely complete pages – missing.

nbd wrote:

On the rev that fails, please show me the output of 'ifstatus sixxs'

 BARRIER BREAKER (Bleeding Edge, r34739)
...
root@OpenWrt:~# ifstatus sixxs
{
        "up": false,
        "pending": true,
        "available": true,
        "autostart": true,
        "proto": "6in4",
        "data": {

        },
        "errors": [
                {
                        "subsystem": "6in4",
                        "code": "NO_WAN_LINK"
                }
        ]
}

also LAN shows empty for ipv6 adress:

root@OpenWrt:~# ifstatus lan
{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "uptime": 188,
        "l3_device": "br-lan",
        "proto": "static",
        "device": "br-lan",
        "metric": 0,
        "ipv4-address": [
                {
                        "address": "192.168.1.1",
                        "mask": 24
                }
        ],
        "ipv6-address": [

        ],

(Last edited by hnyman on 18 Dec 2012, 21:11)

similar problem here, with 6in4 and hurricane:

 BARRIER BREAKER (Bleeding Edge, r34744)
 -----------------------------------------------------
  * 1/2 oz Galliano         Pour all ingredients into
  * 4 oz cold Coffee        an irish coffee mug filled
  * 1 1/2 oz Dark Rum       with crushed ice. Stir.
  * 2 tsp. Creme de Cacao
 -----------------------------------------------------
root@kozlic:~# 
root@kozlic:~# ifstatus henet
{
    "up": false,
    "pending": true,
    "available": true,
    "autostart": true,
    "proto": "6in4",
    "data": {
        
    },
    "errors": [
        {
            "subsystem": "6in4",
            "code": "NO_WAN_LINK"
        }
    ]
}

As fas as I was able to diagnose, that "NO_WAN_LINK" is coming from the 6in4 script, which fails to find the normal ipv4 wan address.

Try this patch:

diff --git a/package/network/ipv6/6in4/files/6in4.sh b/package/network/ipv6/6in4/files/6in4.sh
index 651d7b9..bb36ded 100755
--- a/package/network/ipv6/6in4/files/6in4.sh
+++ b/package/network/ipv6/6in4/files/6in4.sh
@@ -26,6 +26,8 @@ proto_6in4_setup() {
        ( proto_add_host_dependency "$cfg" 0.0.0.0 )
 
        [ -z "$ipaddr" ] && {
+               network_flush_cache
+
                local wanif
                if ! network_find_wan wanif || ! network_get_ipaddr ipaddr "$wanif"; then
                        proto_notify_error "$cfg" "NO_WAN_LINK"

fixed! thanks

hnyman wrote:

IPv6 functionality seems to be broken for me with r34739. Worked ok with yesterday's r34715.

The fix mentioned by Jow works for me, too. So, this bug was caused by the libubox library, not the ipv6-support module.

One question about r34908: https://dev.openwrt.org/changeset/34908

It looks like there is a new option "site_border".
Wiki says that the default is 0: http://wiki.openwrt.org/doc/uci/network6#options
but default config file sets it to 1: https://dev.openwrt.org/browser/trunk/package/network/ipv6/ipv6-support/files/network6.config

Which is right?

The same discrepancy goes actually also for "peerdns" and "prefix_fallback", as the default config file sets values differing from the supposed default values. Is that intentional?

I understand that the underlying scripts use "no action defaults", but it might then be documented better in the wiki that what are the suggested values and why the default config file sets those values.

OK fixed this for peerdns and site_border as it is more consistent for the default to be 1 as one would expect that they are useful in most cases.

For prefix_fallback I will leave it as is for now as the prefix_fallback can cause some surprises if you don't know about it and it is not mentioned in the config file.

I have Comcast cable Internet in Salt Lake City, UT. There appears to be native ipv6 support. When I use the ISC dhcp6c (IIRC) on Openwrt, I get a /64, but when I use the odhcp6c it gives me a /128. Any ideas?

I tried several dhcp6 clients, and one gave the /64, but the rest give the /128.

I'm also having trouble getting ipv6-support to set up ipv6 on anything other than wan and lan. I also have a dmz and a hot network, and want ipv6 on them. When I attempt to enable it, none of the interfaces get ipv6 addresses. What could I be doing wrong? What's the right way to set this up?

interesting. can you try setting
option request_prefix 64
in the wan section of network6

also if you still have the isc dhcp at hand a pcap using tcpdump or so would help.

edit
regarding your address problem. have you added sections in network6 (similar to lan with mode router) for your other interfaces?

(Last edited by CyrusFF on 29 Dec 2012, 19:52)

Ok. Today I have my 3 year old with me, and he wants to play. :-)  Later this evening, or perhaps not until Sunday or Monday... I'll use opkg to install the other dhcp6 client and tcpdump, then write you a report.

thank you very much

I ran the 'odhcp6c' by hand from the command line, using the same
arguments as I saw it running with when it was started for me by the
system. Here's the output:

root@gw:~# /usr/sbin/odhcp6c -s/lib/ipv6/dhcpv6.sh -P64 eth0
odhcp6c[16571]: Sending SOLICIT (timeout 4294967295s)
odhcp6c[16571]: Got a valid reply after 38ms
odhcp6c[16571]: Got a valid reply after 95ms
odhcp6c[16571]: Sending REQUEST (timeout 4294967295s)
odhcp6c[16571]: Got a valid reply after 38ms
odhcp6c[16571]: assigning address 2001:558:6008:18:1c3a:2a5b:1fd3:9438/128 for iface 2: Success
odhcp6c[16571]: State for eth0 changed to bound
odhcp6c[16571]: Sending <POLL> (timeout 86400s)
sh: missing ]
/lib/ipv6/dhcpv6.sh: line 33: bound: not found


Here's the tcpdump command and output from that:

tcpdump -i eth0 -n -l -vv '(ip6 net fe80::/10 && udp && portrange 546-547)'

15:48:57.821012 IP6 (hlim 1, next-header UDP (17) payload length: 128) fe80::215:6dff:fec5:c200.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=1f0c78 (elapsed-time 0) (option-request DNS-server DNS-search-list) (client-ID hwaddr type 1 00156dc5c200) (reconfigure-accept) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0) (IA_PD-prefix ::/64 pltime:0 vltime:0))
15:48:57.857194 IP6 (hlim 64, next-header UDP (17) payload length: 178) fe80::201:5cff:fe22:5d01.547 > fe80::215:6dff:fec5:c200.546: [udp sum ok] dhcp6 advertise (xid=1f0c78 (client-ID hwaddr type 1 00156dc5c200) (server-ID hwaddr/time type 1 time 390983873 14feb5d5b44d) (IA_NA IAID:1 T1:172800 T2:276480 (IA_ADDR 2001:558:6008:18:1c3a:2a5b:1fd3:9438 pltime:345600 vltime:345600)[|dhcp6ext]) (IA_PD IAID:1 T1:172800 T2:276480 (IA_PD-prefix 2601:7:6c00:48::/64 pltime:345600 vltime:345600) (reconfigure-accept) (preference 255)[|dhcp6ext]) (reconfigure-accept) (preference 255) (DNS-server 2001:558:feed::2 2001:558:feed::1))
15:48:57.914642 IP6 (hlim 64, next-header UDP (17) payload length: 178) fe80::201:5cff:fe22:5d01.547 > fe80::215:6dff:fec5:c200.546: [udp sum ok] dhcp6 advertise (xid=1f0c78 (client-ID hwaddr type 1 00156dc5c200) (server-ID hwaddr/time type 1 time 390983871 14feb5d5aa6c) (IA_NA IAID:1 T1:172800 T2:276480 (IA_ADDR 2001:558:6008:18:893e:d0f:d887:850 pltime:345600 vltime:345600)[|dhcp6ext]) (IA_PD IAID:1 T1:172800 T2:276480 (IA_PD-prefix 2601:7:6c40:14::/64 pltime:345600 vltime:345600) (reconfigure-accept) (preference 0)[|dhcp6ext]) (reconfigure-accept) (preference 0) (DNS-server 2001:558:feed::2 2001:558:feed::1))
15:48:58.759181 IP6 (hlim 1, next-header UDP (17) payload length: 142) fe80::215:6dff:fec5:c200.546 > ff02::1:2.547: [udp sum ok] dhcp6 request (xid=e88c22 (elapsed-time 0) (option-request DNS-server DNS-search-list) (client-ID hwaddr type 1 00156dc5c200) (server-ID hwaddr/time type 1 time 390983873 14feb5d5b44d) (Client-FQDN) (IA_NA IAID:1 T1:0 T2:0) (IA_PD IAID:1 T1:0 T2:0) (IA_PD-prefix ::/64 pltime:0 vltime:0))
15:48:58.795692 IP6 (hlim 64, next-header UDP (17) payload length: 169) fe80::201:5cff:fe22:5d01.547 > fe80::215:6dff:fec5:c200.546: [udp sum ok] dhcp6 reply (xid=e88c22 (client-ID hwaddr type 1 00156dc5c200) (server-ID hwaddr/time type 1 time 390983873 14feb5d5b44d) (IA_NA IAID:1 T1:172800 T2:276480 (IA_ADDR 2001:558:6008:18:1c3a:2a5b:1fd3:9438 pltime:345600 vltime:345600)[|dhcp6ext]) (IA_PD IAID:1 T1:172799 T2:276479 (IA_PD-prefix 2601:7:6c00:48::/64 pltime:345599 vltime:345599)[|dhcp6ext]) (DNS-server 2001:558:feed::2 2001:558:feed::1))

... and the result:

ip -6 addr show dev eth0

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 5
    inet6 2001:558:6008:18:1c3a:2a5b:1fd3:9438/128 scope global dynamic
       valid_lft 345569sec preferred_lft 345569sec
    inet6 fe80::215:6dff:fec5:c200/64 scope link
       valid_lft forever preferred_lft forever


After killing that, and running "/etc/init.d/dhclient6 start" to
launch the ISC dhclient, using the defaults straight from it's freshly
installed package:

tcpdump -i eth0 -n -l -vv '(ip6 net fe80::/10 && udp && portrange 546-547)'

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:05:13.553193 IP6 (hlim 1, next-header UDP (17) payload length: 62) fe80::215:6dff:fec5:c200.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=5f36e6 (client-ID hwaddr/time type 1 time 410137513 00156dc5c200) (option-request DNS-server DNS-search-list opt_54) (elapsed-time 0) (IA_NA IAID:1841676800 T1:3600 T2:5400))
16:05:14.644950 IP6 (hlim 1, next-header UDP (17) payload length: 62) fe80::215:6dff:fec5:c200.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=5f36e6 (client-ID hwaddr/time type 1 time 410137513 00156dc5c200) (option-request DNS-server DNS-search-list opt_54) (elapsed-time 109) (IA_NA IAID:1841676800 T1:3600 T2:5400))
16:05:16.907833 IP6 (hlim 1, next-header UDP (17) payload length: 62) fe80::215:6dff:fec5:c200.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=5f36e6 (client-ID hwaddr/time type 1 time 410137513 00156dc5c200) (option-request DNS-server DNS-search-list opt_54) (elapsed-time 335) (IA_NA IAID:1841676800 T1:3600 T2:5400))
16:05:16.949593 IP6 (hlim 64, next-header UDP (17) payload length: 133) fe80::201:5cff:fe22:5d01.547 > fe80::215:6dff:fec5:c200.546: [udp sum ok] dhcp6 advertise (xid=5f36e6 (client-ID hwaddr/time type 1 time 410137513 00156dc5c200) (server-ID hwaddr/time type 1 time 390983873 14feb5d5b44d) (IA_NA IAID:1841676800 T1:172800 T2:276480 (IA_ADDR 2001:558:6008:18:4dc4:a4c4:239e:9cfd pltime:345600 vltime:345600) (preference 255)[|dhcp6ext]) (preference 255) (DNS-server 2001:558:feed::2 2001:558:feed::1))
16:05:16.951789 IP6 (hlim 1, next-header UDP (17) payload length: 108) fe80::215:6dff:fec5:c200.546 > ff02::1:2.547: [udp sum ok] dhcp6 request (xid=5b1da7 (client-ID hwaddr/time type 1 time 410137513 00156dc5c200) (server-ID hwaddr/time type 1 time 390983873 14feb5d5b44d) (option-request DNS-server DNS-search-list opt_54) (elapsed-time 0) (IA_NA IAID:1841676800 T1:3600 T2:5400 (IA_ADDR 2001:558:6008:18:4dc4:a4c4:239e:9cfd pltime:7200 vltime:7500) (opt_0) (opt_0) (opt_0)))
16:05:17.000436 IP6 (hlim 64, next-header UDP (17) payload length: 128) fe80::201:5cff:fe22:5d01.547 > fe80::215:6dff:fec5:c200.546: [udp sum ok] dhcp6 reply (xid=5b1da7 (client-ID hwaddr/time type 1 time 410137513 00156dc5c200) (server-ID hwaddr/time type 1 time 390983873 14feb5d5b44d) (IA_NA IAID:1841676800 T1:172800 T2:276480 (IA_ADDR 2001:558:6008:18:4dc4:a4c4:239e:9cfd pltime:345600 vltime:345600)[|dhcp6ext]) (DNS-server 2001:558:feed::2 2001:558:feed::1))

ip -6 addr show dev eth0

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 5
    inet6 2001:558:6008:18:46b:d462:a467:c5e9/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::215:6dff:fec5:c200/64 scope link
       valid_lft forever preferred_lft forever

This patch clears up that error message, but does not provide me with a /64 on wan.

Index: package/network/ipv6/ipv6-support/files/dhcpv6.sh
===================================================================
--- package/network/ipv6/ipv6-support/files/dhcpv6.sh    (revision 34933)
+++ package/network/ipv6/ipv6-support/files/dhcpv6.sh    (working copy)
@@ -30,7 +30,7 @@


# Operations in case of success
-[ "$state" == "timeout" || "$state" == "unbound" ] && exit 0
+[ "$state" == "timeout" ] || [ "$state" == "unbound" ] && exit 0

local peerdns
config_get_bool peerdns "$network" peerdns 1

For what it's worth, I get 10/10 almost instantly when I visit http://ipv6.test-ipv6.com/. My workstation and laptop, when connected via br-lan, get ula addresses. The address shown at that test page is the external address of my OpenWRT router. The br-lan interface itself has both a ula and global ipv6 address with a /64 prefix, but that's not being propagated to the workstation.

EDIT: I was incorrect. Apparently it takes a little longer for the ipv6 address to be assigned... Now I'm seeing that my workstation indeed has a global /64 address in the same subnet as the global address assigned to the br-lan interface on the router. But, the wan interface on the router does not have an address in the same subnet. Is that normal? (I've not yet finished reading a book on the subject, sorry. I'll try to get in a chapter a day.)

(Last edited by KarlHegbloom on 30 Dec 2012, 17:54)

That is interesting. Thanks for the dumps.
It seems that with ISC dhcp you do not really get a /64 prefix. It just requests a regular address (like a client) and adds it with a /64-prefix instead of a /128. I'm not sure whether this is correct or now, however the address you get is not the prefix you could use. To acquire prefixes it needs to send an IA_PD option and receive prefixes in that.

odhcp6c logs look fine. It gets a prefix (IA_PD option) and hopefully tries to distribute it. Do you by chance have more than one interface with mode=router in network6? If yes, maybe try requesting a bigger prefix (e.g. request_prefix 60 instead of 64).

However as you said that br-lan has both a ULA and global prefix with odhcp6c, correct? In that case it should advertise both prefixes. Are you sure that your clients only get a ULA-adress? ULA-traffic should not be routed through the wan-interface and I don't see how you could pass the ipv6 test otherwise.

I will test native DHCPv6 stuff etc. when I'm back home in 2 days or so.
Thanks for finding the typo in dhcpv6.sh, however I don't think it has any effect in your scenario.

(Last edited by CyrusFF on 30 Dec 2012, 09:56)

I'm only getting a /128 from Comcast too. When I was using wide-dhcpv6-client before I was getting a /128 on WAN and a /64 on LAN, and everything was working great. I'm using the suggested "native" configuration for ipv6-support, and I've tried everything but I can't seem to get it to work. Can anybody give me some tips if they've gotten their ipv6-support config to work with Comcast?

CyrusFF wrote:

That is interesting. Thanks for the dumps.
It seems that with ISC dhcp you do not really get a /64 prefix. It just requests a regular address (like a client) and adds it with a /64-prefix instead of a /128.

Prefix lengths for regular client addresses are announced via RA and not DHCPV6 I think.

@mikma: yes but there was a confusion of an individual address and a prefix.
@erictooth: can you give some details? how did you configure wide? are there any prefix-related messages in the log?
how did you configure network6? did you try to set request_prefix to a distinct value (e.g. 64)?

(Last edited by CyrusFF on 14 Jan 2013, 08:36)

CyrusFF wrote:

@erictooth: can you give some details? how did you configure wide? are there any prefix-related messages in the log? how did you configure network6? did you try to set request_prefix to a distinct value (e.g. 64)?


network6ipv6-support, not working, "standard" native ipv6 config according to wiki on ipv6-support. WAN interface gets a /128 starting with 2001, LAN gets nothing.

config interface 'wan'
    option mode 'dhcpv6'
    option request_prefix 'auto'     # I also tried 64
    option prefix_fallback 'relay'

config interface 'lan'
    option mode 'router'
    option advertise_prefix '64'
    option relay_master 'wan'

dhcp6cwide-dhcpv6-client, working. WAN gets a /128 starting with 2001 and LAN gets a /64 starting with 2601.

config 'dhcp6c' 'basic'
    option 'enabled' '1'
    option 'interface' 'wan'
    option 'dns' 'dnsmasq'
    option 'debug' '0'

    option 'pd' '1'                    # Prefix Delegation
    option 'na' '1'                    # Non-Temporary Address — must be '1' for Comcast
    option 'rapid_commit' '1'            # Rapid Commit

config 'interface' 'lan'
    option 'enabled' '1'
    option 'sla_id' '1'
    option 'sla_len' '0'

I won't be able to go through the logs until later today but I'll post whatever I find.

I just commited some major changes for IPv6-support. This is the final native integration now. I don't expect the configuration to break any more only some more things might be added later on.

Configuration is now much easier. You only need to configure /etc/config/network now, there is no network6 any more. Everything should feel more integrated now.

I updated the examples on http://wiki.openwrt.org/doc/uci/network6

For configuration details see:
Static: http://wiki.openwrt.org/doc/uci/network#protocol.static
DHCPv6: http://wiki.openwrt.org/doc/uci/network#protocol.dhcpv6
etc.

Prefix distribution and relaying: http://wiki.openwrt.org/doc/uci/6relayd
(The old way of configuring 6relayd directly should still work).

Other Changes:
* 6distributed and network6 are now gone.
* IPv6 prefix-related configuration is now handled by /etc/config/network (netifd)
* RD, DHCPv6 server & RD, DHCPv6 and NDP relaying support (as well as the fallback-handling) is now handled in /etc/config/6relayd


If you want to use radvd or dnsmasq-dhcpv6 (>=2.66) for your configuration then you can configure them accordingly (for dnsmasq this might need you to add some more init-logic).

(Last edited by CyrusFF on 15 Jan 2013, 15:22)

FYI: I just pushed some fixes for DHCPv6 over PPP.

* select the correct interface when doing DHCPv6 over PPP
* fix "ICMPv6: RA: ndisc_router_discovery failed to add default route"-issue
* fix dhcpv6 client using all-zero MAC over PPP interfaces

I tested this with a local pppoe-testserver so it should now hopefully work as expected.
It should now not be necessary to use radvd or wide-dhcpv6-client for prefix delegation to work correctly.

Sorry, posts 76 to 75 are missing from our archive.