OpenWrt Forum Archive

Topic: [IPv6] IPv4 OpenWRT Gateway obtaining IPv6 address from other router?

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

I have two Linksys WRT54GL routers running my home network. Still great little gadgets smile One of them is running the bcrm2.4 release of Backfire 10.03.1, and is my primary gateway to the internet for my home network. However, due to lack of good IPv6 firewall support, this router purely handles IPv4, not IPv6. We'll call this router 1.

My second router sits behind the first one and extends wireless range of the network (same SSID, different channel), as well as allows a couple of wired gadgets to connect to the net. This router is running the bcrm47xx release of Backfire 10.03.1. It also is my IPv6 gateway (currently utilising AICCU and a tunnel from SixXS). We'll call this router 2.

For any device on the network capable of using IPv6, the setup is currently working perfectly. They get their IPv4 address from router 1 via DHCP, and their IPv6 address from router 2 using RADVD.

However, router 1 doesn't have any IPv6 connectivity. Is there a way to have router 1 get an IPv6 address from router 2? I realise this will create a loop of sorts (traffic would go from router 1 to router 2 and back to router 1 again to actually go out onto the internet), but I don't plan for router 1 to be doing anything strenuous via IPv6, I just want it to have the connectivity.

Setting up another tunnel isn't an option (the aforementioned firewall issues being 1 problem, the lack of space being another, router 1 also acts as a free hotspot for people near the house using Chilli, so there's already a bit of space used up), and when I already have a perfectly good gateway on router 2, it seems silly to duplicate it anyway.

Has anyone tried this, or know if it's possible? I've tried the net.ipv6.conf.br-lan.accept_ra=2 trick using sysctl already, didn't seem to work, but I didn't reboot afterwards (I don't think it's necessary anyway, however I'm at work and don't want to risk knocking my connection to home offline).

Thanks for any help anyone can offer smile

You need one /64 prefix for each IPv6 network or peer-to-peer link you are setting up. One /48 or /56 prefix would be preferably, from which you creates two or more /64. I don't know about sixxs but with Hurricane Electric you can get one /48 per tunnel. For routers I try to avoid using RA to set addresses, and use static config.

I've done that part already. I have a /48 subnet of which I'm using a single /64 piece of it, and router 2 is serving that subnet using RADVD. Other devices on the network are successfully able to get the prefix and create a full IPv6 address, and connect to IPv6 addresses.

The only gap with this setup is router 1 has no IPv6 connectivity. I don't need another tunnel, I just want router 1 to act as an IPv6 client to router 2 (which itself is a client to router 1 for IPv4 connectivity).

The Linux 2.4 kernel does not support the magic value "2" for accept_ra. You'll most likely get it to receive slaac IPs by setting accept_ra to 1 and disabling ipv6 forwarding entirely.

Why can't you use static configuration or IPv6-address and default gateway on router 2?

Router 1, router 2 is the IPv6 gateway, and there probably isn't any reason why I can't just manually assign an IPv6 address I suppose. Not that it's likely to happen due to the address space, but is there any recommendations to avoid clashes?

Begin your address with one or more leading zero bytes. Addresses assigned by SLAAC never have a leading zero byte in the 64 bit host part afaik.

I'd use prefix::1/64 for one, and prefix::2/64 for the other.

(Last edited by mikma on 8 Nov 2012, 18:10)

Good advice, thanks mikma smile I've set up a manual IP address on router 1, and it can now ping6 router 2, as well as other IPv6 addresses on the internal network, it just doesn't seem to be able to get outside the network (i.e., can't connect or ping IPv6 addresses on the internet like ipv6.google.com).

Back to the drawing board smile Suspect I need to manually specify a gateway or something similar somewhere.

Drusenija wrote:

Suspect I need to manually specify a gateway or something similar somewhere.

Yes, your tunnel router should be configured as default gateway for ipv6, refer to network configuration in the wiki.

I have 2 Linksys WRT54GL routers operating my home network. Continue to great quick gadgets teeth One of them is flowing the bcrm2.4 launch of Backfire ten.03.1, as well as is my primary gateway to the internet for my home network. However, because of insufficient good IPv6 firewall assistance, the router strictly handles IPv4, not IPv6. We will call the router 1. My second router rests behind the first one as well as extends wireless selection of the network (same SSID, diverse channel), along with empowers a couple of wired devices to connect to the net. This excellent router is operating the bcrm47xx release of Backfire ten.03.1. It also is my IPv6 gateway (presently using AICCU along with a tunnel from SixXS). We'll call this router 2.

Hmm, well that's an interesting rewrite of my original post smile

mikma, I'd added an 'ip6gw' line into my /etc/config/network file in the appropriate place yesterday but it didn't work. I tried it again today figuring that would be my starting point, and today it worked. Go figure smile Thanks for your help!

Edit:
I bet I know what I did wrong. Router 1 provides the internet connectivity to router 2 that it requires for it's tunnel. I'll wager after rebooting router 1, router 2 hadn't had a chance to reestablish the tunnel when I did my test. Today I left it a bit longer.

(Last edited by Drusenija on 9 Nov 2012, 23:20)

Hi all,

I have been running IPV6 at home for more than a year with various isp configs. The router I use is a dlink DIR-825 that finally is behaving as it should. Meanwhile, the ISP (Telia) has gone from 6to4 to 6rd. So, my router gets its address based on its IP4 d:o, and now publishes a /64 prefix.

Hosts autoconfig and all is fine. I have tried to add two TL-WR841ND's mainly to use as wireless extenders (a bridge) to the adjacent building. No cigar, and it indicates the IPV6 / bridging / network code in Openwrt is not due for prime time.

However, beeing interested in the IPV6 migration, I am asking you to post what *is* and what *is not* working v.r. Openwrt.

I'll start: LAN A w ipv6 -- WR841 -- WDS link -- WR841 -- LAN B. Both routers with AA 12.09 beta 2 + kmod-ipv6 . Both routers eventually (will measure time) autoconfigure with the advertised prefix, so RADVD announcements get through, but I have traces where announcements have been corrupted by openwrt. It might happen "at random". However, it is NOT possible to communicate using IPV6, I have not determined yet exactly WHAT happens to the packets, (need to setup trace on wireless to capture WDS). Routing tables on two linux systems (on A and B) look the same.

DIR-600B2 OpenWrt Attitude Adjustment 12.09-beta2 / LuCI 0.11 Branch (0.11+svn9402)
   

IPV6 works perfect, probably due to wlan bridged to LAN, since router has NOT configured the LAN prefix, i.e. this seems erratic, it HAD configured the prefix a while ago. Right now only link local fe80::211:22ff:fe33:4455/64

Using this router as AP performance is same using IPV6 and IPV4, and client has full functionality. No modules loaded except kmod-ipv6 + web

Last: rebooting the router, it just configured its IPV6 addresses using the 6rd 2001:2002:xxxx:cccc prefix.

(Last edited by gulweb on 17 Nov 2012, 18:59)

TL-WR841ND #1 as access point:

Router autoconfigured using advertised LAN prefix. Client performance + functionality perfect, as previous post.

Edit:

TL-WR841ND #2, also tested and works flawless.

Now for renewed WDS test.

Edit 2:

In both previous tests the wifi was configured as (AP + WDS). Client was connected over wifi.

Reconfiguration as follows:

WR-841ND #2 was reconfigured as CLIENT + WDS. It was located orphaned on a table. Client PC connected to Local LAN with WR841 #1.

After startup, both routers pingable (IPV4). SSH into orphaned router. PING6 from orphaned router works flawlessly, both local and
to IPV6.google.com so, WDS in this config can carry IPV6. Now, last step Client was moved from Local LAN to LAN port on orphaned router.
IPV4 OK. No connectivity to IPV6, it is NOT possible to ping , and not possible to browse IPV6.google.com.

Internet -- Router --- LAN ---WR841 #1 --- WDS--- WR841#2 -- Client
OK             OK            OK        OK                                  OK                 BAD ; ipv6 connectivity.

                radvd here                                     wds here

Puzzled.......

Anyone have a good idea of what to try next?

(Last edited by gulweb on 17 Nov 2012, 20:06)

I would try to ping link local IPv6 addresses from the client. If the neighbour discovery protocol (uses ICMPv6 multicast) isn't working then I might add entries for the peers with the "ip -6 neigh" command instead for testing

And use tcpdump on each device to check where the ICMPv6 packets are dropped.

Some debugging progress, but not working...

I have now traced neighbor solicitation, and found out they do not pass the WDS bridge. Moreover, these are sent as different multicasts 33:33:xx:xx:xx:xx, . There are interface parameters mc_forwarding but someone has gone to lengths to define these as readonly in the /proc filesystem. It is interesting to see that most OTHER params can be switched on/off, but not these. There must be some logic here, and I guess these are set up somehow during init, (not precompiled??) so now the question is WHERE to turn these on. It makes sense NOT to turn mc_forwarding on by default, if the router is supposed to route this traffic, however, in MY case (and most probably many others) you do not want transparent bridging between ports 1-4 (LAN) and NOT on wifi.

mikma wrote:

I would try to ping link local IPv6 addresses from the client. If the neighbour discovery protocol (uses ICMPv6 multicast) isn't working then I might add entries for the peers with the "ip -6 neigh" command instead for testing

And use tcpdump on each device to check where the ICMPv6 packets are dropped.

Yes, thanks for the tip about ip neigh, once I set this up, I can ping across the WDS bridge, so now we know this is the problem.

The remedy is of course to be able to turn mc_forwarding on for the components of br-0 (and perhaps for br0 itself). Or, maybe br-0 is the only one, if enrolled interfaces inherit the masters parameters....

Once this is figured out the result could be a small "howto".

Edit: I feel I am *very* close to the solution now, this is mentioned sporadicly for some years , but is not well described......and nobody has
bothered to explain/resolve this, but this is the IPV6 year.........

(Last edited by gulweb on 18 Nov 2012, 02:12)

Packets to/from link local addresses should never be forwarded by a router. But bridges as in your scenario should forward such traffic to allow NDP and RA. I expect mc_forwarding is only used when acting as a router, since mc_forwarding is disabled on my openwrt router. But IPv6 NDP still works via the ethernet bridge br-lan, between wired and wireless lan.

I don't know if it is useful but it is possible to set up proxy ndp (similar to proxy arp) using ip neigh. And there is also a ndp proxy daemon available in openwrt. http://priv.nu/projects/ndppd/

(Last edited by mikma on 18 Nov 2012, 02:38)

mikma wrote:

Packets to/from link local addresses should never be forwarded by a router. But bridges as in your scenario should forward such traffic to allow NDP and RA. I expect mc_forwarding is only used when acting as a router, since mc_forwarding is disabled on my openwrt router. But IPv6 NDP still works via the ethernet bridge br-lan, between wired and wireless lan.

I don't know if it is useful but it is possible to set up proxy ndp (similar to proxy arp) using ip neigh. And there is also a ndp proxy daemon available in openwrt. http://priv.nu/projects/ndppd/

Yes, that was my guess, after I spent some time tcpdumping. And the way it works is wrong, at least with my config. However, it would be nice if the only components required for a working router were the base system + kmod-ipv6. I read the "fine print" and installed kmod-ip6tables and ip6tables with the assumption that would change the mc_forwarding default. No, that did NOT change anything. Anyway, it is not consistant, and since when bridged wifi and switch0 are the same "lan", it should be transparent by default, after all ports in the switch are. The problem is I do not know what the openwrt designers had in mind: IS there some important aspect that has warranted disabling L2 connectivity, and why did someone go to the extent of making that system parameter READONLY, or is this just a bug? 13 years ago, working at D I G I T A L , we had this running smoothly, and yes, you dont need a router, and multiple routers on a LAN should also autoconfigure by overlap / merge. So finally we could get rid of SOME of the manual IP config work.

But, if it was hard to write, it should be hard to read :-)

(Last edited by gulweb on 18 Nov 2012, 03:08)

Hmm, these live in addrconf.c in linux/net/ipv6. I can see that the presumed controlling variables are declared so that they ar readonly as opposed to anything else. So, no for setting up a build environment and fix this....

Have to check whether this is linux generic, or openwrt....well, it seems so, cause my linux box also has write protection on this parameter.

Interesting test, take a standard Linux box, make a bridge from 2 or more ethernet interfaces, enable ipv6 forwarding, and voila: a broken bridge ??

Edit:

I wonder if this is the reason the original TP-Link firmware failed to bridge IPV6 between Lan - Wifi - Lan. I guess the TP-link firmware is based on the same source, and since this seems to be a linux kernel-net-ipv6 issue they have the problem too..And IPV6 has not been so prevalent yet.

(Last edited by gulweb on 18 Nov 2012, 15:44)

mikma wrote:

Packets to/from link local addresses should never be forwarded by a router. But bridges as in your scenario should forward such traffic to allow NDP and RA. I expect mc_forwarding is only used when acting as a router, since mc_forwarding is disabled on my openwrt router. But IPv6 NDP still works via the ethernet bridge br-lan, between wired and wireless lan.

I don't know if it is useful but it is possible to set up proxy ndp (similar to proxy arp) using ip neigh. And there is also a ndp proxy daemon available in openwrt. http://priv.nu/projects/ndppd/

I suspect this is a WDS-only issue, since if you just want to get out on the internet, the client KNOWS the router, and its lladdr. When you want to talk between systems, this is also OK on wired systems, since these can use the L2 connectivity of the switch and it does not block anything, the problem occurs when you want to forward packets with same prefix between switch and wifi. But with that reasoning the problem SHOULD be seen with a single router as well.

I also have another contradictory observation, in that when I tested with a single client connected to an orphaned WDS bridge, I actually managed to achieve IPV6 connectivity to the internet at ONE time. It might be influenced by what is in the neighbor cache, but a lack of ability to refresh said cache.

Edit:

Just passively monitoring the "lemote lan" which is WDS bridged, there seems to be ONE multicast that makes it through, 33:33:00:00:00:01
Can someone explain why this is forwarded when mc_forwarding is 0, which was the assumtion why OTHER mc do not pass the WDS bridge?

(Last edited by gulweb on 18 Nov 2012, 20:55)

I have not been able to find any writeup about how this is ACTUALLY supposed to work. My ramblings up til now seems very wrong anyhow.

Clearly mc_forwarding is NOT supposed to be a significant knob with regards to this. My testing has proceeded, and I can see the default router
messages: There is a "current multicast table" ( I think) at /proc/net/dev_mcast. In this table there are entries that correspond to allnodes multicast, which explains why the router multicast gets through. It is possible to ping6 all local addresses (fe80::......) but then the MAC addresses can be derived from these IPV6 addresses.  My TL-WR841s are now running AA 12.09 beta2 + kmod-ipv6 + radvd. Radvd is started, but does NOT cause the 841s to transmit anything, even though they have heard the lan IPV6 router announcement , and configured  a "live" IPV6 prefix.

In the web interface, there is an option to 1) listen to IPV6 announcement or 2) send announcement. However, these are mutually exclusive.

A peculiar thing is that the MAC mc-address corresponding to the router ITSELF is added to the table, however, I do not understand why the router would want to listen to ITSELF, these filters are input only are they not? A case of loop detection??

Right now I believe there is something that needs to be turned on, i.e. the ipv6 router proper for the blocked mcasts to be enabled.

The ndp problem is still there, but right now I have three routers on the LAN, one that is the "real" one, that propagates a 6rd address out on the LAN
and two that just have the kmod-ipv6 and radvd installed, now all routers agree on the prefix and topology. However, hosts cannot talk across the WDS bridge. Within the routers everything can be reached, and because of the neighbor cache, if I first ping a host FROM openwrt, then that host can also ping6 that router. Leaving the net idle, it is not possible to initiate anything from a host, and tcpdumping shows no router responses to neighbor solicitations.

So, now the question is: what optional component / package is required to turn on ndp forwarding in the openwrt ipv6 stack?

If Ipv6 multicast can't work across the WDS bridge, then I guess they should be separate IPv6 networks and that you got two LANs connected with a link, i.e. three IPv6 networks which each needs a /64 prefix.

With a static IPv6 prefix of length /48, /56 or even /60 it would be easy to add static adresses to all three routers, and set up routing.

The situation with a dynamic IPv6 prefix is more complex means you need to use one (or even two) DHCPv6-PD server(s).

Btw, have you looked at ndppd - NDP Proxy Daemon? Maybe running it on the two devices with the WDS link is a solution.

(Last edited by mikma on 20 Nov 2012, 03:02)

mikma wrote:

If Ipv6 multicast can't work across the WDS bridge, then I guess they should be separate IPv6 networks and that you got two LANs connected with a link, i.e. three IPv6 networks which each needs a /64 prefix.

With a static IPv6 prefix of length /48, /56 or even /60 it would be easy to add static adresses to all three routers, and set up routing.

The situation with a dynamic IPv6 prefix is more complex means you need to use one (or even two) DHCPv6-PD server(s).

Btw, have you looked at ndppd - NDP Proxy Daemon? Maybe running it on the two devices with the WDS link is a solution.

Hello Mikma,

There are *many* workarounds, and I had hoped someone working with the IPV6 within Openwrt would see this discussion and comment. I cannot imagine this is entirely broken, (which I suspected b4 trying to understand the details) but I now suspect there is some component missing that has been architected by someone, problem is we do not know what, who and when. I tried to understand what the proxy was supposed for, and probably not for solving this problem.

The *correct* (??) way to solve this is of course to make sure a bridge should look the same whether it is IPV4 ( same subnet) IPV6 (same subnet) or other protocols that might be used on a LAN. Right now I believe just disabling multicast filtering could be done with only "one knob", some more elaborate solution (for ipv6)  would be to allow ALL 33:33:xx.xx.xx.xx multicasts "allow_ip6_multicasts". I will surely pursue something like this, since I want my clients to be treated equal, whether IP4 / IP6 or mixed stack. I have no problem with this NOT beeing default behaviour, it it is easy to reconfigure. I have used the Linux bridge in the past, clearly many things have changed since then, and most of this is lack of understanding on my behalf"
Regards,

Gulweb

The discussion might have continued from here.