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.

CyrusFF wrote:

Yes, both addresses will be announced by 6relayd plus a default route.

Is it possible to configure 6relayd to pick just one prefix or a specific prefix pattern?

Unfortunately this is not supported yet. All prefixes present on the specific interface are announced.
PS: However I will probably add prefix-class support sooner or later so you can tag prefixes from different uplinks and choose to assign them to selected downstream interfaces only.

(Last edited by CyrusFF on 30 May 2013, 10:37)

@cyrus:
My machine does have an address in the ULA range, but only via SLAAC. It doesn't have one via DHCPv6. I'm not entirely sure how the DHCPv6 client works on OS X 10.8. A quick packet capture shows:

1. both subnets are advertised in the DHCPv6 advertise message

2. OS X sends a DHCPv6 request for only the globally routable prefix

3. 6relayd sends DHCPv6 reply, but it includes both prefixes. Only one was requested, so its unclear why its sending both back?

So, there's a few questions:
1. What does the RFC say about requesting IP addresses in a DHCPv6 request when two or more prefixes are advertised. I'm not sure, I'd need to go look.

2. Why is 6relayd replying with both prefixes when only one is requested?

3. Maybe it would be prudent to only have 6reladyd report in LuCI those addresses that were actually requested, rather than the ones offered?

Thoughts?

@adam2104: Basically anything the clients sends in DHCPv6 is only a hint to the server and can be silently ignored.
A client can also send a completely empty request and expect to get addresses so using the requested address as a base for anything is not a good idea. The client should accept that the server offers more than one address to it like it does for SLAAC.

Whether DHCPv6 is requested or not is not triggered by the availability of any addresses via SLAAC but using a flag in the router advertisement so it's not really related.

I'm not entirely sure how to deal with this yet. It just confirms once again that doing stateful-only is not a good idea. wink
I will probably sort the announced addresses so that global addresses are always in front of ULAs and also that addresses with a bigger preferred lifetime are in front of those with a lower one.

About the hosts-file its maybe best to only add the first address to it. But the lease-view in general could stay as it is I guess. I mean the address is assigned to the client in the end, the client is just ignorant wink

I just pushed some new updates. There is a new list-option ip6class which lets you define which prefixes will be assigned to an interface. The default class of a prefix is the name of its originating interface (e.g. wan6). Thus if I want my lan interface to only get a prefix from wan6 but e.g. not the ULA (which has the class: local) I can set "list ip6class wan6" in my lan interface-section. This make sense if you have multiple uplinks.


@phuque99: See above. This is probably helpful to you.
@adam2104: I changed the behaviour now to what I said in my last post. Only the first address - hostname pair is added to the hosts-file. Also the DHCPv6-server now sorts addresses so that global addresses are now always on the first position.

@cyrusFF:
Sounds good. I'll build a fresh image tonight and give it a try to see what happens.

EDIT:
Follow up question. If I don't supply the ip6class, what's the default behavior?

(Last edited by adam2104 on 30 May 2013, 20:40)

@CyrusFF


Edit: previous issue was resolved when router was rebooted with proper settings on each configuration file. I confirm that 'list ip6class wan6' on "lan" will tell 6relayd advertise only the wan6 prefix. I believe you do this by making sure that the "lan" interface acquires only the wan6 prefix.

However this presents another problem for my own setup. I'm trying to use both HE's v6 and ISP's dynamic v6 on the lan wired interface. But I only want to advertise the ISP's v6 on lan for PC/Mac clients, while "servers" continue to use HE's v6 addresses. Is this something that can be easily done?

(Last edited by phuque99 on 31 May 2013, 08:39)

You'd have to setup a VLAN and connect the servers to that, then set it to only apply the HE addresses to that "interface" and ISP addresses to the normal LAN one (Why would you want to do that btw? does your ISP blocks ports or something?)

I've also got a question actually, what's the reasoning behind setting ip6assign to 60 by default for PD? It's more than enough for my setup (but less than what my ISP provides), but I'm just interested in why it's that value and not something else.

And more of a general question, I've been having this issue where my Windows 8 box refuses to configure DNS information via DHCPv6 (Since it doesn't support RDNSS), while a Windows 7 machine has no issue with it. I've seen a post on HE's forum about the similar issue, but I don't know how widespread it is.

The_Decryptor wrote:

You'd have to setup a VLAN and connect the servers to that, then set it to only apply the HE addresses to that "interface" and ISP addresses to the normal LAN one (Why would you want to do that btw? does your ISP blocks ports or something?)

Thanks, I figured that's the way and the servers are using the first 2 network port interface. I'm trying to look that up on how to do it properly. Why I'm doing that is HE offers static IP and my very unwise ISP offers dynamic v6 that changes all the time.

adam2104 wrote:

Follow up question. If I don't supply the ip6class, what's the default behavior?

All prefixes attached to the interface will be advertised.

(Last edited by phuque99 on 31 May 2013, 09:35)

@adam2104: The default behaviour stays at it was. If you don't provide ip6class then all prefixes will be assigned to your lan-interface.

@phuque99: I guess separating the traffic via VLANs would be the cleanest way to do this. Also regarding your ISP: It's a matter of perspective. From a privacy point of view changing prefixes are a good thing otherwise you could be tracked very easily.

@The_Decryptor: Well there is no real reason for /60 over anything else, its just 1 nibble / hexchar. However you can easily change it if you like.

Regarding the Windows issue: I think it doesn't support receving DNS-information via RA (RFC 6106). It should however support getting DNS via DHCPv6 (stateless or stateful) that was supported since Vista I think. I'll try to get a Windows 8 and test it against 6relayd to see what happens. Do you have any more information about the issue (maybe some packet dumps of the DHCPv6-exchange and the RAs?)

CyrusFF wrote:

I guess separating the traffic via VLANs would be the cleanest way to do this. Also regarding your ISP: It's a matter of perspective. From a privacy point of view changing prefixes are a good thing otherwise you could be tracked very easily.

If you have a NAS that you want to access via IPv6, wouldn't that be a problem for internal clients if the IPv6 is constantly changing?

Ahh, dynamic prefix, ouch.

@CyrusFF Right, I was wondering if there was some RFC or something somewhere that said 60 was the "right thing to do" when it comes to CPE devices.

And yeah, Windows doesn't support getting DNS information via RA messages, only via DHCPv6. It works fine with Windows 7 but with Windows 8 the information never seems to be applied. I've got a packet trace showing the Win8 box sending some RS messages and getting RAs back, as well as the DHCPv6 solicit/advertise messages, they show the server is sending the correct info to the client, so it looks like it's just a issue with 8.

I can send the traces, they're just loaded with a bunch of extra traffic that's noise so I'd have to strip that first.

traces would be nice. i guess just setting a filter in wireshark of "dhcpv6" and copying the related packages will do.
i will also try to snatch my gf's windows 8 tablet for some experiments this weekend and see if i can reproduce anything.

I found out how to remove all the noise (taking a 70MB trace down to 16KB), so I just sent you a link to it.

Under my win8 I have no RA from server. I only see solicit on ff02 :: 1:2 by NAS.
This may be because I'm in relay mode.

(Last edited by Manani on 31 May 2013, 15:58)

@The_Decrpytor: thanks. It seems both Windows and 6relayd behave strangely here. what the hell?!
Windows - although receiving no M-flag in the RA - tries to do stateful DHCPv6.
6relayd - although having prefixes configured (and sending them in the RA) claims it doesn't have any addresses available.

I'm confused to say the least wink
Edit:
Aah  I have a clue. Which revision of OpenWrt or 6relayd are you using?
Judging from the contents of the RA it is an older version. Can you try with the latest trunk or AA-revision. This should be handled more gracefully now and 6relayd should give out addresses to Windows anyway.

(Last edited by CyrusFF on 31 May 2013, 13:24)

Is it fair if I say that in 6rd permanent leases can not be established? Since the router has no control over the IPv6 traffic.

But can we have an Active DHCP Leases file, as in IPv4?

@CyrusFF

Sorry that I'm bothering you with another 6relayd problem. I'm facing this weird issue with Mac and RA from 6relayd. The machine gets the proper v6 and configures the correct gateway. But when any v6 connection is attempted, it'll timeout and "no route to host". And I see that the default gateway disappeared from Mac's routing table (using netstat -nr).

I don't see this problem with radvd. When I compared the RA packets with tcpdump, I see that 6relayd sent an addtional unknown option. I'm not sure if that's messing with Mac computers, but do you know what's that additional unknown option field?


6relayd RA output:

12:27:25.583077 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 104) fe80::2cb0:5dff:fe9c:a577 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 104
        hop limit 0, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
          source link-address option (1), length 8 (1): 3b:47:5a:7c:b5:47
            0x0000:  3b47 5a7c b547
          mtu option (5), length 8 (1):  1500
            0x0000:  0000 0000 05dc
          prefix info option (3), length 32 (4): 2401:ff00:c800:b05d::/64, Flags [onlink, auto], valid time 7200s, pref. time 1800s
            0x0000:  40c0 0000 1c20 0000 0708 0000 0000 2401
            0x0010:  ff00 c800 b05d 0000 0000 0000 0000
          unknown option (24), length 16 (2): 
            0x0000:  4000 0000 1c20 2401 7400 c800 b05d
          rdnss option (25), length 24 (3):  lifetime 1800s, addr: 2401:ff00:c800:b05d::1
            0x0000:  0000 0000 0708 2401 ff00 c800 b05d 0000
            0x0010:  0000 0000 0001

radvd RA output:

 12:17:33.921755 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 88) fe80::2cb0:5dff:fe9c:a577 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 88
        hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2401:ff00:c800:b043::1/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
            0x0000:  40c0 0001 5180 0000 3840 0000 0000 2401
            0x0010:  ff00 c800 b043 0000 0000 0000 0001
          rdnss option (25), length 24 (3):  lifetime 600s, addr: fe80::2cb0:5dff:fe9c:a577
            0x0000:  0000 0000 0258 fe80 0000 0000 0000 2cb0
            0x0010:  5dff fe9c a577
          mtu option (5), length 8 (1):  1480
            0x0000:  0000 0000 05c8
          source link-address option (1), length 8 (1): 3b:47:5a:7c:b5:47
            0x0000:  3b47 5a7c b547

Tha option is called route information and it is required that we sent it along. Although its value seems to be wrong. it should be ff instead of 74 in the data. Anyway that shouldn't be a problem for your case. I'm still not entirely sure what is wrong though. Oh well let's see next week.

@CyrusFF

I upgraded my router to pickup the new version of 6relayd, so now hosts are getting assigned addresses alongside SLAAC addresses, but Windows 8 still isn't using the DNS information (When I first brought up the adapter after upgrading my router it did actually use the v6 DNS info, but it was pretty quickly removed for whatever reason) I recorded a new trace and I'll send you the link.

No host information is getting written out either for dnsmasq to use either, but considering the state of DHCPv6 in clients I'm not that surprised. Windows 8 seems to be asking for an address, but then never assigns it to the interface, while OS X does, etc.

Thanks. I figured out whats wrong now. Apparently my workaround for iOS (announcing the ULA-prefix as deprecated) broke Windows. This should be fixed now.

Excellent, I disabled the ULA deprecation on my current install and straight away both my Windows 7 and Windows 8 machines started using the DHCPv6 allocated address, the provided DNS information and had their hostname added to the hosts file on the router. Seems Windows 7 is a bit more flexible in that regard (Using DNS), while 8 just rejected it.

Hello The-Decryptor: how do you do that? Just by erasin "fd72:846f:c93b::/48"?

@The_Decryptor: If you're able to, can you test 6relayd with only RA? I noticed that my Win7, like my Mac, isn't able to route v6 traffic even after obtaining valid v6 prefix and router's local-link address as default route. I didn't face this is issue with radvd. I suspect it could be my dual-v6 link setup.

This is the 6relayd RA-only configuration:

config server default
    #option master    wan6
    option network    lan
    option rd    server
    #option dhcpv6    server
    #option fallback_relay    'rd dhcpv6 ndp'
    #option management_level 2
    option compat_ula 0

@Manani

In the WebUI it's under Network > IPv6 RA and DHCPv6 and the option is called "ULA-preference compatibility"

@phuque99

I can try, but since I've only got one v6 uplink I doubt I'd hit the same problem as you're getting, and it's still announcing both my ISP provided v6 prefix and the ULA prefix anyway. I also don't think DHCPv6 actually provides routing information, that's all handled by RA, so disabling it shouldn't change anything.

Sorry, posts 226 to 225 are missing from our archive.