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.

hnyman wrote:

How have you defined the firewall zones in /etc/config/firewall? You are sure that FreeIPv6 has been added to the wan zone?

Sure. From the moment the suppression of the 6rd interface gives me better rédultats I abandoned FreeIPv6 for the moment.

hnyman wrote:

You might give the output of "ip6tables -L -v".

Edit: Please, go directly to this post to see my best succesful settings.

(Last edited by Manani on 11 Dec 2012, 15:29)

Manani wrote:
hnyman wrote:

What is the output of "route -A inet6"? I am wondering if a default route gets generated, or if you are left without one.

Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
2a01:e3x:xxxx:xxxx::/64                     ::                                      UA    256    0        0 eth1
2a01:e3x:xxxx:xxxx::/64                     ::                                      UA    256    0        0 br-lan
::/0                                        fe80::207:cbff:fe30:9329                UGDA  1024   0        0 eth1

I have no experience with 6rd, so my comments may be totally wrong, but I wonder about those three lines above:

Both eth1 (wan?) and br-lan serve 2a01:e3x:xxxx:xxxx::/64, which sounds strange to me.

Additionally, the global route next hop is to a link-local address  fe80::... Is that ISP's device? or what?


In my own 6in4 tunnel config, the nexthop is just to the tunnel, no nexthop given.
::/0      ::     U     1024   0        0 6in4-sixxs

Information from my ISP

• 6rd Tunneling playground :
# ip tunnel add sit2 mode sit local xx.xx.xx.xx \
6rd_prefix 2a01:e30::/28 ttl 64
# ip link set dev sit2 up
# ip -6 addr add 2a01:e3x:xxxx:xxx0::1/128 dev sit2
# ip -6 addr add 2a01:e3x:xxxx:xxx0::1/64 dev br0
# ip -6 route add default via ::192.88.99.201 \
dev sit2 metric 1
hnyman wrote:
Manani wrote:
hnyman wrote:

What is the output of "route -A inet6"? I am wondering if a default route gets generated, or if you are left without one.

Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
2a01:e3x:xxxx:xxxx::/64                     ::                                      UA    256    0        0 eth1
2a01:e3x:xxxx:xxxx::/64                     ::                                      UA    256    0        0 br-lan
::/0                                        fe80::207:cbff:fe30:9329                UGDA  1024   0        0 eth1

I have no experience with 6rd, so my comments may be totally wrong, but I wonder about those three lines above:

Both eth1 (wan?) and br-lan serve 2a01:e3x:xxxx:xxxx::/64, which sounds strange to me.

Additionally, the global route next hop is to a link-local address  fe80::... Is that ISP's device? or what?


In my own 6in4 tunnel config, the nexthop is just to the tunnel, no nexthop given.
::/0      ::     U     1024   0        0 6in4-sixxs

This is the default result of your build. I have made no changes except 6relayd activate and deactivate the network6.
I am a simple user off OpenWRT. I have no notion of development.

Manani wrote:

This is the default result of your build. I have made no changes except 6relayd activate and deactivate the network6.
I am a simple user off OpenWRT. I have no notion of development.

The same /64 on both sides is probably just the effect of 6relayd.
But I am still wondering about that link-local address as the next hop. As you can ping ipv6.google.com from the router, the basic routing works. But does your PC get a reasonable gateway/nexthop info? What does it say?

hnyman wrote:
Manani wrote:

This is the default result of your build. I have made no changes except 6relayd activate and deactivate the network6.
I am a simple user off OpenWRT. I have no notion of development.

The same /64 on both sides is probably just the effect of 6relayd.
But I am still wondering about that link-local address as the next hop. As you can ping ipv6.google.com from the router, the basic routing works. But does your PC get a reasonable gateway/nexthop info? What does it say?

Edit: Please, go directly to this post to see my best succesful settings.

(Last edited by Manani on 11 Dec 2012, 15:38)

Your PC seems to be missing all the ipv6 routing info. There should be info at least for the gateway and possibly also for the DNS server. This is from my PC:

IPv6 Address. . . . . . . . . . . : 2001:xxxx:xxxx:0:7271:bcff:fe4b:2990(Prefe
Temporary IPv6 Address. . . . . . : 2001:xxxx:xxxx:0:a8a2:d972:7fbe:c53e(Prefe
Link-local IPv6 Address . . . . . : fe80::7271:bcff:fe4b:2990%10(Preferred)
Default Gateway . . . . . . . . . : fe80::c43d:c7ff:fea3:3f50%10
                                    192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DHCPv6 IAID . . . . . . . . . . . : 191111524
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-13-F8-22-CB-70-71-BC-4B-29-90
DNS Servers . . . . . . . . . . . : 2001:xxxx:xxxx::1
                                    192.168.1.1

(Last edited by hnyman on 9 Dec 2012, 17:11)

This is great!
Because of you, CyrusFF and Hnyman, I'm certainly one of the first customer of Freetelecom to make 6rd behind the Freebox in bridge mode. The thing to do was very simple.

network

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

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

config interface 'wan6'
    option proto 'dhcpv6'
    option ifname '@wan'
    option reqaddress 'none'
    option reqprefix 'no'

6relayd

config server 'default'
    list network 'lan'
    option fallback_relay 'rd dhcpv6 ndp'
    option master 'wan6'
    option rd 'relay'
    option dhcpv6 'relay'

ipconfig /all

Carte réseau sans fil Connexion réseau sans fil 40 :

   Suffixe DNS propre à la connexion. . . : lan
   Description. . . . . . . . . . . . . . :  300Mbps Dual Band WirelessN USB Adapter
   Adresse physique . . . . . . . . . . . : 
   DHCP activé. . . . . . . . . . . . . . : Oui
   Configuration automatique activée. . . : Oui
   Adresse IPv6. . . . . . . . . . . . . .: 2a01:e3x:xxxx:xxxx:xxxx:xxxx:xxx:xxx4(préféré)
   Adresse IPv6 temporaire . . . . . . . .: 2a01:e3x:xxxx:xxxx:xxxx:xxxx:xxxx:xxx1(préféré)
   Adresse IPv6 de liaison locale. . . . .: fe80::e0e6:db46:7fbd:8e54%54(préféré)
   Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.2(préféré)
   Masque de sous-réseau. . . . . . . . . : 255.255.255.0
   Bail obtenu. . . . . . . . . . . . . . : dimanche 9 décembre 2012 18:11:15
   Bail expirant. . . . . . . . . . . . . : lundi 10 décembre 2012 07:43:43
   Passerelle par défaut. . . . . . . . . : fe80::3046:9aff:fefe:xxx%54
                                       192.168.1.1
   Serveur DHCP . . . . . . . . . . . . . : 192.168.1.1

No 6rd interface to create.

Thank you again for everything.


Edit1: luci still shows ipv6 wan status to Not connected   Fixed since r35468
Edit2: As the problem is resolved for 6rd I'm going to delete the logs and my settings from my previous posts. This is to aerate the topic.
Edit3: I will modify the post to indicate my optimal settings.

(Last edited by Manani on 3 Feb 2013, 11:09)

(moving my question to this thread)

tt wrote:

Ah - so the wiki is only suggesting initial settings then. (http://wiki.openwrt.org/doc/uci/network6)

It shows ula_prefix==auto as the appropriate setting for native ipv6, and omits it for all other configurations. I guess it's safe to assume this can be ignored, unless I decide to actually use private addressing.

I've discovered that for my 6to4 interface, the ula_prefix setting needs to be removed from /etc/config/network6. Otherwise (at least with default settings) the ula_prefix private address is advertised as Global, and nodes on the network send via it.

Is this my configuration error, or a bug?

[edit - build is hnyman's IPv6 WNDR3700, r34586]

These examples are with a Windows client, but I get the same result with Linux.
"fdf8:34cf:dabb::1" is the ula_private value initially generated by uci.

>tracert ipv6.google.com

Tracing route to ipv6.l.google.com [2607:f8b0:400c:c03::63]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  fdf8:34cf:dabb::1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *     ^C

OTOH, after deleting ula_prefix, the 6to4 address becomes the only globally scoped IPv6, and the packets go out normally:

>tracert ipv6.google.com

Tracing route to ipv6.l.google.com [2607:f8b0:400c:c01::67]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  2002:XXXX:XXXX::2
  2     *        *       37 ms  2002:c058:6301::
  3    38 ms    45 ms    42 ms  "gw1.isp.net"
  4    39 ms    37 ms    69 ms  "gw2.isp.net"
  5    43 ms    39 ms    39 ms  "gw3.isp.net"
  6      ^C

(Last edited by tt on 10 Dec 2012, 20:32)

Or you could use the policy table. Refer to RFC 4864:

In practice, applications may treat these addresses like global-
      scope addresses, but address selection algorithms may need to
      distinguish between ULAs and ordinary global-scope unicast
      addresses to ensure stability.  The policy table defined in [11]
      is one way to bias this selection, by giving higher preference to
      FC00::/7 over 2001::/3.  Mixing the two kinds of addresses may
      lead to undeliverable packets during times of instability, but
      that mixing is not likely to happen when the rules of RFC 3484 are
      followed.

Are you suggesting that I somehow configure all the nodes on my network to prefer 2002:: addresses? Windows, Ubuntu and even my wireless bridge-mode second OpenWRT device would all need this. Ouch, I'll stick with no-ULA.

Is it possible to selectively disable advertisement of the ULA?

Another solution is to get real IPv6 addresses, tunneled (for example Hurricane Electric) or native instead of using sub optimal 6to4 (2002::/16).

Absolutely. I'm running 6to4 on fumes until Comcast delivers on their long-ago promise in my area.

Ok, I'll leave ULA unconfigured for now.

Hmm I haven't encountered this issue but of course it should be safe to disable it. I will think of something, either disabling the ULA when other adresses are there or setting its preffered lifetime to 0 in this case. You can expect an update soon.

Let me know if you have any other idea.

(Last edited by CyrusFF on 11 Dec 2012, 11:12)

I just commited a fix for this.
The new behaviour is as follows:
* If the ULA prefix is the only one on an interface it is preferred.
* If there are other global prefixes the ULA prefix is send as non-preferred (deprecated) as long as this is still the case.

I am using 2001:470:xxxx::/64 and 2002:xxxx:xxxx::/64 prefixes on my lan, (the latter is used when communicating with 2002::/16). And I am thinking about adding an ULA prefix and use it for all internal communications between hosts on the lan. Using ULA will avoid renumbering if/when I replace my HE-tunnel with native IPv6.

Is this configuration compatible with this new way of configuring IPv6, and which openwrt version is needed in such case?

Won't host-to-host traffic be steered by your local name service? In my case above, the ULA choice causes trouble because my hosts are selecting that address for contacting the Openwrt device as an intermediate node, not an end node. Then, when that address goes out over 6to4 as a source address, the replies can't be returned.

(Last edited by tt on 12 Dec 2012, 04:38)

@mikma: Yes this would be supported by the new ipv6-support.
However it is in a early devleopment stage and not meant to be used in production right now. So you'd have to build OpenWrt-trunk from source or maybe try reasonably fresh snapshots. Expect changes and not having a WebUI for it for now. A stable release is scheduled for OpenWrt "Barrier Breaker" coming sometime next year.

@tt: the reason for having the ULA is supporting communication between non-bridged local interfaces when no public adresses are available.  This might however cause hosts to misbehave when both ULA and public prefixes are announced. My current workaround for now is that whenever a public prefix is announced the ULA prefix has a preferred lifetime of 0, meaning its deprecated and OS shouldn't use it for new connections and therefore the OSs should use the public prefix.

If there are still any problems, please let me know.

Your solution works well for me on hnyman's build r34672, with ula_prefix==auto. Thanks!

Nice. Thanks for testing!

You might get more feedback in near future, as the buildbot system is again generating new trunk snapshots, so more people have access to the updated ipv6-support modules. (but naturally they need to install it to the snapshots, as it is not yet part of the defaults)

(Last edited by hnyman on 14 Dec 2012, 09:25)

Yes I know. I also have other folks (besides OpenWrt) on the line to test and review this stuff at the moment.
For now I am quite satisfied with the progress. The only thing that is missing from my point now is the WebUI and proper DNS-integration (e.g. devices hostname properly resolve to their respective IPv6 adresses as well).

I think both things will come in a few weeks. The latter will probably involve gettings dnsmasq more integrated, e.g. making it the DHCPv6 and Router Advertisement server but we'll have to wait for some more features to be integrated there.

I was able to get also the WDS mode to run ok with the new ipv6-support modules. The basic advice in wiki is still valid: http://wiki.openwrt.org/doc/recipes/atheroswds. Basically router1 handles all the smart ipv6 stuff and router2 (the slave) is dumbed down.

In router1, the WDS master:
/etc/config/wireless:  mode is normal ap', set option 'wds' '1' for the existing wifi-iface section (I used the 5Ghz radio1)

In router2, the WDS slave:
/etc/config/dhcp: disable dhcp server (dnsmasq) by adding ignore 1 for LAN interface
/etc/config/network: change router's LAN IP for ipv4, make sure that there is option accept_ra '1', delete all ipv6 tunnel interface definitions
/etc/config/wireless: set option 'wds' '1' to the existing wifi-iface section, set mode to 'sta' (instead of 'ap')
/etc/config/network6: comment out everything with #, no functionality needed in this router

Those were the only changes needed. My PC was connected to router2 and got ipv4 & ipv6 addresses ok and the automatic routing through router1 to internet worked ok both for ipv4 & ipv6.

diff output about the key differences (excluding the deleted tunnel interfaces and commented network6):

--- /mnt/trunk/etc/config/wireless
+++ /etc/config/wireless
@@ -39,8 +39,9 @@
 config 'wifi-iface'
        option 'device' 'radio1'
        option 'network' 'lan'
-       option 'mode' 'ap'
+       option 'mode' 'sta'
        option 'ssid' 'WLANID'
        option 'encryption' 'psk2'
        option 'key' 'something'
        option 'wps_pushbutton' '1'
+        option 'wds' '1'
--- /mnt/trunk/etc/config/network
+++ /etc/config/network
@@ -9,7 +9,7 @@
        option 'ifname' 'eth0.1'
        option 'type' 'bridge'
        option 'proto' 'static'
-       option 'ipaddr' '192.168.1.1'
+       option 'ipaddr' '192.168.1.2'
        option 'netmask' '255.255.255.0'
        option accept_ra '1'

--- /mnt/trunk/etc/config/dhcp
+++ /etc/config/dhcp
@@ -19,6 +19,7 @@
        option 'limit' '150'
        option 'leasetime' '12h'
        option 'force' '1'
+       option 'ignore' '1'

 config 'dhcp' 'wan'
        option 'interface' 'wan'

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

when I look  to the changelog, there are a few network script related changes, and indirectly, some netifd changes.
https://dev.openwrt.org/changeset?sfp_e … sfph_mail=

Key parts of the system log. Looks like some triggers do not happen as the sixxs tunnel interface does not come up and 6distributed does not assign any address for the tunnel or for the lan interface.

EDIT: when thinking about the tunnel, it should be directly based on 6in4 package and netifd. No input from these new ipv6-support packages, so this is probably not actually related to this package, but might be more generic problem with netifd / libubus / network scripts.

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

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