pfSense

See original issue #9634

Martin Wasley wrote:

just to put you right on this Jim as there seems some confusion. The REQUEST you see in the ENV VAR REASON is just dhcp6c saying it's received a reply to ITS request message to the server. It's not saying I have received a REQUEST message. This is an example sequence:

• Client sends a solicit from [fe80::aabb:ccff:fedd:eeff]:546 to [ff02::1:2]:547. (Client messages are sent to the multicast address, per section 14 of RFC 8415.)
• Server replies with an advertise from [fe80::0011:22ff:fe33:5566]:547 to [fe80::aabb:ccff:fedd:eeff]:546.
• Client replies with a request from [fe80::aabb:ccff:fedd:eeff]:546 to [ff02::1:2]:547.
• Server finishes with a reply from [fe80::0011:22ff:fe33:5566]:547 to [fe80::aabb:ccff:fedd:eeff]:546.

It’s when dhcp6c receives the ‘reply’ message that it runs the script and sets the env var ‘REASON’ to ‘REQUEST’ meaning it’s received a reply to ITS request message, this is when you see 'REQUEST' in the logs.

I tested this issue in more detail and can confirm it.
REASON=REQUEST means that dhcp6c received a reply to ITS request message (i.e. request function != false)
for example, you'll never see REQUEST in REASON if you put another dhcp6c client on the WAN side
The original issue seems caused by buggy/misconfigured DHCP6 server (or DHCP6 server flooding/spoofing)