Project

General

Profile

Actions

Bug #4206

closed

Missing route creation on DHCP-PD lease where ia-na != ia-pd

Added by Anders Lind almost 7 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Low
Category:
DHCP (IPv6)
Target version:
Start date:
01/12/2015
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:

Description

The long story ( https://forum.pfsense.org/index.php?topic=86374.0 ) short:
When a prefix is delegated through DHCP for IPv6 from a pfSense edge router to a SOHO D-Link sub-router then only the DHCPv6 info is supplied to that sub-router, but pfSense does not create the route to the sub-router/delegated sub-network.

The problem short:
The route is never created because the resulting string generated by /usr/local/sbin/prefixes.php is:
/sbin/route change -inet6 <delegated network> <but missing WAN address of the sub-router>
E.g.:
/sbin/route change -inet6 2a02:abcd:dcba:3fff::/64

The cause ( https://forum.pfsense.org/index.php?topic=86374.msg474928#msg474928 ):
The lease file /var/dhcpd/var/db/dhcpd6.leases contains for the sub-router different strings for ia-na and ia-pd that leads to that the WAN address of the sub-router becomes the empty string, because /usr/local/sbin/prefixes.php at lines:

     55 $routes = array();
     56 foreach ($duid_arr as $entry) {
     57         if(!empty($entry['ia-pd'])) {
     58                 $routes[$entry['ia-na']] = $entry['ia-pd'];
     59         }
     60 }

, fails, because the IPv6 address of ia-na and the IPv6 network of ia-pd lies in each (but different) entries of the $duid_arr (and not the same entry if the strings of ia-na and ia-pd had been equal - see below!)

This happens because:

ia-na:
ia-na "\273\240\300\034\000\003\000\001\300\240\273\034\xxx\xxx" {
ia-na in hex:
         BB  A0  C0  1C  00  03  00  01  C0  A0  BB  1C  XX  XX

ia-pd: 
ia-pd "\000\000\000\000\000\003\000\001\300\240\273\034\xxx\xxx" {
ia-pd in hex:
         00  00  00  00  00  03  00  01  C0  A0  BB  1C  XX  XX

mac address of the sub-router:           c0 :a0 :bb :1c :xx :xx

and because the start of the prefixes.php file:
     10 $duid_arr = array();
     11 while (( $line = fgets($fd, 4096)) !== false) {
     12         // echo "$line";
     13         if(preg_match("/^(ia-[np][ad])[ ]+\"(.*?)\"/i", $line, $duidmatch)) {
     14                 $type = $duidmatch[1];
     15                 $duid = $duidmatch[2];
     16                 continue;
     17         }

, stores the entire octet strings into $duid instead of e.g. only the "real" duid part meaning excluding the first 4 octets. Well the DUID in this example is a type 3 (DUID-LL).

Question 1 is why this difference? I do not have a clue e.g. if it is the dhcp6 server or the client (the D-Link sub-router) that makes the alternative ia-na string compared to the ia-pd string, but if we look at the MAC address:

c0 :a0 :bb :1c :xx :xx <-- MAC
c0 :a0 :bb :1c         <-- First 4 blocks of MAC
BB  A0  C0  1C         <-- two blocks (first and third) switch places
BB  A0  C0  1C == \273\240\300\034\ <-- start/first 4 octets of the ia-na string.

Question 2: Are the possible solutions to fix prefixes.php (line 13 and line 15) by either:
1) taking a part of the ia-na string and ia-pd string that corresponds to the DUID and remove(/leave out) the first 4 blocks (1 block => \xxx) or
2) forcing the first 4 blocks zeroed out (\000) or
3) do and verify what the dhcpv6 service or my D-Link sub-router does?

I just guess it has nothing to do with RFC6355 ( http://tools.ietf.org/html/rfc6355 ), but "just" RFC3315 ( http://tools.ietf.org/html/rfc3315 ) combined with some ISC DHCPv6 stuff and/or the D-Link stuff of which I have no understanding.


Files

packetcapture.cap (5.08 KB) packetcapture.cap pcap file Anders Lind, 01/20/2015 02:21 PM
Status DHCPv6 leases.png (165 KB) Status DHCPv6 leases.png Screenshot of the Status DHCPv6 leases page Anders Lind, 01/20/2015 02:21 PM
dhcpd6.leases (892 Bytes) dhcpd6.leases Leases file Anders Lind, 01/20/2015 02:21 PM
Actions

Also available in: Atom PDF