OPNsense Forum
English Forums => Development and Code Review => Topic started by: noctarius on April 01, 2018, 08:24:27 pm
-
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).
-
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
-
The RAW Option support will add any option so that should be OK, it will require ASCII to Hex etc for you to create the option, but there are just too many variables and options to create separate options.
@noctarius - Have a look at the Opnsense dhcp6c port and see if you can add what you want to that, or I can do it with you when I get a little time, but it might be several weeks away.
-
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've asked @nivek1612 to write some info on the use of RAW options. I did not create all that, it was originally done by a genius in France, I just ported it over to FreeBSD dhcp6c and our ports. It works, as they are using it in France, but exactly what you need to do to use it, I'll leave for @nivek1612 to explain. From memory, you need to specify the Option, then the string... all in HEX!
I did write some putty about it on the FreeBSD port commit.
-
Ok so the RAW options are easy to use
Here are the examples of some I need to specify to establish a connection to ORANGE in France. Simply convert the ASCII to HEX.
Key is knowing what ASCII the DHCP6 Server is expecting
I figured that out by simply doing a Wireshark trace of the ORANGE supplied router
It told me I needed options 11, 15 and 16 (details below)
"Authentication" which must be the users Orange login (fti / xxxxxx) in hex, preceded by 22 zeros, for example:
raw-option 11 00:00:00:00:00:00:00:00:00:00:00:66:74:69:2f:65:77:74:70:32:FF:68
“User-Class” which must be "+ FSVDSL_livebox.Internet.softathome.Livebox3”
raw-option 15 00:2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:6c:69:76:65:62:6f:78:33
“Vendor Class” which must be “sagem”
raw-option 16 00:00:04:0e:00:05:73:61:67:65:6d
These options can be passed to the dhcp6 server from "send options" separated by "," once DHCPV6 has been selected as the IPv6 connection type
@noctarius
In your case you would calculate you hex string from the ASCII - lets assume it was FF:FF:00:00:FF:FF
Then you would just add the following to the send options field of DHCPv6 client configuration
raw-option 64 FF:FF:00:00:FF:FF, raw-option ......
-
Almost... :)
Have a look at https://tools.ietf.org/html/rfc6334 (https://tools.ietf.org/html/rfc6334)
First figure is correct, 64. Next you need the length, so put 00 in hex, length is auto calculated, then the string. As it's a variable length field that's fine.
So say the AFTR was aftr.example.com, it has to be formatted in a specific way.
Length of each part, without the '.'. then terminated with a 00
So the string part is "04 61 66 74 72 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00"
a f t r e x a m p l e c o m
Put it together and you get
64 00 04 61 66 74 72 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00
At least that's the way I read it.
-
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! :)
-
Hello,
Late to the party. As for our dhcp6c project, I've stripped *all* unused tools and code from the repo, so we can concentrate on the client. No upstream seems to be active so that's a sort of sensible way forward. Every other aspect of DHCPv6 in terms of Server is handled by ISC-DHCP anyway.
(Hijacking this a bit)
The "new" client will likely hit in 18.1.7, coupled with Martin's SIGHUP reload to get rid of zombie processes trashing the IPv6 connectivity for unstable connections.
In 18.1.8 or 18.1.9 we should be ready to pull in the RAW options, but they require a bit more code review.
If we have a working implementation for AFTR, that is ok too to pull in parallel.
Last but not least, Martin and me have been reworking the DHCPv6 interface plumbing extensively, something queued up for 18.1.7 as well. The most prominent change is that the advanced options now work in tandem with the default options for interface tracking, prefixes and such.
For DHCPv6, with 18.7 we should be looking at a finished integration for RAW options in the GUI.
Sounds like a plan?
And a thanks for everyone involved in pushing this onward! :)
Cheers,
Franco
-
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! :)
You know... after I wrote and posted that I went to bed and thought as I was dropping off.. hang on, that may be the response I was looking at. In that case, my bad.... Kev I assume was correct . :)
At least I showed how to do it if it was like that., :)
-
It appears the client may or may not send the FQDN in its request, or even a partial FQDN..
https://tools.ietf.org/id/draft-ietf-dhc-dhcpv6-fqdn-02.txt (https://tools.ietf.org/id/draft-ietf-dhc-dhcpv6-fqdn-02.txt)
-
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 :-)
-
When I get time to play with this I'll start looking at some packet captures and take it from there. RFC docs are generally always a pain to read, especially late at night!
-
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.
-
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?
-
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).
-
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 :)
-
We appreciate all hands for coding. What I can offer is post-code review and pre-code discussion and walk you through it. Easiest way to talk is via Freenode IRC #opnsense.
Cheers,
Franco
-
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!
-
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
-
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.
Cheers,
Franco
-
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 :-)
-
I can either send you my dhcp6c source with the raw options or you can send me your patches and I'll work them in, which do you want to do?
Probably easier if I send you the source as you know what you are looking for on the in/out.
-
It's all here on top of your changes for raw options (extra branch but going to be merged for 18.1.8).
https://github.com/opnsense/dhcp6c/pull/1
Cheers,
Franco
-
Bugger... just spent the last hour adding the raw opts stuff.. ::)
-
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 :)
-
Confused now...
I added my original RAW options to the opnsense/dhcp6c, which is a version of my original PR that added config re-read in SIGHUP and also had all the RAW options stuff. Franco wanted to break it into two parts, first part was the config re-read which is now in 18.1.7 and the RAW options bit was next. However when looking at the source this morning for https://github.com/opnsense/dhcp6c there were no RAW options hence I then re-added them.
@franco - please de-confuse me.
-
Martin, there are two branches in that repo: https://github.com/opnsense/dhcp6c/branches
I assume you saw the commit I added, because you commented on it. ;)
https://github.com/opnsense/dhcp6c/commit/a716d4bfc97
I took this from the ports submission, cleaned up a few whitespace issues only.
SIGHUP is on master *and* shipped with 18.1.7. :)
Cheers,
Franco
-
OK... My brain still appears to be on central american time... 8)
I'll take a look on Monday as it's a public holiday here.
-
OK... @franco is now merging dpinger so I can work on this with @noctarius.
@noctarios - where are you at with dhcp6c?
-
What is the status on Dual Stack Lite support? According to the wiki at https://wiki.opnsense.org/manual/ipv6.html I assume it is still work in progress? Any ETA for full support?
The roadmap at https://opnsense.org/about/road-map/ mentions "Improved IPv6 support" for the release coming in January 2019. Does this maybe include "Dual Stack Lite"?
-
DS-Lite is not part of our code yet. Initial work was done, but has not been finished yet.
We try to make this clear by not misleading people to say "DS-Lite support" anywhere in our roadmap. :)
Cheers,
Franco
-
Thanks for the update. I really like this project and vision. OPNsense is my future firewall / router of choice. I will keep an eye out for this.
DS-Lite seems to be still bleeding edge. I had to retire my "high end" Asus router because of this. In my research I found exactly one (sadly closed-source) router which does fully support DS-Lite today. I could pay extra fees to my ISP to get a full dual stack, but I refuse to pay for legacy tech (IPv4), so DS-Lite it is for me.