Solved Is there a working DHCPv6 client for FreeBSD?

C

crocket

It seems dhclient and dhcp6 are all broken at this point.
dhcp6c couldn't fetch an IPv6 address from my OpenWrt router.
 
Until dhclient from FreeBSD base starts supporting IPv6, you can use dual-dhclient in /etc/rc.conf.
​
Using dual-dhclient in /etc/rc.conf(recommended)​

Install dual-dhclient

Code: 
pkg install dual-dhclient
Set up dual-dhclient in /etc/rc.conf

Code: 
ipv6_activate_all_interfaces="YES"
dhclient_program="/usr/local/sbin/dual-dhclient"
ifconfig_DEFAULT="DHCP accept_rtadv"
dhcpcd on FreeBSD(Partial Functionality)​

I tried dhcpcd on FreeBSD. It fetches an DHCPv6 address and generates two SLAAC addresses. However, dhcpcd has an issue with SLAAC. It doesn't classify SLAAC addresses as `autoconf` or `temp` according to ifconfig. Also, dhcpcd is not integrated with /etc/rc.conf. Thus, I surmise that dhcpcd is not properly ported to FreeBSD.

dual-dhclient is superior to dhcpcd.

dhcp6c on FreeBSD(Complete Failure)​

dhcp6c fails to fetch a DHCPv6 address due to some errors. Let me show you the errors below.

Code: 
-> sudo dhcp6c -d -D -f -c /usr/local/etc/dhcp6c.conf vtnet0
Mar/18/2017 03:24:26: extracted an existing DUID from /var/db/dhcp6c_duid: 00:01:00:01:20:5e:a7:40:52:54:00:3a:4d:f7
Mar/18/2017 03:24:26: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Mar/18/2017 03:24:26: failed initialize control message authentication
Mar/18/2017 03:24:26: skip opening control port
Mar/18/2017 03:24:26: <3>comment [# The following is an example for use with IPv6 auto-configuration.] (67)
Mar/18/2017 03:24:26: <3>comment [# The "information-only" statement makes dhcp6c exchange informational] (70)
Mar/18/2017 03:24:26: <3>comment [# configuration parameters with servers. A list of DNS server addresses] (71)
Mar/18/2017 03:24:26: <3>comment [# is an example of such parameters. This statement is useful when the] (69)
Mar/18/2017 03:24:26: <3>comment [# client does not need stateful configuration parameters such as IPv6] (69)
Mar/18/2017 03:24:26: <3>comment [# addresses or prefixes.] (24)
Mar/18/2017 03:24:26: <3>comment [# interface ne0 {] (17)
Mar/18/2017 03:24:26: <3>comment [#     information-only;] (20)
Mar/18/2017 03:24:26: <3>comment [# };] (4)
Mar/18/2017 03:24:26: <3>comment [# The following is a sample configuration for a client on a LAN] (63)
Mar/18/2017 03:24:26: <3>comment [# where IPv6 addresses are assigned via DHCPv6 ("stateful address] (65)
Mar/18/2017 03:24:26: <3>comment [# assignment"). Use this if you want the client to query the] (60)
Mar/18/2017 03:24:26: <3>comment [# DHCPv6 server for an IPv6 address and for DNS servers, as in] (62)
Mar/18/2017 03:24:26: <3>comment [# traditional IPv4 DHCP.] (24)
Mar/18/2017 03:24:26: <3>[interface] (9)
Mar/18/2017 03:24:26: <5>[vtnet0] (6)
Mar/18/2017 03:24:26: <3>begin of closure [{] (1)
Mar/18/2017 03:24:26: <3>[send] (4)
Mar/18/2017 03:24:26: <3>[ia-na] (5)
Mar/18/2017 03:24:26: <3>[0] (1)
Mar/18/2017 03:24:26: <3>end of sentence [;] (1)
Mar/18/2017 03:24:26: <3>[send] (4)
Mar/18/2017 03:24:26: <3>[rapid-commit] (12)
Mar/18/2017 03:24:26: <3>end of sentence [;] (1)
Mar/18/2017 03:24:26: <3>[send] (4)
Mar/18/2017 03:24:26: <3>[domain-name-servers] (19)
Mar/18/2017 03:24:26: <3>end of sentence [;] (1)
Mar/18/2017 03:24:26: <3>[send] (4)
Mar/18/2017 03:24:26: <3>[domain-name] (11)
Mar/18/2017 03:24:26: <3>end of sentence [;] (1)
Mar/18/2017 03:24:26: <3>[send] (4)
Mar/18/2017 03:24:26: <3>[ntp-servers] (11)
Mar/18/2017 03:24:26: <3>end of sentence [;] (1)
Mar/18/2017 03:24:26: <3>end of closure [}] (1)
Mar/18/2017 03:24:26: <3>end of sentence [;] (1)
Mar/18/2017 03:24:26: <3>[id-assoc] (8)
Mar/18/2017 03:24:26: <13>[na] (2)
Mar/18/2017 03:24:26: <13>[0] (1)
Mar/18/2017 03:24:26: <13>begin of closure [{] (1)
Mar/18/2017 03:24:26: <3>end of closure [}] (1)
Mar/18/2017 03:24:26: <3>end of sentence [;] (1)
Mar/18/2017 03:24:26: <3>comment [# The following is an example configuration for delegation of an IPv6 prefix] (76)
Mar/18/2017 03:24:26: <3>comment [# from an upstream service provider.  With this configuration dhcp6c will] (73)
Mar/18/2017 03:24:26: <3>comment [# send solicit messages containing an IA_PD option, with an IAID 0, on to] (73)
Mar/18/2017 03:24:26: <3>comment [# an upstream PPP link, ppp0.  After receiving some prefixes from a server,] (75)
Mar/18/2017 03:24:26: <3>comment [# dhcp6c will then configure derived IPv6 prefixes with the SLA ID 1 on a] (73)
Mar/18/2017 03:24:26: <3>comment [# local ethernet interface, ne0.  Note that the IAID for the id-assoc] (69)
Mar/18/2017 03:24:26: <3>comment [# statement is 0 according to the default.] (42)
Mar/18/2017 03:24:26: <3>comment [# interface ppp0 {] (18)
Mar/18/2017 03:24:26: <3>comment [#         send ia-pd 0;] (23)
Mar/18/2017 03:24:26: <3>comment [# };] (4)
Mar/18/2017 03:24:26: <3>comment [# id-assoc pd {] (15)
Mar/18/2017 03:24:26: <3>comment [#         prefix-interface ne0 {] (32)
Mar/18/2017 03:24:26: <3>comment [#                 sla-id 1;] (27)
Mar/18/2017 03:24:26: <3>comment [#         };] (12)
Mar/18/2017 03:24:26: <3>comment [# };] (4)
Mar/18/2017 03:24:26: <3>comment [# If a shared secret was to be configured in both the client and the server] (75)
Mar/18/2017 03:24:26: <3>comment [# for DHCPv6 authentication, it would be specified in this file as follows:] (75)
Mar/18/2017 03:24:26: <3>comment [# keyinfo kame-key {] (20)
Mar/18/2017 03:24:26: <3>comment [#      realm "kame.net";] (24)
Mar/18/2017 03:24:26: <3>comment [#      keyid 1;] (15)
Mar/18/2017 03:24:26: <3>comment [#      secret "5pvW2g48OHPvkYMJSw0vZA==";] (41)
Mar/18/2017 03:24:26: <3>comment [# };] (4)
Mar/18/2017 03:24:26: <3>comment [# And the interface statement would be modified as follows:] (59)
Mar/18/2017 03:24:26: <3>comment [# interface ppp0 {] (18)
Mar/18/2017 03:24:26: <3>comment [#      send ia-pd 0;] (20)
Mar/18/2017 03:24:26: <3>comment [#      send authentication kame;] (32)
Mar/18/2017 03:24:26: <3>comment [# };] (4)
Mar/18/2017 03:24:26: called
Mar/18/2017 03:24:26: invalid operation (0) for option type (16)
Mar/18/2017 03:24:26: invalid operation (0) for option type (17)
Mar/18/2017 03:24:26: invalid operation (0) for option type (20)
Mar/18/2017 03:24:26: called
Mar/18/2017 03:24:26: reset a timer on vtnet0, state=INIT, timeo=0, retrans=891
Mar/18/2017 03:24:27: Sending Solicit
Mar/18/2017 03:24:27: a new XID (c53c6c) is generated
Mar/18/2017 03:24:27: set client ID (len 14)
Mar/18/2017 03:24:27: set identity association
Mar/18/2017 03:24:27: set rapid commit (len 0)
Mar/18/2017 03:24:27: set elapsed time (len 2)
Mar/18/2017 03:24:27: send solicit to ff02::1:2%vtnet0
Mar/18/2017 03:24:27: reset a timer on vtnet0, state=SOLICIT, timeo=0, retrans=1091
Mar/18/2017 03:24:27: receive advertise from fe80::126f:3fff:fe4c:5103%vtnet0 on vtnet0
Mar/18/2017 03:24:27: get DHCP option server ID, len 10
Mar/18/2017 03:24:27:   DUID: 00:03:00:01:10:6f:3f:4c:51:03
Mar/18/2017 03:24:27: get DHCP option client ID, len 14
Mar/18/2017 03:24:27:   DUID: 00:01:00:01:20:5e:a7:40:52:54:00:3a:4d:f7
Mar/18/2017 03:24:27: get DHCP option opt_82, len 4
Mar/18/2017 03:24:27: unknown or unexpected DHCP6 option opt_82, len 4
Mar/18/2017 03:24:27: get DHCP option DNS, len 16
Mar/18/2017 03:24:27: get DHCP option domain search list, len 5
Mar/18/2017 03:24:27: get DHCP option opt_20, len 0
Mar/18/2017 03:24:27: unknown or unexpected DHCP6 option opt_20, len 0
Mar/18/2017 03:24:27: get DHCP option identity association, len 40
Mar/18/2017 03:24:27:   IA_NA: ID=0, T1=21600, T2=34560
Mar/18/2017 03:24:27: get DHCP option IA address, len 24
Mar/18/2017 03:24:27:   IA_NA address: fd3c:35be:df79:1234::d4a pltime=4294967295 vltime=4294967295
Mar/18/2017 03:24:27: server ID: 00:03:00:01:10:6f:3f:4c:51:03, pref=-1
Mar/18/2017 03:24:27: unexpected advertise
Mar/18/2017 03:24:27: reset timer for vtnet0 to 0.996489
Mar/18/2017 03:24:28: picked a server (ID: 00:03:00:01:10:6f:3f:4c:51:03)
Mar/18/2017 03:24:28: Sending Request
Mar/18/2017 03:24:28: a new XID (33c06a) is generated
Mar/18/2017 03:24:28: set client ID (len 14)
Mar/18/2017 03:24:28: set server ID (len 10)
Mar/18/2017 03:24:28: set IA address
Mar/18/2017 03:24:28: set identity association
Mar/18/2017 03:24:28: set elapsed time (len 2)
Mar/18/2017 03:24:28: send request to ff02::1:2%vtnet0
Mar/18/2017 03:24:28: reset a timer on vtnet0, state=REQUEST, timeo=0, retrans=909
Mar/18/2017 03:24:28: receive reply from fe80::126f:3fff:fe4c:5103%vtnet0 on vtnet0
Mar/18/2017 03:24:28: get DHCP option server ID, len 10
Mar/18/2017 03:24:28:   DUID: 00:03:00:01:10:6f:3f:4c:51:03
Mar/18/2017 03:24:28: get DHCP option client ID, len 14
Mar/18/2017 03:24:28:   DUID: 00:01:00:01:20:5e:a7:40:52:54:00:3a:4d:f7
Mar/18/2017 03:24:28: get DHCP option opt_82, len 4
Mar/18/2017 03:24:28: unknown or unexpected DHCP6 option opt_82, len 4
Mar/18/2017 03:24:28: get DHCP option DNS, len 16
Mar/18/2017 03:24:28: get DHCP option domain search list, len 5
Mar/18/2017 03:24:28: get DHCP option opt_20, len 0
Mar/18/2017 03:24:28: unknown or unexpected DHCP6 option opt_20, len 0
Mar/18/2017 03:24:28: get DHCP option authentication, len 28
Mar/18/2017 03:24:28:   proto: reconfig, alg: HMAC-MD5, RDM: mono counter, RD: 58cc a86d 0000 002c
Mar/18/2017 03:24:28: unsupported authentication protocol: 1
Mar/18/2017 03:24:28: failed to parse options
Mar/18/2017 03:24:29: Sending Request
Mar/18/2017 03:24:29: set client ID (len 14)
Mar/18/2017 03:24:29: set server ID (len 10)
Mar/18/2017 03:24:29: set IA address
Mar/18/2017 03:24:29: set identity association
Mar/18/2017 03:24:29: set elapsed time (len 2)
Mar/18/2017 03:24:29: send request to ff02::1:2%vtnet0
Mar/18/2017 03:24:29: reset a timer on vtnet0, state=REQUEST, timeo=1, retrans=1737
Mar/18/2017 03:24:29: receive reply from fe80::126f:3fff:fe4c:5103%vtnet0 on vtnet0
Mar/18/2017 03:24:29: get DHCP option server ID, len 10
Mar/18/2017 03:24:29:   DUID: 00:03:00:01:10:6f:3f:4c:51:03
Mar/18/2017 03:24:29: get DHCP option client ID, len 14
Mar/18/2017 03:24:29:   DUID: 00:01:00:01:20:5e:a7:40:52:54:00:3a:4d:f7
Mar/18/2017 03:24:29: get DHCP option opt_82, len 4
Mar/18/2017 03:24:29: unknown or unexpected DHCP6 option opt_82, len 4
Mar/18/2017 03:24:29: get DHCP option DNS, len 16
Mar/18/2017 03:24:29: get DHCP option domain search list, len 5
Mar/18/2017 03:24:29: get DHCP option opt_20, len 0
Mar/18/2017 03:24:29: unknown or unexpected DHCP6 option opt_20, len 0
Mar/18/2017 03:24:29: get DHCP option authentication, len 28
Mar/18/2017 03:24:29:   proto: reconfig, alg: HMAC-MD5, RDM: mono counter, RD: 58cc a86e 0000 002d
Mar/18/2017 03:24:29: unsupported authentication protocol: 1
Mar/18/2017 03:24:29: failed to parse options
Mar/18/2017 03:24:31: Sending Request
Mar/18/2017 03:24:31: set client ID (len 14)
Mar/18/2017 03:24:31: set server ID (len 10)
Mar/18/2017 03:24:31: set IA address
Mar/18/2017 03:24:31: set identity association
Mar/18/2017 03:24:31: set elapsed time (len 2)
Mar/18/2017 03:24:31: send request to ff02::1:2%vtnet0
Mar/18/2017 03:24:31: reset a timer on vtnet0, state=REQUEST, timeo=2, retrans=3518
Mar/18/2017 03:24:31: receive reply from fe80::126f:3fff:fe4c:5103%vtnet0 on vtnet0
Mar/18/2017 03:24:31: get DHCP option server ID, len 10
Mar/18/2017 03:24:31:   DUID: 00:03:00:01:10:6f:3f:4c:51:03
Mar/18/2017 03:24:31: get DHCP option client ID, len 14
Mar/18/2017 03:24:31:   DUID: 00:01:00:01:20:5e:a7:40:52:54:00:3a:4d:f7
Mar/18/2017 03:24:31: get DHCP option opt_82, len 4
Mar/18/2017 03:24:31: unknown or unexpected DHCP6 option opt_82, len 4
Mar/18/2017 03:24:31: get DHCP option DNS, len 16
Mar/18/2017 03:24:31: get DHCP option domain search list, len 5
Mar/18/2017 03:24:31: get DHCP option opt_20, len 0
Mar/18/2017 03:24:31: unknown or unexpected DHCP6 option opt_20, len 0
Mar/18/2017 03:24:31: get DHCP option authentication, len 28
Mar/18/2017 03:24:31:   proto: reconfig, alg: HMAC-MD5, RDM: mono counter, RD: 58cc a870 0000 002e
Mar/18/2017 03:24:31: unsupported authentication protocol: 1
Mar/18/2017 03:24:31: failed to parse options
Mar/18/2017 03:24:34: Sending Request
Mar/18/2017 03:24:34: set client ID (len 14)
Mar/18/2017 03:24:34: set server ID (len 10)
Mar/18/2017 03:24:34: set IA address
Mar/18/2017 03:24:34: set identity association
Mar/18/2017 03:24:34: set elapsed time (len 2)
Mar/18/2017 03:24:34: send request to ff02::1:2%vtnet0
Mar/18/2017 03:24:34: reset a timer on vtnet0, state=REQUEST, timeo=3, retrans=7121
Mar/18/2017 03:24:34: receive reply from fe80::126f:3fff:fe4c:5103%vtnet0 on vtnet0
Mar/18/2017 03:24:34: get DHCP option server ID, len 10
Mar/18/2017 03:24:34:   DUID: 00:03:00:01:10:6f:3f:4c:51:03
Mar/18/2017 03:24:34: get DHCP option client ID, len 14
Mar/18/2017 03:24:34:   DUID: 00:01:00:01:20:5e:a7:40:52:54:00:3a:4d:f7
Mar/18/2017 03:24:34: get DHCP option opt_82, len 4
Mar/18/2017 03:24:34: unknown or unexpected DHCP6 option opt_82, len 4
Mar/18/2017 03:24:34: get DHCP option DNS, len 16
Mar/18/2017 03:24:34: get DHCP option domain search list, len 5
Mar/18/2017 03:24:34: get DHCP option opt_20, len 0
Mar/18/2017 03:24:34: unknown or unexpected DHCP6 option opt_20, len 0
Mar/18/2017 03:24:34: get DHCP option authentication, len 28
Mar/18/2017 03:24:34:   proto: reconfig, alg: HMAC-MD5, RDM: mono counter, RD: 58cc a873 0000 002f
Mar/18/2017 03:24:34: unsupported authentication protocol: 1
Mar/18/2017 03:24:34: failed to parse options
The output of dhcp6c is too long. Below, I extracted the part I think was relevant to failure.

Code: 
unknown or unexpected DHCP6 option opt_82, len 4
unknown or unexpected DHCP6 option opt_20, len 0
get DHCP option authentication, len 28
  proto: reconfig, alg: HMAC-MD5, RDM: mono counter, RD: 58cc a873 0000 002f
unsupported authentication protocol: 1
failed to parse options
My conclusion about dhcp6 is that it has been abandoned for at least 8 years, and it shouldn't be used.
 
Anyone considering using (ISC) dhclient in an IPv6 situation should be aware of the following limitations:
  • Two instances of dhclient are required if you are obtaining both an ia-na (non-temporary address) and an ia-pd (prefix-delegation)
  • dhclient requests a ::/64 prefix-length by default, with no run-time override available
While the former is an annoyance, the latter is a problem for providers such as Comcast that will provide a single ::/64 prefix, unless the prefix-length of the IA_PD Prefix option is populated on request. (In many of their markets, a ::/60 prefix will be delegated on request.)

This latter limitation has been known for years and there is at least set of patches available to be able to set a requested prefix-length. I have not tested the patches I found at https://archive.mgm51.com/sources/pd-pref.html

ISC is aware of other problems related to prefix-length when the hard-coded ::/64 is requested, but a different prefix-length is returned. They also indicate that:

DHCLIENT_DEFAULT_PREFIX_LEN in includes/site.h, and a user who wants a different default can edit this file and recompile.​

See https://kb.isc.org/article/AA-01141...efix-length-issues-with-ISC-DHCP-clients.html

Edit: I haven't had any luck getting dhclient to send the ia-prefix hint in the ia-pd option, even with the above change made.

The overall situation around prefix-length hinting is being discussed by the IETF. See, for example, https://tools.ietf.org/html/rfc8168
 
A couple of items to round out this thread...

I've been using the patches found at https://archive.mgm51.com/sources/pd-pref.html for a few years with Comcast as my ISP, and the patches work fine.

The ISC is in the process of releasing ISC DHCP 4.4 which includes the capability to specify requested prefix length. I tried the beta version of the dhclient included and it works.
 
I decided it was time to upgrade my home FreeBSD/PF router from an old Soekris running FreeBSD 9 to a more modern Supermicro running FreeBSD 11.

Everything pretty much worked as expected in the upgrade ... Except for DHCPv6, which has me pulling my hair out.

Basically, For dhcp6c, I copied the working configuration over from my old FreeBSD 9 setup, and just changed the interface names based on the current driver names. It will properly work about 1 out of every 1000 times I run it, seemingly for no random reason.

Logs look something like this:
Code: 
Feb/25/2018 21:24:57: send solicit to ff02::1:2%lagg0
Feb/25/2018 21:24:57: reset a timer on lagg0, state=SOLICIT, timeo=0, retrans=1091
Feb/25/2018 21:24:57: receive advertise from fe80::201:5cff:fe86:b046%lagg0 on lagg0
Feb/25/2018 21:24:57: get DHCP option client ID, len 14
Feb/25/2018 21:24:57:   DUID: 00:01:00:01:22:26:0e:58:00:25:00:00:1a:1a
Feb/25/2018 21:24:57: get DHCP option server ID, len 14
Feb/25/2018 21:24:57:   DUID: 00:01:00:01:15:55:76:84:84:2b:2b:fc:9d:17
Feb/25/2018 21:24:57: get DHCP option identity association, len 40
Feb/25/2018 21:24:57:   IA_NA: ID=1, T1=1800, T2=2880
Feb/25/2018 21:24:57: get DHCP option IA address, len 24
Feb/25/2018 21:24:57:   IA_NA address: 2001:558:6004:4:a5b7:73f:6440:284c pltime=3600 vltime=3600
Feb/25/2018 21:24:57: get DHCP option IA_PD, len 41
Feb/25/2018 21:24:57:   IA_PD: ID=1, T1=1800, T2=2880
Feb/25/2018 21:24:57: get DHCP option IA_PD prefix, len 25
Feb/25/2018 21:24:57:   IA_PD prefix: 2601:881:8000:4750::/64 pltime=3600 vltime=3600
Feb/25/2018 21:24:57: server ID: 00:01:00:01:15:55:76:84:84:2b:2b:fc:9d:17, pref=-1
Feb/25/2018 21:24:57: unexpected advertise
Feb/25/2018 21:24:57: reset timer for lagg0 to 0.962758
Feb/25/2018 21:24:58: picked a server (ID: 00:01:00:01:15:55:76:84:84:2b:2b:fc:9d:17)
Feb/25/2018 21:24:58: Sending Request
Feb/25/2018 21:24:58: a new XID (84de89) is generated
Feb/25/2018 21:24:58: set client ID (len 14)
Feb/25/2018 21:24:58: set server ID (len 14)
Feb/25/2018 21:24:58: set IA address
Feb/25/2018 21:24:58: set identity association
Feb/25/2018 21:24:58: set elapsed time (len 2)
Feb/25/2018 21:24:58: set IA_PD prefix
Feb/25/2018 21:24:58: set IA_PD
Feb/25/2018 21:24:58: send request to ff02::1:2%lagg0
Feb/25/2018 21:24:58: reset a timer on lagg0, state=REQUEST, timeo=0, retrans=909
The last bit from Sending Request to reset a timer on lagg0 just keeps repeating, and it generally never actually finishes.


dhclient6 from isc does seem to be able to get both the NA and PD, but with there not being any scripts that actually join the whole thing together to assign the PD onto an interface and enable rtadvd on the inside interface, it's all kinda useless.

Any ideas why this has gotten so much harder?

I'd really prefer to not just give up and run pfSense.
 
The rare 1/1000 times it does actually work, this is what the output looks like:

Code: 
Feb/25/2018 21:29:18: Sending Solicit
Feb/25/2018 21:29:18: a new XID (692950) is generated
Feb/25/2018 21:29:18: set client ID (len 14)
Feb/25/2018 21:29:18: set identity association
Feb/25/2018 21:29:18: set rapid commit (len 0)
Feb/25/2018 21:29:18: set elapsed time (len 2)
Feb/25/2018 21:29:18: set IA_PD
Feb/25/2018 21:29:18: send solicit to ff02::1:2%lagg0
Feb/25/2018 21:29:18: reset a timer on lagg0, state=SOLICIT, timeo=0, retrans=1091
Feb/25/2018 21:29:18: receive advertise from fe80::201:5cff:fe86:b046%lagg0 on lagg0
Feb/25/2018 21:29:18: get DHCP option client ID, len 14
Feb/25/2018 21:29:18:   DUID: 00:01:00:01:22:26:0e:58:00:25:00:00:b0:0b
Feb/25/2018 21:29:18: get DHCP option server ID, len 14
Feb/25/2018 21:29:18:   DUID: 00:01:00:01:15:55:76:84:84:2b:2b:fc:9d:17
Feb/25/2018 21:29:18: get DHCP option identity association, len 40
Feb/25/2018 21:29:18:   IA_NA: ID=1, T1=1800, T2=2880
Feb/25/2018 21:29:18: get DHCP option IA address, len 24
Feb/25/2018 21:29:18:   IA_NA address: 2001:558:6004:4:74d5:51a1:76c4:329c pltime=3600 vltime=3600
Feb/25/2018 21:29:18: get DHCP option IA_PD, len 41
Feb/25/2018 21:29:18:   IA_PD: ID=1, T1=1800, T2=2880
Feb/25/2018 21:29:18: get DHCP option IA_PD prefix, len 25
Feb/25/2018 21:29:18:   IA_PD prefix: 2601:881:8000:4750::/64 pltime=3600 vltime=3600
Feb/25/2018 21:29:18: server ID: 00:01:00:01:15:55:76:84:84:2b:2b:fc:9d:17, pref=-1
Feb/25/2018 21:29:18: unexpected advertise
Feb/25/2018 21:29:18: reset timer for lagg0 to 0.968963
Feb/25/2018 21:29:19: picked a server (ID: 00:01:00:01:15:55:76:84:84:2b:2b:fc:9d:17)
Feb/25/2018 21:29:19: Sending Request
Feb/25/2018 21:29:19: a new XID (89cdd3) is generated
Feb/25/2018 21:29:19: set client ID (len 14)
Feb/25/2018 21:29:19: set server ID (len 14)
Feb/25/2018 21:29:19: set IA address
Feb/25/2018 21:29:19: set identity association
Feb/25/2018 21:29:19: set elapsed time (len 2)
Feb/25/2018 21:29:19: set IA_PD prefix
Feb/25/2018 21:29:19: set IA_PD
Feb/25/2018 21:29:19: send request to ff02::1:2%lagg0
Feb/25/2018 21:29:19: reset a timer on lagg0, state=REQUEST, timeo=0, retrans=909
Feb/25/2018 21:29:19: receive reply from fe80::201:5cff:fe86:b046%lagg0 on lagg0
Feb/25/2018 21:29:19: get DHCP option client ID, len 14
Feb/25/2018 21:29:19:   DUID: 00:01:00:01:22:26:0e:58:00:25:00:00:b0:0b
Feb/25/2018 21:29:19: get DHCP option server ID, len 14
Feb/25/2018 21:29:19:   DUID: 00:01:00:01:15:55:76:84:84:2b:2b:fc:9d:17
Feb/25/2018 21:29:19: get DHCP option identity association, len 40
Feb/25/2018 21:29:19:   IA_NA: ID=1, T1=1800, T2=2880
Feb/25/2018 21:29:19: get DHCP option IA address, len 24
Feb/25/2018 21:29:19:   IA_NA address: 2001:558:6004:4:74d5:51a1:76c4:329c pltime=3600 vltime=3600
Feb/25/2018 21:29:19: get DHCP option IA_PD, len 41
Feb/25/2018 21:29:19:   IA_PD: ID=1, T1=1800, T2=2880
Feb/25/2018 21:29:19: get DHCP option IA_PD prefix, len 25
Feb/25/2018 21:29:19:   IA_PD prefix: 2601:881:8000:4750::/64 pltime=3600 vltime=3600
Feb/25/2018 21:29:19: dhcp6c Received REQUEST
Feb/25/2018 21:29:19: make an IA: PD-1
Feb/25/2018 21:29:19: create a prefix 2601:881:8000:4750::/64 pltime=3600, vltime=3600
Feb/25/2018 21:29:19: add an address 2601:881:8000:4750:ae1f:6bff:fe44:a036/64 on igb2
Feb/25/2018 21:29:19: make an IA: NA-1
Feb/25/2018 21:29:19: create an address 2001:558:6004:4:74d5:51a1:76c4:329c pltime=3600, vltime=4088054368887115280
Feb/25/2018 21:29:19: add an address 2001:558:6004:4:74d5:51a1:76c4:329c/128 on lagg0
Feb/25/2018 21:29:19: removing an event on lagg0, state=REQUEST
Feb/25/2018 21:29:19: removing server (ID: 00:01:00:01:15:55:76:84:84:2b:2b:fc:9d:17)
Feb/25/2018 21:29:19: got an expected reply, sleeping.


Unfortunately, pressing "ctrl-c, up, enter", and it does not work the second time right after that, with the same sort of looping like it showed on the first post.

Is it really that unusual to expect dhcpv6 to work on FreeBSD to be able to connect to Comcast?
 
I am just getting back into FreeBSD after more than 15 years. I've become tired of working within the confines of consumer NAS devices.

I did a fresh install of FreeBSD a couple of weeks ago. It took me an inordinate amount of time to realize that the default rc.conf entry to enable IPv4 DHCP was incorrect which resulted in my new FreeBSD not connecting properly. That was corrected by changing the rc.conf entry to "SYNCDHCP". Yes, this should be the default setting in FreeBSD, never mind what grandpa says.

My next challenge was IPv6. I have a dual-stack network with statefull IPv6 DHCP service running on my FW & DHCP server. It has been up and running for a couple of years and works flawlessly issuing IPv4 & IPv6 addresses to a range of devices (Win10, MacOS, iOS, Android, Nest, ATV, etc.). It has taken me some time to understand that while IPv6 has been around for quite a while, it still has not been fully implemented by various software/hardware companies (Android devices do not fully support it. They only support stateless which I find useless).

I came across too few threads about how to setup a working DHCPv6 client in FreeBSD. From my reading it came down to two options; dual-dhclient and dhcpcd. At first blush, dual-dhclient seemed like the logical choice. I managed to find enough information to get started with it. However, no matter what configurations I used it would never work. Not only did IPv6 not work, IPv4 didn't work either. It seemed that the IPv6 using isc-dhclient would interfere with the DHCPv4 so I had no internet although it did get the proper IPv4 & IPv6 addresses. I spent far too much time playing with configurations to try to get this to work. In particular, it seemed that having accept_rtadv for IPv6 in rc.conf killed the DHCPv4. If I removed this part, IPv4 worked fine (internet connection) but IPv6 didn't.

So, I tried dhcpcd. It appealed to me since I understood it to be used by NetBSD for their default DHCP client. It took some playing around with since while there may be man pages about the package, there is nothing to say how to get it running or the corresponding rc.conf lines. With all that said and done, I now have a fully functional dual stack network. My network card gets the proper IPv4 and IPv6 addresses as assigned by my DHCP server. All is well again. The only line I have in my rc.conf file for network devices is:
Code: 
### Set-up IPv4 network through DHCP 
### IPv6 is handled by the dhcpcd package
ifconfig_eth0="SYNCDHCP"                                # Set eth0 interface to sync with IPv4 DHCP server
For added context, this was done on a fresh install of FreeBSD 12 with no other user added packages installed.

Hopefully, this is useful for someone else.
 
Well, in my case, dhcpcd + rtsold was the only solution to this issue.
Code: 
ipv6_activate_all_interfaces="YES"
rtsold_enable="YES"
dhcpcd_enable="YES"
with no ifconfig_xx="inet6 " line in /etc/rc.conf works with both DHCPv6 and RA on FreeBSD 12.1.

Also, I'll upload my Dynamic DNS client sh script for NO-IP + IPv6 + FreeBSD to github.
 
You must log in or register to reply here.
Back
Top