DHCPv4 Option for IPv4 routes with IPv6 nexthops
draft-equinox-intarea-dhcpv4-route4via6-01

Internet Area Working Group                                 D. Lamparter
Internet-Draft                                              NetDEF, Inc.
Intended status: Experimental                                  T. Fiebig
Expires: 25 October 2025                                         MPI-INF
                                                           23 April 2025

            DHCPv4 Option for IPv4 routes with IPv6 nexthops
               draft-equinox-intarea-dhcpv4-route4via6-01

Abstract

   As a result of the shortage of IPv4 addresses, installations are
   increasingly recovering IPv4 addresses from uses where they are not
   strictly necessary.  One such situation is in establishing next hops
   for IPv4 routes, replacing this use with IPv6 addresses.  This
   document describes how to provision DHCP-configured hosts with their
   routes in such a situation.

   // This draft lives at https://github.com/eqvinox/dhc-route4via6

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 25 October 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights

Lamparter & Fiebig       Expires 25 October 2025                [Page 1]
Internet-Draft          intarea-dhcpv4-route4via6             April 2025

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Extended static route function  . . . . . . . . . . . . . . .   3
     3.1.  Applicable next-hop behavior  . . . . . . . . . . . . . .   4
     3.2.  Applicable destination prefix behavior  . . . . . . . . .   5
   4.  Expected host behavior  . . . . . . . . . . . . . . . . . . .   6
     4.1.  Singular address assignment . . . . . . . . . . . . . . .   6
     4.2.  Overlapping routes from other sources . . . . . . . . . .   6
     4.3.  Default route . . . . . . . . . . . . . . . . . . . . . .   7
     4.4.  Routes clashing with the connected subnet . . . . . . . .   7
   5.  DHCP Option encoding  . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Destination prefix  . . . . . . . . . . . . . . . . . . .   8
     5.2.  Next-hop  . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Example encoded options . . . . . . . . . . . . . . . . . . . . .  11
   Revision history (TO BE REMOVED)  . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   IPv4 is currently (and will likely be for some time) in a situation
   where IPv4 addresses are in short supply, but services still need to
   be made available to users that do not yet have IPv6 connectivity.
   In some cases, even the service side may not have IPv6 support yet.
   In other cases some aspect of the service precludes using proxy-style
   service delivery with translation technologies on either or both
   sides.  This leads to a need for fine-grained deployment of IPv4
   connectivity with minimum wastage of addresses.

   A particularly interesting improvement enabled by the extension
   described here is the complete removal of IPv4 addresses from first-
   hop routers acting as DHCPv4/v6 relays, while still providing IPv4
   connectivity.  In this scenario, the relay (assumed colocated with
   the router) has no IPv4 address to use to communicate with the
   client.  An almost-working solution for this case is presented by

Lamparter & Fiebig       Expires 25 October 2025                [Page 2]
Internet-Draft          intarea-dhcpv4-route4via6             April 2025

   [DHCPv6] with the [DHCP4o6] transport method.  Since this mechanism
   encapsulates IPv4 DHCP messages, all related IPv4 configuration can
   be carried.  However, DHCPv4 does not support a way to encode an IPv6
   default gateway or other routes, which is necessary in this case.

   If the router and relay are not co-located, the relay may have an
   IPv4 address while the router does not.  In this case, the option
   described in this document could be carried in a plain IPv4 DHCP
   message.

   Note that the changes described in this document are to DHCPv4, not
   DHCPv6.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Extended static route function

   This document defines a DHCPv4 option container with 2 suboptions for
   use within it.  The container can occur multiple times, and the
   suboptions can each occur zero, one, or multiple times in each
   container.  Each container represents one "fully-filled matrix" of
   destination prefixes and next-hops, i.e. to be interpreted as a full
   cartesian combination of the two sets.  In detail, this means:

   1.  each option container is processed as one unit, building up a
       list of destination prefixes and next-hops.  It is expected that
       the container will in most cases present one destination prefix
       with one or two next-hops.  However, DHCPv4 clients processing
       the option MUST support processing multiple destination prefix
       suboptions.
       // *NB/TODO: this implies [DHCP-LONGOPT] is NOT applicable here.
       Not
       // sure if that's a good idea.*

   2.  when multiple destination prefixes occur in the same container,
       all of the next-hops for that container MUST be processed for all
       of the destination prefixes in that container.

   3.  if no destination prefix sub-option occurs in a container, the
       IPv4 default route (0.0.0.0/0) is implicitly expressed and the
       container MUST be processed as if the 0.0.0.0/0 destination
       prefix was explicitly encoded.

Lamparter & Fiebig       Expires 25 October 2025                [Page 3]
Internet-Draft          intarea-dhcpv4-route4via6             April 2025

   4.  if no next-hop sub-option occurs in a container, the "source of
       DHCP packet" function is encoded as with the unspecified-address
       (::) next-hop described below.  The container MUST be processed
       as if a :: next-hop were explicitly encoded.

   5.  both sub-options may be absent, the rules in the previous two
       bullet points MUST be applied in combination.  This is in fact
       expected to be a relatively common setup and is intentionally
       made available with a space-preserving encoding.

   6.  the container can be repeated an arbitrary number of times with
       different suboptions.  Any single destination prefix MUST NOT be
       expressed in more than one container.  If encountering duplicate
       destination prefixes, clients MAY pick one at random, or MAY
       merge nexthops; but this is considered a network side
       configuration error.  However, note that this refers only to
       repeating the exact same destination prefix and prefix length.  A
       differing prefix length presents a distinct destination prefix
       and MUST be processed independently.

   7.  next-hops MUST NOT repeat within the same container, but the same
       next-hop MAY occur in any number of containers and MUST be
       processed normally in that case.

   8.  if multiple next-hops are expressed in the same container, this
       represents equal-cost multipath routes across the set of next-
       hops.  Clients processing the option MUST install at least one of
       the listed nexthops but MAY choose any subset at their
       discretion, e.g.  if their capability of installing ECMP is
       limited to some number of next-hops (or is 1, i.e. no ECMP
       support.)

3.1.  Applicable next-hop behavior

   Outlined in [IANA-IPv6], not all IPv6 addresses are valid for use
   when encoded as next-hop and some have specific functionality
   [IANA-IPv6-SPECIAL] attached to them as follows:

   1.  the unspecified-address nexthop (which is also implied by the
       absence of any nexthop suboption) indicates that the routes in
       the container should use the DHCP packet's source address as
       nexthop.  When [DHCP4o6] is in use, hosts MUST retrieve the IPv6
       source address of the DHCPv6 packet carrying the DHCPV4-RESPONSE
       message.
       // TODO: does it really make sense to support IPv4 here?  Maybe
       only
       // allow this with DHCP4o6?

Lamparter & Fiebig       Expires 25 October 2025                [Page 4]
Internet-Draft          intarea-dhcpv4-route4via6             April 2025

   2.  the Discard-Only Address block (0100::/64) [DISCARD] MAY be used
       to express unreachable destinations, in particular if only
       limited but not global IPv4 connectivity is available.  If this
       is used, it MUST be the only next-hop suboption in one container,
       clients SHOULD ignore the entire container if this is not
       respected.  If a client is unable to mark destinations as
       unreachable in its routing table, it MAY ignore the container and
       SHOULD indicate a client configuration issue in its
       administrative interfaces.

   3.  any unicast IPv6 address MAY be used as next-hop.  This
       specifically also covers link-local addresses, which the client
       MUST support and MUST associate with the link that it has
       received the DHCP packets on.

   4.  // TODO: is ::ffff:192.0.2.123 an IPv4 nexthop?  Is this worth
       // supporting explicitly, and then saying that the other static
       route
       // / default gateway options should be ignored?

   5.  the following types/ranges of addresses are invalid and MUST NOT
       be used; no client behavior is specified if any are present in a
       container:

       *  the loopback address (::1)
          // TODO: express other directly-connected IPv4 hosts with
          this?

       *  any multicast address (ff00::/8)

       *  any address with a reserved allocation

3.2.  Applicable destination prefix behavior

   Some IPv4 prefixes, due to their function given in [IANA-IPv4], do
   not make sense to use with this option.  DHCPv4 servers MUST NOT
   encode and DHCPv4 clients MUST ignore the following prefixes as well
   as any more-specific prefixes within them:

   *  0.0.0.0/8 (note that 0.0.0.0/0 is less specific than this, and
      thus valid)

   *  127.0.0.0/8

   *  224.0.0.0/4

   *  255.255.255.255/32

Lamparter & Fiebig       Expires 25 October 2025                [Page 5]
Internet-Draft          intarea-dhcpv4-route4via6             April 2025

   Behavior for 240.0.0.0/4 is outside the scope of this document.

4.  Expected host behavior

   The option described in this document is intended to be implemented
   on hosts supporting IPv4 routes with IPv6 nexthops as described in
   [v4overv6].  Hosts that do not support the behavior described there
   MUST NOT request and MUST ignore the option described in this
   document.

   Hosts that support [v4overv6] behavior and acquire their
   configuration from [DHCP] SHOULD implement the option described here.

4.1.  Singular address assignment

   While not limited to this case, this option is expected and intended
   to be used with assigning a singular IPv4 address to a DHCPv4 client.
   This implies that the Subnet Mask option defined in [DHCP-OPT] will
   have the value 255.255.255.255.

   DHCPv4 clients implementing the option described in this document
   MUST process such a Subnet Mask option value as assigning a single
   address.  There is no network or broadcast address for this "single-
   sized" pseudo-subnet.  No IPv4 addresses are expressed to be on-link
   for the purposes of [ARP] (though they MAY become so due to
   additional, e.g. local configuration assigning additional addresses
   to the interface.)

   Whether the address is bound to the interface or host (strong vs.
   weak host model), and whether to perform or skip [DADv4] for the
   address is beyond the scope of this document.

4.2.  Overlapping routes from other sources

   [RFC3442] documents a mechanism to communicate a set of routes and
   their nexthops over DHCP.  The original DHCP "router" option (code 3)
   may communicate a default router.  If either of these options is
   used, the routes communicated may overlap.

   To get consistent and unsurprising behavior, this document places the
   follwing expectations on the host:
   // TODO: redundant paragraph/merge with text above, needs some
   // merging/editing.

Lamparter & Fiebig       Expires 25 October 2025                [Page 6]
Internet-Draft          intarea-dhcpv4-route4via6             April 2025

   *  Routes that describe distinct destination prefixes MUST be handled
      independently.  This includes routes that differ only in prefix
      length.  As a result, the routing table MAY contain a mix of IPv4
      routes with IPv4 nexthops as well as IPv6 nexthops.  Standard
      longest prefix match behavior MUST be observed.

   *  If routes with the same destination prefix are described both with
      previously existing methods as well as the options documented
      here, the route described by the latter MUST be used and the
      routes with IPv4 nexthops MUST be discarded.  This notably
      includes "unreachable" routes described here; a route with an IPv4
      nexthop for such a destination MUST still be discarded.

   *  Multiple routes for the same destination prefix with different
      nexthops of the same address family SHOULD be combined into a
      single route for equal-cost multipath behavior, if the host
      supports this.  If ECMP routes are not supported, the host MUST
      deterministically choose one of the routes.  This MAY be done by
      using the first or last option as seen in DHCP packet order, or by
      choosing the numerically lowest or highest nexthop.

4.3.  Default route

   The default route is expressed here as a route for 0.0.0.0/0, which
   is also implied by the absence of any destination prefix suboption.
   There is no distinct special encoding for a default gateway, any
   nexthop for 0.0.0.0/0 MUST be treated as if it were a default
   gateway.

4.4.  Routes clashing with the connected subnet

   // (only applicable if NOT assigning a single IPv4 address as /32)
   // TODO: determine what behavior is reasonable here.  (The client is
   // likely to be given a /32 subnet mask anyway.)

5.  DHCP Option encoding

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type (TBA1)  |     Length    |          Suboptions           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   :                              ...                              :

   Type  TBA1 (field defined in [DHCP-OPT])

   Length  as defined in [DHCP-OPT]

Lamparter & Fiebig       Expires 25 October 2025                [Page 7]
Internet-Draft          intarea-dhcpv4-route4via6             April 2025

   Suboptions  zero or more suboptions as defined below

5.1.  Destination prefix

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type = 1   |     Length    | R | prefixlen |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    IPv4 prefix (0 - 4 octets)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type  1

   Length  as defined in [DHCP-OPT]

   R  Reserved bits.  MUST be sent as zero, MUST be ignored on receipt.

   prefixlen  IPv4 prefix length, integer value from 0 to 32 (inclusive)

   IPv4 prefix  The route's destination prefix, encoded in as few bytes
      necessary for the given prefixlen value, i.e. calculate length as
      ceil(prefixlen / 8).
      // TODO: maybe just ditch minimum length encoding, make it match
      // other DHCPv4 bits?

      Valid values are described in Section 3.2.

   If the Length field indicates additional data past the IPv4 prefix
   value, clients MUST ignore it.  Future documents MAY introduce other
   behavior here and servers MUST NOT send any such data until such a
   point.

5.2.  Next-hop

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type = 2   |     Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  IPv6 addresses (n*16 octets)                 |
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type  2

   Length  as defined in [DHCP-OPT], a multiple of 16.

Lamparter & Fiebig       Expires 25 October 2025                [Page 8]
Internet-Draft          intarea-dhcpv4-route4via6             April 2025

   IPv6 addresses  One or more IPv6 addresses specifying the nexthop for
      this route.  Refer to Section 3.1 for valid values and associated
      behavior.
      // TODO: is this a list, or do we just repeat the suboption?  In
      // theory, this could have sub-suboptions, but unlikely to need?

6.  Security Considerations

   _TBD_

7.  Privacy Considerations

   _TBD_

8.  IANA Considerations

   A codepoint from the "BOOTP Vendor Extensions and DHCP Options"
   registry is requested for use with the container option described in
   Section 5.
   // Editor note: 2 places of TBA1

   A registry is requested to be created for the sub-options in the
   option above.
   // TBD: proper wording for this, and fill in values 1 & 2

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [DHCP]     Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2131>.

   [DHCP-OPT] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2132>.

Lamparter & Fiebig       Expires 25 October 2025                [Page 9]
Internet-Draft          intarea-dhcpv4-route4via6             April 2025

   [DHCP-LONGOPT]
              Lemon, T. and S. Cheshire, "Encoding Long Options in the
              Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
              DOI 10.17487/RFC3396, November 2002,
              <https://www.rfc-editor.org/rfc/rfc3396>.

   [v4overv6] Chroboczek, J., Kumari, W. A., and T. Høiland-Jørgensen,
              "IPv4 routes with an IPv6 next hop", Work in Progress,
              Internet-Draft, draft-chroboczek-intarea-v4-via-v6-03, 20
              January 2025, <https://datatracker.ietf.org/doc/html/
              draft-chroboczek-intarea-v4-via-v6-03>.

   [DISCARD]  Hilliard, N. and D. Freedman, "A Discard Prefix for IPv6",
              RFC 6666, DOI 10.17487/RFC6666, August 2012,
              <https://www.rfc-editor.org/rfc/rfc6666>.

   [IANA-IPv4]
              IANA, "IPv4 Address Space Registry",
              <https://www.iana.org/assignments/ipv4-address-space/>.

   [IANA-IPv6]
              IANA, "Internet Protocol Version 6 Address Space",
              <https://www.iana.org/assignments/ipv6-address-space/>.

   [IANA-IPv6-SPECIAL]
              IANA, "IPv6 Special-Purpose Address Registry",
              <https://www.iana.org/assignments/iana-ipv6-special-
              registry/>.

9.2.  Informative References

   [RFC3442]  Lemon, T., Cheshire, S., and B. Volz, "The Classless
              Static Route Option for Dynamic Host Configuration
              Protocol (DHCP) version 4", RFC 3442,
              DOI 10.17487/RFC3442, December 2002,
              <https://www.rfc-editor.org/info/rfc3442>.

   [DHCPv6]   Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,
              <https://www.rfc-editor.org/info/rfc8415>.

   [DHCP4o6]  Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
              Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
              RFC 7341, DOI 10.17487/RFC7341, August 2014,
              <https://www.rfc-editor.org/info/rfc7341>.

Lamparter & Fiebig       Expires 25 October 2025               [Page 10]
Internet-Draft          intarea-dhcpv4-route4via6             April 2025

   [ARP]      Plummer, D., "An Ethernet Address Resolution Protocol: Or
              Converting Network Protocol Addresses to 48.bit Ethernet
              Address for Transmission on Ethernet Hardware", STD 37,
              RFC 826, DOI 10.17487/RFC0826, November 1982,
              <https://www.rfc-editor.org/rfc/rfc826>.

   [DADv4]    Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
              DOI 10.17487/RFC5227, July 2008,
              <https://www.rfc-editor.org/rfc/rfc5227>.

Acknowledgements

   The authors would like to acknowledge and thank Tomek Mrugalski for
   very extensive comments, and in particular pointing out the proper
   way to use DHCP options.

   Comments and feedback has been received and appreciated from Ole
   Troan.

Example encoded options

   _TBD: outdated examples removed, will be re-added_

Revision history (TO BE REMOVED)

   *  -01: scrap single-option encoding, use container instead, and
      reference special-purpose IPv6 addresses (e.g. for discard)

   *  -00:

Authors' Addresses

   David 'equinox' Lamparter
   NetDEF, Inc.
   San Jose,
   United States of America
   Email: equinox@diac24.net, equinox@opensourcerouting.org

   Tobias Fiebig
   Max-Planck-Institut fuer Informatik
   Campus E14
   66123 Saarbruecken
   Germany
   Phone: +49 681 9325 3527
   Email: tfiebig@mpi-inf.mpg.de

Lamparter & Fiebig       Expires 25 October 2025               [Page 11]