Messages

Oh ... now it makes all sense why it failed for me when I tested. I only run virtio (disk, network) with Proxmox for better performance. Interesting, thanks for the hint, so I won't have to retry ;-)

Is your solution better? Not a C-Guy anymore, therefore if your patch is cleaner and resolves in the same / similar output, happy to go with it too :)

Good progress! For reference we discussed how to integrate this step by step. Next is the dhcp6c raw options and AFTR changes. It requires a little review of the raw options patch. 18.1.7 moves to our dhcp6c client code so 18.1.8 could see the addition of raw options.

Right, the dhcp6c changes (the original raw-options patch) needs to get in first. Then we need my addition to the raw-options patch (which also needs to be tested, so far all is just hacked down, so I consider it all WIP ;-)). Finally the DS-Lite UI / backend patches can be added :-)

Ok after I'm back from conference work, I took the day off to work a bit on the implementation. I added the option to send the raw-option response to the script which is executed when a dhcp response is received and I added (I guess) most code on the UI / backend side.

https://github.com/opnsense/dhcp6c/pull/1
https://github.com/opnsense/core/pull/2382

That at least helps, since I still have some things I'm not aware how to solve, like how I have to hook myself into the DHCP6 response :) Happy for any hint. Joined the IRC channel!

Sorry for spamming ;-)

Ok I fixed the first bit of the overall issue. I'm now able to create a GIF tunnel with an outer set of IPv6 addresses which is obviously necessary for a 4in6 tunnel. Please find the according pull request: https://github.com/opnsense/core/pull/2341

Next step would be to get additional parameters, like mtu, -raccept_rtadv (or better ifdisabled) into the UI and the controller. You guys are probably way faster to do this :)

And one more question, how can I hook into the dhcp6c events? I need to create/recreate the tunnel when the WAN IPv6 changes (yes in Germany you get crappy "dynamic" prefixes assigned).

Ok coming back to the first issue, you cannot create a GIF tunnel that matches what I expect. I think there's a bug somewhere in the logic to create the tunnel interface related to IPv6 but I can't find it.

In the screenshots gif0 is created manually and you see it has a set of IPv6 tunnel addresses (WAN -> AFTR). I also want to set the MTU value, as 1280 is a nice default but not always the best. Apart from that it'd be great to drop all IPv6 related properties of the inner tunnel.

Anyhow as you can see gif1 is what is created. It seems to miss the IPv6 addresses of the endpoints. Maybe I'm just reading it wrong? Otherwise any idea where to look to fix it?

Perfectly agree. RFCs are a PITA.

I still think, on the other hand, there's an issue in creating an IPv4 over IPv6 tunnel from the UI. I expect if I choose WAN as the parent interface, put the AFTR address into the remote addsn'tress field and give the local and remote endpoint according to the spec to end up with the same result as my initial commands (see above). Anyhow this doesn't happen. Not sure what is configured wrong, but the tunnel doesn't work.

Right but to be on the save side, if you want the provider to send an AFTR it's better to include option 64 into your request :-)

Well but that is the response from the providers DHCPv6 server. I need to send request option 64 to make them send it to me.

Maybe I wasn't clear enough, I want to use the dhcp6 client to retrieve the AFTR value for my own firewall to connect to the AFTR (IP4 over IP6 tunnel), I don't want to host my own DHCPv6 server :-)

So the main question is how do I send an empty option 64? Probably just raw-opion 64 00.
And how do I receive / transform an answer to this option, since it needs to be sent to a script and needs to be decoded (hex->ascii).

Anyways, thanks guys! Great help, appreciated! We're getting there! :)

Thanks for the help. I'm not yet 100% sure how the raw option works (from looking at the patch), but I guess it'll work since the AFTR discovery is just sending an additional identifier (option 64) and reading the dns name, which is a simple text value.

I still wonder for the other bit of the original question though, I can't make an 4in6 (IPIP6) tunnel through the web interface. I bet I'm just doing it wrong but I wonder if somebody has an idea from looking at the commands.

I got ahead with this after a quick discussion on Twitter yesterday (https://twitter.com/noctarius2k/status/980506277536305152) and started to work on a patch for the currently used wide-dhcpv6 to support retrieving the AFTR name from the provider's DHCPv6 server. The current status of the patch can be seen here: https://github.com/noctarius/wide-dhcpv6/commit/11a10644db7724d7747dc8ec31751cf64e2d5826

My last bit of coding with C is quite a while back, therefore it'd be interesting if I missed any major point in the patch.

For a bit more information on DS-Lite, CGN and the AFTR please see the following RFC:
Dual-Stack Lite and CGN: https://tools.ietf.org/html/rfc6333
AFTR name from DHCPv6: https://tools.ietf.org/html/rfc7870

Hey guys,

Currently trying to get DS-Lite to work. DS-Lite is a IPv6 transition mechanism widely deployed in Europe by cable providers such as Liberty Global (like UPC, Unitymedia, ...), like Vodafone, Kabel Deutschland and others.

I can set up the necessary tunnel (in Linux it is the ipip6 protocol) which transports the IPv4 packets via an established IPv6 tunneling over to a so-called AFTR (carrier grade NAT system) to transition users from their native IPv6 home connections to the IPv4 world. Multiple users share a single external IPv4 address using this system.

Unfortunately I have two issues:
1. the provided dhcp6c doesn't provide the option #64 (AFTR-NAME), which provides the address of the carriers AFTR (NAT) server
2. I can setup the necessary IP tunnel via command line, but I fail to make it work using the UI (I'm probably just missing something)

To fix the first problem, I wonder if it would be possible to exchange the wide-dhcp6 (KANE) with the openwrt DHCPv6 client (odhcp6c, https://github.com/openwrt/odhcp6c) which already supports the necessary bits for discovery of the AFTR and providing it as environment usable variables.

For the second issue, below is the commands that need to run to make a tunnel usable for the AFTR and a route to transmit IPv4 through the tunnel.

ifconfig gif0 create
ifconfig gif0 inet6 tunnel <<WAN_IPV6> <<AFTR_IPV6>> mtu 1280 -accept_rtadv
ifconfig gif0 inet 192.0.0.2 192.0.0.1 netmask 255.255.255.248
route add default gw 192.0.0.1

Maybe somebody can help me out on how to set up the above commands from the UI. If I'll go forward and make it a package for opnsense I'd like to add it as an IPv4 option for how to get the IP on the WAN interface (like tracking for IPv6 lan).