Experiments with DHCP client side syntax
-
Asking for some help with complex syntax at DHCP client config side.
My goal is to use pfSense with IPv6. And as one might have noticed, ISPs have made this task relatively difficult. From ISP's viewpoint, the cost of deployment and support are critical factors, while openness is not. Often aren't IPV6 addresses obtained via simple professional standards, but trough various low level tricks (Option 82, PPPOE, younameit).
I'm attempting to substitute an ISP CPE device (Inteno DG301) with pfSense. IPV4 alone is working superior but IPV6 configuration is sensitive to glitches. To get things right, IPV4 and IPV6 DHCP clients must work in pair. Omissions in IPV4 conf will lead to no IPV6 connectivity later.
The way I have chosen is to snoop Ethernet and try to mimic the behaviour of CPE.
The original CPE is soliciting following DHCP v4 options:Client MAC address: IntenoBr_xx:yy:zz (00:22:07:xx:yy:zz)
[..]
Option: (55) Parameter Request List
Length: 8
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (3) Router
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (12) Host Name
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (28) Broadcast Address
Parameter Request List Item: (42) Network Time Protocol Servers
Parameter Request List Item: (212) 6RD
Option: (60) Vendor class identifier
Length: 18
Vendor class identifier: DG301-W7P2U-INTENO
Option: (12) Host Name
Length: 11
Host Name: Inteno_YYZZ
Option: (255) End[Note: xx:yy:zz are substituted, actually ZZ denotes another interface of CPE than zz]
There is little known about complex configuration examples. Textbooks cite too theoretical examples which won't work in practice. pfSence GUI has very cryptical help texts. My decision was to tick "Configuration override" for both DHCP v4 and v6 and catch errors via debug level DHCP log (tuned to show full 2000 lines).
This is what my semifunctional /root/ALT/4.conf currently looks like:
interface "em5" {
timeout 60;
retry 15;
select-timeout 0;
initial-interval 1;
send dhcp-client-identifier "Inteno";
send host-name "Inteno";
request subnet-mask,
routers,
domain-name-servers,
host-name,
domain-name,
broadcast-address,
ntp-servers;script "/usr/local/sbin/pfSense-dhclient-script";
}
} # Did you spot the extra curly brace which parser is not complaining at ? ;)My questions are:
Q1: Is the ISC dhcp code actually supporting option declarations at client side? Can please somebody provide at least one working syntax example? Should the declaration reside outside of interface scope or where?
At least this example will result parsing errors:
option vendor-class-identifier code 18 = text;
# send vendor-class-identifier "DG301-W7P2U-INTENO";
Q2: Any idea about incorporating the 6RD option? I haven't yet succeeded to snoop any actual IP packet containing the relevant data structure, thus I think a short mimicking should be enough. Is it really possible that Option 6RD only is a trigger word? The following declarations and requests will fail:
SRC: https://community.ubnt.com/t5/EdgeMAX/dhcp-client-OPTION-6RD-212/td-p/1434763
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
option option-6rd code 212 = { integer 8, integer 8, integer 16, integer 16,
# integer 16, integer 16, integer 16, integer 16,
# integer 16, integer 16, array of ip-address };
# request rfc3442-classless-static-routes,
# option-6rd;Q3: The syntax of Option 12 turns the parser mad. But why? Is the underscore symbol prohibited? Should one reproduce the string in HEX ("XX:YY:ZZ")?
# send host-name "Inteno_1234";
Feb 4 14:09:31 dhclient 456 Bogus Host Name option 12: Inteno_1234 (Inteno_1234)
[Note: 1234 is substituted]
Q4: Whether a finite list of implemented keywords (i.e. config file options like host-name) exist with option codes provided, or one has to google and experiment? (man (5) fairytales are too smoggy to work with. RFCs do not contain the keywords)
-
:-[ :-[ :-[ Me ask, me answer :-[ :-[ :-[
As it turned out, I was over-engineering approximately thirteenfold or so.
Of course, it would be nice to master all these bloody DHCP details, but.
The actual solution to replace CPE by pfSense was much easier.It turns out (in this particular configuration) [b]the WAN interface does not need any IPv6 global address on it.
An IPv4 address together with a link-local address will do.
Very counter-intuitive from ppl coming from v4 world, eh?As one of the ways of mitigation, the previous dhcp v6 client file could be copied off the /var/etc/ directory. Then an alternative DHCPv6 configuration should built up elsewhere (e.g. below /root/) based on its example. The main reason to do so was the limitless love towards the old style CLI and debug cycle. The secondary reason was the necessity to correct the script name that GUI has kindly offered during the previous experiments.
# script "/var/etc/dhcp6c_wan_dhcp6withoutra_script.sh"; # This default remnant is WRONG
script "/var/etc/dhcp6c_wan_script.sh"; # We need to go with RAAfterwards, the alternative DHCP v6 file should be activated via Interfaces/WAN GUI and LAN/OPTX interfaces made "tracking" WAN as usual.
This particular configuration dictates we'll forget about IA-NA:
# send ia-na 0; # NO global IPv6 addr on WAN. Link-local only.
id-assoc na 0 {}; # Thrown off. (We don't speak, you don't ask.)
Last but not least, with Linux clients, I was able chose "Unmanaged" as the "router type" (on RA page). DHCP server could still be useful for entertainment purposes (communicating any dynamic value to hosts) but Global Scope addresses will now just appear from nowhere, via PD and RA mechanisms. Sic the v6 magic!