Dual Stack Lite (DS-Lite) Support

[noctarius]

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).

[noctarius]

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

[marjohn56]

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.

[noctarius]

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.

[marjohn56]

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.

[nivek1612]

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 ......

[marjohn56]

Almost...

Have a look at 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.

[noctarius]

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!

[franco]

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

[marjohn56]

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.,

[marjohn56]

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

[noctarius]

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 :-)

[marjohn56]

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!

[noctarius]

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.

[noctarius]

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?