Project

General

Profile

Bug #6768

DNS Resolver entry for DHCPv6 static mapping has wrong IP address

Added by Michael Virgilio 8 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Category:
DHCP6
Target version:
Start date:
09/05/2016
Due date:
% Done:

100%

Affected version:
2.3.2
Affected Architecture:

Description

I have added two DHCPv6 static mappings for two hosts on my network. But when resolving the hostname to IP address, the address returned by unbound is not correct.

Example:
xps-desktop has static mapping of ::3001 (prefix is xxxx:yyyy:zzzz:*7a71*::)

nslookup xps-desktop

Server: gw
Address: [LAN int address]

Name: xps-desktop.home
Addresses: xxxx:yyyy:zzzz:*7a70*::3001
192.168.1.55

The same happens for the other static DHCPv6 entry that I have as well.

As I believe the functionality for static DHCPv6 with a Track Interface prefix was added in 2.3, this likely affects all 2.3.x versions, but I only have 2.3.2 running, so I've selected that as the affected version.

Associated revisions

Revision e89a17fb
Added by Phillip Davis 8 months ago

Fix #6768 IPv6 static mapping on delegated prefixes

For example, WAN receives a /48 delegated from the upstream (ISP...),
e.g. "2001:470:abcd::" pfSense then uses this as a starting point to
calculate the addresses on LAN, OPT1, OPT2 etc where they have been
specified asa "track interface WAN".
Actually each local interface gets just a /64 taken out of the /48,
using the chunk specified by "IPv6 Prefix Id" for that local interface.
e.g. if "IPv6 Prefix Id" is set to "a1" on LAN, then the LAN would be:
2001:470:abcd:00a1::/64

Then when we specify a static-mapped address in LAN, or other things
that live in LAN, e.g. "::4242" we mean 4242 on from the base LAN
address, so "2001:470:abcd:00a1::4242"

i.e. we always have a CIDR of 64 when calculating this stuff. We do not
want the logic that was in this code that was using the upstream prefix
delegation size (like /48).

Note: The code in services.inc "worked" because var $ifname was not set,
and so $trackifname was blank, $trackcfg was blank, and so the attempted
calculation of $pdlen always came out as 64 anyway. That tricked me for
a while trying to understand why the use in service.inc worked.
system.inc did not work, because it actually claculated $pdlen and got a
number like 48 - which actually we do not want here.

Revision 786d411d
Added by Phillip Davis 8 months ago

Fix #6768 IPv6 static mapping on delegated prefixes

For example, WAN receives a /48 delegated from the upstream (ISP...),
e.g. "2001:470:abcd::" pfSense then uses this as a starting point to
calculate the addresses on LAN, OPT1, OPT2 etc where they have been
specified asa "track interface WAN".
Actually each local interface gets just a /64 taken out of the /48,
using the chunk specified by "IPv6 Prefix Id" for that local interface.
e.g. if "IPv6 Prefix Id" is set to "a1" on LAN, then the LAN would be:
2001:470:abcd:00a1::/64

Then when we specify a static-mapped address in LAN, or other things
that live in LAN, e.g. "::4242" we mean 4242 on from the base LAN
address, so "2001:470:abcd:00a1::4242"

i.e. we always have a CIDR of 64 when calculating this stuff. We do not
want the logic that was in this code that was using the upstream prefix
delegation size (like /48).

Note: The code in services.inc "worked" because var $ifname was not set,
and so $trackifname was blank, $trackcfg was blank, and so the attempted
calculation of $pdlen always came out as 64 anyway. That tricked me for
a while trying to understand why the use in service.inc worked.
system.inc did not work, because it actually claculated $pdlen and got a
number like 48 - which actually we do not want here.

(cherry picked from commit e89a17fbf04aae89f60f13baf293f397ca21c303)

History

#1 Updated by Michael Virgilio 8 months ago

No, the asterisks aren't part of the address. Apparently bold text isn't supported here, despite the button above the edit field.

#2 Updated by Michael Virgilio 8 months ago

Likely reason for this is because in entering the DHCPv6 static mapping, you're entering ONLY the host portion of the address. But in creating the DNS entry, it appears as though the prefix appended to the host portion is the base (0) prefix, not the proper prefix for the interface that the static entry is being configured on.

#3 Updated by Phillip Davis 8 months ago

I tried this in a VM. I delegated a /56 (out of the /48 I have from he.net) from my real router to the WAN of the VM (sitting in my real LAN). Then set the LAN of the VM to Track Interface with "IPv6 Prefix ID" set to "a1" (just to give a recognizable offset).

LAN ends up with an IPv6 subnet like 2001:1111:2222:ffa1::/64 ("1111" and "2222" are not the real public IP values:) - so the "a1" bit is correctly being calculated there.

I added a static mapped IP ::4242

In /var/dhcpd/etc/dhcpdv6.conf I get good-looking stuff:

subnet6 2001:1111:2222:ffa1::/64 {
range6 2001:1111:2222:ffa1::1000 2001:1111:2222:ffa1::2000;
do-forward-updates false;
option dhcp6.name-servers 2001:1111:2222:ffa1:a00:27ff:fe03:8b36;

}
host s_lan_0 {
host-identifier option dhcp6.client-id ADUID;
fixed-address6 2001:1111:2222:ffa1::4242;
option host-name teststaticipv6;
}

Can you post more detail on how this happens - WAN and LAN settings, and content from /var/dhcpd/etc/dhcpdv6.conf ?

#4 Updated by Michael Virgilio 8 months ago

The issue isn't with DHCP... it's with DNS (unbound, in my case) resolution of a DHCPv6 static mapping.

Looking in /var/unbound/host_entries.conf, it looks like the entries are not being added with the right address.

/var/dhcpd/etc/dhcpdv6.conf:
host s_lan_1 {
host-identifier option dhcp6.client-id 00:01:00:01:xx:xx:xx:yy:yy:yy:zz:zz:zz:d7;
fixed-address6 2601:xxx:yyyy:7a71::3001;
option host-name xps-desktop;
}

/var/unbound/host_entries.conf:
...
local-data-ptr: "2601:xxx:yyyy:7a70::3001 xps-desktop.home"
local-data: "xps-desktop.home AAAA 2601:xxx:yyyy:7a70::3001"
local-data: "xps-desktop AAAA 2601:xxx:yyyy:7a70::3001"

#6 Updated by Renato Botelho 8 months ago

  • Assignee set to Renato Botelho
  • Target version set to 2.4.0

#7 Updated by Phillip Davis 8 months ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#8 Updated by Jim Pingle 3 months ago

  • Target version changed from 2.4.0 to 2.3.3

#9 Updated by Renato Botelho 3 months ago

  • Status changed from Feedback to Resolved

works

#10 Updated by Renato Botelho 3 months ago

  • Status changed from Resolved to Feedback

ops, untested yet

#11 Updated by Jim Pingle 3 months ago

  • Status changed from Feedback to Resolved

Tested 2.3.3 and 2.4, correct subnet is used.

Also available in: Atom PDF