Feature request to support IPv6-only Preferred DHCPv4 Option
name: IPv6-only Preferred DHCPv4 Option
about: Adding Option 108 support (draft-ietf-dhc-v6only) to the DHCP clientSome initial questions The draft-ietf-dhc-v6only is with RFC Editors and will be published as an RFC soon. The IANA allocated the option code 108 recently. AFAIK the ISC DHCP client does not support that option yet. The draft-ietf-dhc-v6only was produced by IETF DHC Working Group.
Is your feature request related to a problem? Please describe. While migrating a network to IPv6-only mode, it might be still required to keep some devices dual-stack still. Separating IPv6-only and dual-stack hosts into different network segment does not scale very well and introduces other challenges. It's rather desirable to allow IPv6-only and dual-stack devices to coexist on the same network segment, and provide IPv4 addresses via DHCPv4 only to hosts which really need IPv4 connectivity. So what we need is a way for a host which can operate in IPv6-only mode to signal its IPv6-only readiness to the DHCPv4 server. More details could be found in draft-ietf-dhc-v6only
Describe the solution you'd like The client which is willing to be IPv6-only includes the Option 108 into the PRL. If the server does not support it or the network segment does not provide IPv6-only connectivity, the server does not include the option in the response and the normal DHCPv4 process happens. So the client would receive IPv4 address. However if the network segment is IPv6-only and the server is configured to respond with the Option 108, the server includes the option into DHCPOFFER or DHCPACK. When the client receives the option 108 back, it should stop DHCPv4 process for some time. More details could be found in:
Describe alternatives you've considered While it's possible to achieve the similar results by silently discarding DHCPv4 packets from IPv6-only capable hosts, that approach has a serious drawback: the client never stops asking, so the load on the DHCP infrastructure increases.
Additional context N/A
Funding its development See below
Participating in development While I'm not really proficient at writing C code and I'm not familiar with the ISC codebase, I'm happy to participate. Willing to test the client code indeed.
Contacting you Email or Hangouts: furry13@gmail.com