DS-Lite Support (WIP) #2382

noctarius · 2018-05-01T20:27:00Z

This is still WIP but I'd like to share it already to get feedback as early as possible, since C is a looooong time back and PHP too (apart from that fact it's not exactly my favorite language ;-)).

This patch series adds support for DS-Lite (https://tools.ietf.org/html/rfc6333) which is one of the most commonly used transition techniques for IPv6-only provider networks but offering IPv4 access for customers using a so-called CNAT (carrier grade NAT). The NAT capability is provided by the provider given an IPIP 4in6 tunnel to a remote endpoint called AFTR.

The AFTR address can either be configured manually or is discovered using DHCPv6 option 64 (using the new raw-option support in dhcp6c, opnsense/dhcp6c#1) as described in https://tools.ietf.org/html/rfc6334.

Looking forward to feedback.

AdSchellevis · 2018-05-02T06:39:22Z

Hi @noctarius,

I would like to see if we can integrate this a little bit more loosely coupled, although I understand that most of the legacy code around dhcp looks a lot similar to this.

Is there some documentation of the steps needed to get this working? We have quite some hooks in place to add custom features, it would be good if we can detach this more.

Thanks for working on this,

Best regards,

Ad

noctarius · 2018-05-02T06:57:58Z

I think all the steps necessary are in the forum https://forum.opnsense.org/index.php?topic=7788.msg35863#msg35863. Anyhow I think it is valid to have it as an option for the IPv4 configuration of the interface. Obviously you need to do quiet a few things in the background, like retrieving the AFTR address via DHCPv6, the creation of a tunnel (and possibly re-creation), setting up the dynamic, default gateway (192.0.0.1) and some more things. I'd refrain from making it too complicated for users to activate / configure, as this is not an easy thing (especially the DHCP part), as well as tunnel configuration stuff.

Happy to jump on a discussion though, hanging out in the IRC ;-)

edit: maybe I misunderstand what you want to have loosely coupled though ;-)

here's a script I'm using so far (with a patch to interfaces.inc to make call it after a dhcp prefix is retrieved):

#!/bin/sh

findCurrentTunnel() {
  gifs=`ifconfig | grep 'gif[0-9]:' | awk '{print $1}' | awk 'gsub("[:]", "")'`
  for gif in $gifs; do
    echo -n "Searching $gif... " >> /var/log/dhcp6c.log
    aftr=`ifconfig $gif | grep inet6 | grep '\-\->' | awk '{print $5}'`
    echo "$aftr" >> /var/log/dhcp6c.log

    if [ "$aftr" == "$1" ]; then
      echo $gif
      return 0
    fi
  done
  return 1
}

findAvailableGif() {
  gifs=`ifconfig | grep 'gif[0-9]:' | awk '{print $1}' | awk 'gsub("gif|:", "")'`
  for i in `seq 0 100 1`; do
    for o in $gifs; do
      if [ $i -eq $o ]; then
        continue
      fi

      echo "gif$i"
      return 0
    done
  done
  echo "gif0"
  return 0
}

AFTR="2a02:908::13:4000"
WANIP6=`ifconfig $1 | grep inet6 | grep 'prefixlen 128' | awk '{print $2}'`

if [ -f /tmp/dslite.dat ]; then
  OLDWANIP6=`cat /tmp/dslite.dat`
  echo "Found old WAN IPv6: $OLDWANIP6" >> /var/log/dhcp6c.log
fi

echo "Current WAN IPv6: $WANIP6" >> /var/log/dhcp6c.log

gif=$(findCurrentTunnel "$AFTR")
if [ $? -eq 0 ]; then
  if [ "$OLDWANIP6" == "$WANIP6" ]; then
    # just received new DHCP6 lease, IPv6 and probably prefix stayed the same, preventing tunnel from recreation
    echo "No new IPv6 received, skipping tunnel recreation." >> /var/log/dhcp6c.log
    return 0
  fi

  echo -n "Found old DS-Lite tunnel $gif, destroying... " >> /var/log/dhcp6c.log
  ifconfig $gif destroy
  echo "done." >> /var/log/dhcp6c.log
fi

gif=$(findAvailableGif)
if [ ! $? -eq 0 ]; then
  echo "No available GIF interface number found..." >> /var/log/dhcp6c.log
  return 1
fi
echo -n "Creating DS-Lite tunnel with $gif... " >> /var/log/dhcp6c.log
ifconfig $gif create
ifconfig $gif inet6 tunnel $WANIP6 $AFTR mtu 1460 -accept_rtadv ifdisabled
ifconfig $gif inet 192.0.0.2 192.0.0.1 netmask 255.255.255.248
echo "done." >> /var/log/dhcp6c.log

echo -n "Setting up default route for IPv4 to tunnel... " >> /var/log/dhcp6c.log
#route add default -interface $gif > /dev/null
route add default 192.0.0.1
echo "done." >> /var/log/dhcp6c.log

echo "$WANIP6" > /tmp/dslite.dat

noctarius · 2018-05-02T07:11:49Z

Here is a bit more of a timeline description:
-> dhcp6c sends an assignment request, includes dhcp6-option 64 (AFTR DNS name)
-> DHCPv6 assignes IPv6 (and a prefix, optional obviously)
-> extract AFTR DNS name from response (if available)
-> see if AFTR is overridden manually (see ui code)
-> if AFTR is not an IPv6 but DNS name, resolve DNS to address
-> create IPIP tunnel (4in6) with public wan IPv6 -> AFTR address
-> configure inner IPs local 192.0.0.2, remote 192.0.0.1 (see DS-Lite spec)
-> set default route IPv4 to 192.0.0.1
-> monitor 192.0.0.1 in case the tunnel crashes and recreate tunnel (not yet implemented, looking for the hook from the monitoring service)

Tbh I don't think there is too much option since I actually need the response from DHCPv6 (using the new raw-option patch) to find an AFTR. I guess I'd be able to use the newwanip hook but I have to make sure the tunnel is created before the default gateway is set, since it'll fail otherwise (since 192.0.0.1 won't be available yet).

As said, happy for any hint to make it nicer, but I doubt there's too much option, especially in the UI, I really really want it to be an option for IPv4 on WAN, everything else is too complicated / unintuitive :-)

fichtner

first thoughts... nice work so far, thanks!

fichtner · 2018-05-02T12:16:39Z

src/www/interfaces.php

@@ -2466,7 +2545,7 @@ function toggle_allcfg() {
                          </td>
                        </tr>
                        <tr class="dhcpv6_basic">
-                          <td><a id="help_for_dhcp6prefixonly" href="#" class="showhelp"><i class="fa fa-info-circle"></i></a> <?=gettext("Request only a IPv6 prefix"); ?></td>
+                          <td><a id="help_for_dhcp6prefixonly" href="#" class="showhelp"><i class="fa fa-info-circle"></i></a> <?=gettext("Request only an IPv6 prefix"); ?></td>


probably best merged in a different PR

I just saw it, the reason it is a separate commit, easy to extract and merge before ;)

very forward-thinking... cherry-picked via 932038d

fichtner · 2018-05-02T12:19:21Z

src/www/status_interfaces.php

@@ -275,12 +275,28 @@
                  endif;
                if ($ifinfo['status'] != "down"):
                  if ($ifinfo['dhcplink'] != "down" && $ifinfo['pppoelink'] != "down" && $ifinfo['pptplink'] != "down"):
-                    if ($ifinfo['ipaddr']):?>
+                    if ($ifinfo['ipaddr']):


should split this up as well, not sure if this is the best approach to add conditionals where none existed before

fichtner · 2018-05-02T12:19:40Z

src/www/widgets/widgets/interface_list.widget.php

@@ -127,7 +127,13 @@ function interface_widget_update(sender, data)
          <?=empty($ifinfo['media']) ? htmlspecialchars($ifinfo['cell_mode']) : htmlspecialchars($ifinfo['media']);?>
        </td>
        <td>
-          <?=htmlspecialchars($ifinfo['ipaddr']);?>
+          <? if ($ifinfo['ipaddr'] == "dslite") {


fichtner · 2018-05-02T12:21:31Z

src/etc/inc/interfaces.inc

+        if (is_dslite_enabled($ifdescr)) {
+            $gifif = dslite_find_tunnel_interface($ifdescr);
+            $aftr = dslite_find_aftr_address($ifdescr);
+            $ifinfo['ipaddr'] = 'dslite';


the tunnel does not have a local ipv4 tunnel address?

It is always 192.0.0.2 -> 192.0.0.1 as per spec, therefore the ip doesn't really make sense to be shown. You share a public IPv4 with multiple customers using the AFTR CNATing.

fichtner · 2018-05-02T12:23:23Z

src/etc/rc.newwanipv6

+// If on DS-Lite, try to find a valid / usable AFTR address (either from DHCPv6 or manually configured)
+if (is_dslite_enabled($interface)) {
+    // Try to read dhcp option 64 (AFTR name) from the environment
+    $aftr_addr = trim(getenv("raw_dhcp_option_64"));


very cool solution :)

I just extended the raw option patch which is already around ;-)

fichtner · 2018-05-02T12:28:00Z

src/etc/inc/dslite.inc

+
+require_once("interfaces.inc");
+require_once("util.inc");
+require_once("system.inc");


cyclic dependencies

ok for merge, but it would be less confusing to move these into interfaces.inc and use a consistent interfaces_dslite_ prefix

Sure can do, wasn't quite sure since few things (like gateway stuff) has its own files, others don't.

fichtner · 2018-05-02T12:29:09Z

src/etc/inc/dslite.inc

+        log_error(sprintf("Starting DS-Lite tunnel with AFTR '%s' on interface %s with external IP '%s'", $aftr, $parent, $ip));
+    }
+
+    $gifif = legacy_interface_create('gif');


this generates a gif interface with an arbitrary index. better rename the interface to be able to guess the name later when we need it, e.g. dslite_wan

Which is ok, I save the gif name into the state file, as with multiple wan interfaces you might have multiple dslite tunnels ;-)

no, wan is the unique internal identifier... the others are lan and opt0 - opn(n-1)

between saving state to a file and avoiding it it's always better to avoid if possible

fair enough, but there's no "wan" anywhere hardcoded ;-) it'll just work with any $interface :D

it's $parent here as fas as I can see

oh right, for any $parent 👍

what I could do is build something like "parentname_dslite", whatya think?

I'd lead with dslite_ to make it easier to spot (like a "driver" name), but both are fine, since we don't need to track them in the config.xml and can always modify later if needed :)

fichtner · 2018-05-02T13:03:03Z

src/etc/inc/interfaces.inc

@@ -2357,6 +2357,87 @@ function interface_virtual_create($interface)
    }
 }

+function interface_dslite_configure($verbose, $parent = 'wan', $aftr)


your copyrights to the file, obviously

AdSchellevis · 2018-05-02T16:10:36Z

src/etc/inc/interfaces.inc

+    $gifif = legacy_interface_create('gif', "{$parent}_dslite");
+
+    $pmtu = '';
+    if (!empty($mtu)) {


better to move/check !empty($config['interfaces'][$parent]['dslite_tunnel_mtu']) over here and use it when not empty, in the sprintf(), so the $wanconfig and $mtu can be dropped.

AdSchellevis · 2018-05-02T16:16:37Z

src/etc/inc/interfaces.inc

+    $gifif = legacy_interface_create('gif', "{$parent}_dslite");
+
+    $pmtu = '';
+    if (!empty($mtu)) {


better to check !empty($config['interfaces'][$parent]['dslite_tunnel_mtu']) over here and use the contents in the sprintf() when that's the case. $wanconfig and $mtu can be dropped then

AdSchellevis · 2018-05-02T16:24:34Z

src/etc/inc/interfaces.inc

+    @file_put_contents($dslite_tunnel_file, $gifif);
+
+    $dslite_aftr_file = sprintf("/tmp/dslite_%s_aftr.state", $parent);
+    @file_put_contents($dslite_aftr_file, $aftr);


out of curiosity, can't we read the aftr tag back from ifconfig? It's usually a bit more resilient to check ifconfig directly then to use temporary files. If I understand the workflow correctly, the gif interface should always have a predictable name now, so if it's there, we can validate it. right?

It should be possible to read it back from ifconfig as long as there is a connection. If the tunnel drops for any reason I'm not sure the AFTR address would still be readable. I think a safe fallback would be to try to read it from ifconfig and if not available recreate the tunnel using the AFTR address in the file. Not everything I want to implement is done yet, for example tunnel monitoring and possibly recreating it :)

Is there any way we can check if the address is and stays in ifconfig? If it does, I can add the option to legacy_interfaces_details() so we can always stick to the interface and prevent files from getting async.

Not sure, my AFTR connection seems to be pretty stable. Normally when a reconnection (in the Fritzbox) happens you get a new external IP address (which is still shared by multiple people but is "new" to you). I didn't have this situation yet, at least not that I realized. I think setting up the gateway monitoring (for 192.0.0.1) might give some hint if we actually need to recreate the interface at any time. Whenever I apply changes to the/a wan interface, I should get a new DHCPv6 request, shouldn't I?

I would expect so, yes. If you can send me an example ifconfig -m output of the interface, I can see if we can fit the aftr tag in legacy_interfaces_details() so you can fetch it from there. Saves temp files :)

Sure thing nothing easier than that, however I'd imagine it is already available, since the 4in6 is most probably just a gif tunnel :-)

Anyhow here it is:

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1460 options=80000<LINKSTATE> capabilities=80000<LINKSTATE> tunnel inet6 2a02:908::b863 --> 2a02:908::13:4000 inet 192.0.0.2 --> 192.0.0.1 netmask 0xfffffff8 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> groups: gif

Just changed a few bits in my IPv6 ;-) and the 2a02:908::13:4000 is the AFTR address in my case. I guess you might not be able to reach / ping that address though. As far as I know, it's only reachable from the inside of the Unitymedia network.

ok, the tunnel wasn't parsed yet, with 0ac2af1 you can easily extract it from legacy_interfaces_details()

[tunnel] => Array ( [proto] => inet6 [src_addr] => 2a02:908:0000:0000:0000:0000:b863 [dest_addr] => 2a02:908::13:4000 )

AdSchellevis · 2018-05-02T16:32:48Z

src/etc/inc/interfaces.inc

+    @unlink($dslite_aftr_file);
+}
+
+function interface_dslite_find_tunnel_interface($parent)


If the interface is static, it's probably better to ditch this and refer to the static value.

AdSchellevis · 2018-05-02T16:35:32Z

src/etc/inc/interfaces.inc

+    }
+
+    $gifif = interface_dslite_find_tunnel_interface($parent);
+    if (!empty($gifif)) {


could probably check for existence of the interface using !empty(legacy_interfaces_details("{$parent}_dslite"))

After ditching find_tunnel, doesn't it make more sense to do a if (does_interface_exist($gifif)) { ?

you're probably right, both do an ifconfig call.

AdSchellevis · 2018-05-02T16:41:42Z

src/etc/rc.newwanipv6

+        log_error("Got AFTR from DHCPv6 response: {$aftr_addr}");
+    }
+
+    if (!empty(trim($config['interfaces'][$interface]['dslite_aftr_addr']))) {


if dslite_aftr_addr takes precedence over getenv("raw_dhcp_option_64") it's better to make it explicit in the call flow. if dslite_aftr_addr then use this, else something like.

$aftr_addr = !empty(trim(getenv("raw_dhcp_option_64"))) ? pack("H*", trim(getenv("raw_dhcp_option_64"))) : null;

I actually think it's pretty ugly to use the same code over and over again like the getenv( .... ) but well, you asked for it. Wait for typos :D

AdSchellevis · 2018-05-02T16:50:31Z

@noctarius I missed the forum posting, but thanks for explaining. Your point is clear about intuitiveness, we should indeed try to integrate it in the interface settings. I left some remarks in the code which might help to simplify things a bit further.

noctarius · 2018-05-02T17:00:07Z

You're welcome.

I'm using the very hacky shellscript for now which works™ ;-) But I'd be better in the system as more and more people will have the DS-Lite setup. Especially with the freedom of selecting your own modem/router/hardware in Germany (Europe?!?). Fritzboxen shouldn't be the only ones (apart from the hacky implementation in openwrt) to support DS-Lite :D

noctarius · 2018-05-02T17:03:27Z

PS: this all depends on the new raw-option patch for dhcp6c, just to remember :)

fichtner · 2018-05-03T06:18:26Z

src/etc/inc/gwlb.inc

@@ -5,6 +5,7 @@
    Copyright (C) 2008 Bill Marquette <bill.marquette@gmail.com>
    Copyright (C) 2008 Seth Mos <seth.mos@dds.nl>
    Copyright (C) 2010 Ermal Luçi
+    Copyright (C) 2018 Christoph Engelbert <me@noctarius.com>


I don't agree with this one as a means of substantial copyrightable changes. interfaces.inc and interfaces.php are ok though because I expected that copyright to merely shift from dslite.inc to interfaces.inc when asking for the merge and noting now the copyright was missing.

fichtner · 2018-05-03T06:19:27Z

src/etc/inc/interfaces.inc

+
+    $mtu = '';
+    if (!empty($config['interfaces'][$parent]['dslite_tunnel_mtu'])) {
+        $mtu = sprintf('mtu %s', $config['interfaces'][$parent]['dslite_tunnel_mtu']);


This should be:

$mtu = exec_safe('mtu %s ', $config['interfaces'][$parent]['dslite_tunnel_mtu']);

fichtner · 2018-05-03T06:20:44Z

src/etc/inc/interfaces.inc

+        $mtu = sprintf('mtu %s', $config['interfaces'][$parent]['dslite_tunnel_mtu']);
+    }
+
+    mwexecf('/sbin/ifconfig %s inet6 tunnel %s %s %s -accept_rtadv ifdisabled', array($gifif, $ip, $aftr, $mtu));


here $mtu will be escaped as a word instead of two parsable arguments for ifconfig, so that doesn't work. Use this instead:

mwexecf("/sbin/ifconfig %s inet6 tunnel %s %s {$mtu} -accept_rtadv ifdisabled", array($gifif, $ip, $aftr));

(cherry picked from commit 0ac2af1)

…face

…l as adding a dynamic gateway

…s widget and page.

…ed DHCPv6 AFTR option response back to a string. Related commit for dhcp6c is noctarius/dhcp6c@d3d0585

fichtner · 2019-10-07T16:57:32Z

Lots of conflicts after over a year, need to redo this.

fichtner reviewed May 2, 2018

View reviewed changes

fichtner self-assigned this May 2, 2018

fichtner reviewed May 2, 2018

View reviewed changes

AdSchellevis reviewed May 2, 2018

View reviewed changes

fichtner reviewed May 3, 2018

View reviewed changes

AdSchellevis added a commit that referenced this pull request May 5, 2018

lib/interfaces, parse ifconfig tunnel data for #2382

0ac2af1

fichtner pushed a commit that referenced this pull request May 5, 2018

lib/interfaces, parse ifconfig tunnel data for #2382

8f881a4

(cherry picked from commit 0ac2af1)

AdSchellevis added a commit to OPNids/core that referenced this pull request May 30, 2018

lib/interfaces, parse ifconfig tunnel data for opnsense/core#2382

82ac621

(cherry picked from commit 0ac2af1)

AdSchellevis added a commit to OPNids/core that referenced this pull request May 30, 2018

lib/interfaces, parse ifconfig tunnel data for opnsense/core#2382

574b313

noctarius added 7 commits October 9, 2018 08:30

Added UI support to select DS-Lite as the IPv4 option for a WAN inter…

0673368

…face

Added a check for a valid IPv6 configuration if DS-Lite is chosen

40a0f2c

Added support for creation and destruction of DS-Lite tunnels, as wel…

54bcfc9

…l as adding a dynamic gateway

Removing old files added by accident

471a690

Optimized the statistics and connection type information in interface…

ab7ca51

…s widget and page.

Added raw-option access by transforming the hex value of the discover…

2ca2f69

…ed DHCPv6 AFTR option response back to a string. Related commit for dhcp6c is noctarius/dhcp6c@d3d0585

added a missing dslite link

50d7b82

noctarius force-pushed the dslite-support branch from 5319ad5 to 50d7b82 Compare October 9, 2018 06:33

fichtner force-pushed the master branch from 48820e5 to 333dc0f Compare December 28, 2018 16:46

fichtner closed this Oct 7, 2019

DS-Lite Support (WIP) #2382

DS-Lite Support (WIP) #2382

Conversation

noctarius commented May 1, 2018

AdSchellevis commented May 2, 2018

noctarius commented May 2, 2018 • edited Loading

noctarius commented May 2, 2018

fichtner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fichtner May 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

noctarius May 3, 2018 • edited Loading

Choose a reason for hiding this comment

AdSchellevis May 5, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AdSchellevis commented May 2, 2018

noctarius commented May 2, 2018

noctarius commented May 2, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fichtner May 3, 2018 • edited Loading

Choose a reason for hiding this comment

fichtner commented Oct 7, 2019

noctarius commented May 2, 2018 •

edited

Loading

fichtner May 2, 2018 •

edited

Loading

noctarius May 3, 2018 •

edited

Loading

AdSchellevis May 5, 2018 •

edited

Loading

fichtner May 3, 2018 •

edited

Loading