FYI: dhcpv6 should work again now. sorry for the inconveniences

Hello
@Hnyman
Since some versions the default settings allow proper functioning of 6rd. My customization consite simply adding the port forwarding, the allocation of permanent leases and the settings for wi-fi.
I will do some tests again and I will inform you.

Edit: i'll wait for next build with fixed DHCPv6 before testing.

(Last edited by Manani on 2 Feb 2013, 11:57)

It was a settings problem. Everything goes well as follows:

network

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'

Thanks

CyrusFF,

Currently running on trunk r35407. Made the following changes. The wan comes up for a few minutes and then drops. The pc client now cannot get any ipv6 address from the router. Think before when I was using radvd, the router propagated the ra nicely.  Now a little confused if I should go back to radvd. Any ideas?

Thanks.

Edit : Reinstalled radvd and the router propagates the ipv6 lan addresses nicely.

/etc/config/network

config interface 'lan'
    option type 'bridge'
    option proto 'static'
    option netmask '255.255.255.0'
    option _orig_ifname 'eth0.1 radio0.network1'
    option _orig_bridge 'true'
    option ifname 'eth0.1'
    option ipaddr '192.168.1.254'
    option ip6assign '64'

config interface 'wan'
    option ifname 'eth0.2'
    option _orig_ifname 'eth0.2'
    option _orig_bridge 'false'
    option proto 'dhcp'
    option broadcast '1'

config globals 'globals'
    option ula_prefix '2001:xxxx:xxxx:4::/64'

config interface 'wan6'
    option proto 'static'
    option ifname 'eth0.2'
    option dns '2001:xxxx:xxxx::3 2001:xxxx:xxxx::3'
    option ip6addr '2001:xxxx:xxxx::9f/64'
    option ip6gw '2001:xxxx:xxxx::1'
    option ip6prefix '2001:xxxx:xxxx:4::/64'

/etc/config/6relayd

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

(Last edited by wkweksl on 3 Feb 2013, 04:17)

Set the option rd and option dhcpv6 to 'server' and not to 'relay' otherwise this won't work.
The rest looks ok from my perspective.

Still no joy. "ip -6 neigh show" shows the wan gateway to be reachable. However, it's just simply not responding to pings. Anything else I can try?

Thanks.

Edit : Escalated to ISP. Waiting for outcome.

Edit2 : Some slight misconfiguration on ISP part. IPv6 working fine now. Thanks, CyrusFF!

2001:xxxx:xxxx::1 dev eth0.2 lladdr 00:12:xx:xx:xx:6c router REACHABLE

(Last edited by wkweksl on 4 Feb 2013, 10:14)

so I just downloaded and built trunk r35736 and so far I am very impressed how far IPv6 support has come.  PPPoE+DHCP-PD/DHCPv6 work perfectly, as does 6RD, all configurable from LuCI.  wow!  Hats off to the devel community for this progress.

I am wondering however how to shorten the RA lifetimes and DHCPv6 prefix lifetimes on the LAN?  In the case where the wan link does an up-down or temporary loss of connectivity, the prefix is valid for 24hrs yet in the case of a dynamically assigned IP, the 6RD prefix will necessarily change.

I made a few tests and disconnected/reconnected and since the wan up/down does not deprecate the previously assigned prefix, the hosts behind the wrt end up with a whole list of prefixes assigned that are valid for 24 hrs - n*seconds.  It would be nice to know how to shorten the validity of the delegated prefix as well as the frequency of router announcements?

I was using radvd previously to do this, however I see that the current de-facto seems to be 6relayd.  Is it possible to control this as well using 6relayd?

thanks for any help!

This seems like a misconfiguration normally when the native connection or the 6rd-uplink goes down the prefix of the interface that went down is advertised for another 2 hours (validity time 2 hours and counting down) and a preferred lifetime of 0 meaning non-preferred or "do not use any more".

You are correct, the lifetime for the prefixes drops to 120 minutes.

Am i correct in saying that 6relayd does not send router announcements at all and only replies to sollicited RA requests?

I rebuilt my trunk and am using radvd and disabled 6relayd for RAs and SLAAC on the LAN; 6relayd has the advantage of a tiny footprint but I had some devices that seem to misbehave with it need to do more testing.

No, it also sends RAs automatically every 3-10 Minutes if there are no RS from clients.

Maybe the ULA-prefix is the problem?
You could try removing that local prefix in the global-section of /etc/config/network and or in LuCI on the Interface-page.

Also it would be interesting to know which client (Windows, Linux, Mac, iOS, Android, ...) is the problem.

I disabled my radvd and rebooted with 6relayd acting in server-mode for RAs and DHCPv6, I will do more testing and see if I can get back to the state where I had broken connectivity.  It was a iPad device running the latest iOS that according to ip6info software had a valid prefix, yet I was not able to utilize it for whatever reason - it was coming out of sleep when I was doing the testing.

as you suggested I removed the ULA prefix from globals in the configuration as well.

I see from a wireshark capture that there are in fact semi-random RAs being generated.  What is the frequency logic and can it be tweaked?  As well I see there is RDNSS (yay!) that announces the wrt device; is it possible to specify an alternate DNS server?

No specifying a different DNS-server is not yet possible.

The frequency logic is like this:
Send RA in the following cases:
* Just after (re)starting 6relayd
* An address (prefix) was added / removed / changed on the interface.
* The router acquired / lost an IPv6 default route.
* When an RS is received
* After not sending an RA for MinRtrAdvInterval + a random number between 0 and (MaxRtrAdvinterval - MinRtrAdvInterval) seconds

with MaxRtrAdvInterval being 600 and MinRtrAdvInterval being MaxRtrAdvInterval / 3  (RFC 4861 default)
part of that is specified by RFC 4861 and / or RFC 6204.

The MaxRtrAdvInterval, MinRtrAdvInterval and also the DNS-server announced are not yet configurable but I could put this on my ToDo. However I don't see where changing the interval could fix the clients as an RA is sent anyway if an update to the prefix on the interface happens.

I was not saying this was lacking, I only liked the regular RAs that could be configured in radvd for predictability of debugging.  Using a different DNS than the wrt would be nice but the rest if compliant (I have not read the RFCs would be fluff.

I am guessing my issue with the iPad was the ULA and will report anything different should it be the case.  I had also noticed something of a "lag" in terms of obtaining a prefix over a WDS client, I need to investigate that as well.  I obtain one on my windows7 laptop after 60-90 seconds, whereas with my old openwrt + radvd I was getting it as quickly as v4 DHCP.

I would like to re-iterate how glad I am to see 6RD/DHCP-PD configurable via LuCI   thx for the work

I added some new features to 6relayd:
#1 is 6relayd announces ULA-address with a preferred time of 0 if there is a public prefix now
This is enabled by default and can be disable by setting option compat_ula 0 in the UCI-file.

#2 is the option rewrite_dns_addr which allows you to override the announced DNS-server.
Those are only avaiable in the config file for now. I'll write a patch for LuCI some time later.

I also just ordered a new router and I will try to test with my iPod touch later and see how that thing behaves.

And yeah also it was finally time to add proper IPv6 support to OpenWrt.

(Last edited by CyrusFF on 26 Feb 2013, 14:06)

Hello,

I'm running BB r35770 using the new ipv6 code - which worked basically perfectly from fresh build of BB. I'm connected via Comcast, and have a /128 address on the public interface of my router, and a /64 for my internal network. Works fine, routes fine. Folks on my primary network have fast, stable ipv6. Thanks!

Question: I have guest network set up more or less as described here: https://dev.openwrt.org/ticket/4108. I'd like to propagate ipv6 to the guest interface. Is there a way to do this using the new ipv6 setup? What I had done so far is to enable the guest network as a service interface under "IPv6 RA and DHCPv6". I then select /64 for the IPv6 assignment length in the guest interface ivp6 setting. I now have a /64 from the ULA-Prefix on the guest network. But, not sure how to break up my /64 and get a piece of public ivp6 on the get network as well as the lan network.

My suspicion is that both my lan and guest interfaces should be set to /66 subnets of the assigned public /64. I can't set that in the UI, and I'm an ipv6 novice, so am not sure.

B

hello,

using anything shorter than a /64 will break IPv6 autoconfiguration and pretty much everything else - Comcast is only giving you a /64 and thats it?  Ideally you want a /64 for every interface

doing a svn up now!

According to this:

http://forums.comcast.com/t5/Home-Netwo … -p/1414909

A Comcast employee said: We allocate a /64 by default, if your router supports shorter prefixes it needs to send us a hint per RFC3633.  We will allocate up to a /60 today.  We have plans on tap for 2013 to change the defaults.

I tried changing the setting in network that I think hints that I want a /60:

config interface 'wan6'
    option proto 'dhcpv6'
    option ifname '@wan'
    option reqprefix '60'
   
But I'm still getting a /64. Not sure if I'm setting this correctly or not.

B

That setting is indeed what you need and setting it to a specific value sends out hints as specified in RFC3633. So its probably your ISP not complying with the hint. Maybe you could try with 62 or 63 and see what happens. Otherwise you have to talk to Comcast.

Hello, continue with post in another thread:

No, I didn't see anything related with 6relayd in /tmp except the pid file in /tmp/run. Do I need to check that after I restart the network script but before I manually start 6relayed? (Currently I can't test that. Need the network).

No I just wanted to make sure that it did not crash unexpectedly.
I'm not sure at the moment what happens there. It is ok if it disappears for a few seconds a new process comes up. If it doesn't there might be something wrong. Do you see anything unusual in the log?

Searching "6relayd" in the system log showed those:
Feb 28 21:21:12 WYWNDR3700 daemon.warn 6relayd[28256]: Termination requested by signal.
Feb 28 21:21:12 WYWNDR3700 daemon.warn 6relayd[28256]: Failed to relay to ff02::1%br-lan (Network is unreachable)
Feb 28 21:21:12 WYWNDR3700 daemon.err 6relayd[29406]: Unable to open interface wan6 (No such device)

Interesting can you show me your /etc/config/network and /etc/config/6relayd?

Sure.
/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 interface 'lan'
        option type 'bridge'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '192.168.51.1'
        option ifname 'eth0'
        option ip6assign '64'

config interface 'wan'
        option auto '1'
        option ifname 'eth1'
        option defaultroute '1'
        option proto 'pppoe'
        option keepalive '10'
        option demand '0'
        option peerdns '0'
        option username 'username'
        option password 'password'
        option ipv6 '1'

config interface 'henet'
        option proto '6in4'
        option wan_device 'wan'
        option peeraddr 'xx.xx.xx.xx'
        option tunnelid 'id'
        option username 'name'
        option password 'xxxxxxx'
        option ip6addr 'xxxxxxxxxxxx'
        option ip6prefix 'xxxxxxxxxxxxx'
        option mtu '1472'

config switch
        option enable '1'
        option name 'rtl8366s'
        option reset '1'
        option enable_vlan '1'
        option blinkrate '2'
        option max_length '3'

config switch_vlan
        option device 'rtl8366s'
        option vlan '1'
        option ports '0 1 2 3 5'

config switch_port
        option device 'rtl8366s'
        option port '1'
        option led '6'

config switch_port
        option device 'rtl8366s'
        option port '2'
        option led '9'

/etc/config/6relayd:

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

I just realized that I forgot to delete "option ipv6 '1'" from wan interface after the latest firmware update, could that possibly be the reason?

Oh, seems the "option master wan6" be the culprit (never noticed that before)?

Yeah can you either rename your "henet" to "wan6" in /etc/config/network or your "wan6" to "henet" in /etc/config/6relayd and retry?