So this is a little bit embarrassing given that I just did my AD review of this document, but the way the DHCP options were done violates the recommendation in the DHCPv6 Option Guidelines document (RFC 7227) in that it uses suboption codes for the 4RD_MAP_RULE and 4RD_NON_MAP_RULE options, instead of treating OPTION_4RD as an encapsulating option, and the other two options as encapsulated options (see section 9 of RFC 7227).
o One DHCPv6 option codes TBD1 for OPTION_4RD of Section 4.9
respectively (to be added to section 24.3 of [RFC3315]. Suboption
values of 4RD_MAP_RULE (0) and 4RD_NON_MAP_RULE (1) should also be
recorded into the DHCPv6 option code space.
Also, the suboption configuration is expressed as a server requirement, when it's actually an operational requirement:
OLD:
o 4rd rule suboptions: the 4RD DHCPv6 option SHOULD contain at least
one 4RD_MAP_RULE suboption and maximum one 4RD_NON_MAP_RULE
suboption. the length of suboptions in octets
NEW:
o 4rd rule suboptions: the 4RD DHCPv6 option contains at least
one 4RD_MAP_RULE suboption and maximum one 4RD_NON_MAP_RULE
suboption. Since DHCP servers normally send whatever options
the operator configures, operators should be advised to
configure these options appropriately. DHCP servers MAY
check to see that the configuration follows these rules and
notify the operator in an implementation-dependent manner
if the settings for these options aren't valid.