Skip to main content

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

Document Type Active Internet-Draft (individual)
Authors David Lamparter , Tobias Fiebig
Last updated 2024-10-21
Replaces draft-equinox-intarea-route4via6
RFC stream (None)
Intended RFC status (None)
Formats
Additional resources GitHub Repository
GitHub Username: eqvinox
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-equinox-intarea-dhcpv4-route4via6-00
Internet Area Working Group                                 D. Lamparter
Internet-Draft                                              NetDEF, Inc.
Intended status: Experimental                                  T. Fiebig
Expires: 24 April 2025                                           MPI-INF
                                                         21 October 2024

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

Abstract

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

   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.

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 24 April 2025.

Copyright Notice

   Copyright (c) 2024 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 24 April 2025                 [Page 1]
Internet-Draft          intarea-dhcpv4-route4via6           October 2024

   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.  Expected host behavior  . . . . . . . . . . . . . . . . . . .   3
     3.1.  Overlapping routes  . . . . . . . . . . . . . . . . . . .   3
     3.2.  Default route . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Routes clashing with the connected subnet . . . . . . . .   4
   4.  DHCP Option encoding  . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Route encoding  . . . . . . . . . . . . . . . . . . . . .   5
   5.  YANG model  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Example encoded options . . . . . . . . . . . . . . . . . . . . .   8
   Editing notes (TO BE REMOVED) . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   // more intro TBA

   // DHCP is likely handing out individual IPv4 addresses, i.e. the
   // subnet mask is /32 when this mechanism is relevant.

   // To preempt any misunderstanding, this is an *IPv4 DHCP* option.
   // *NOT a DHCPv6 option*.

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

   A particularly interesting scenario enabled by the extension
   described here is the complete removal of IPv4 addresses from first-
   hop routers acting as DHCP 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
   [DHCPv6] with the [DHCP4o6] transport method.  Since this mechanism
   encapsulates IPv4 DHCP messages, all related IPv4 configuration can
   be carried - but notably there is no way to encode an IPv6 default
   gateway or other route.

   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.

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.  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 this function MUST ignore the
   option described in this document and behave as before.

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

3.1.  Overlapping routes

   [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:

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

   *  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.

3.2.  Default route

   The default route is expressed here as a route for 0.0.0.0/0.  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.

3.3.  Routes clashing with the connected subnet

   // TODO: determine what behavior is reasonable here.  (The client is
   // likely to be given a /32 subnet mask anyway.)

4.  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    |             Routes            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   :                              ...                              :

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

   Length  as defined in [DHCP-OPT]

   Routes  One or more routes encoded as described below.  DHCP Servers

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

      MUST NOT emit this option with an empty payload.  DHCP clients
      MUST ignore this option if its length is zero.

      It is easily possible for encoded routes and their nexthops to
      exceed the encodable size of 255 bytes.  This is addressed by
      applying the mechanism specified in [DHCP-LONGOPT]; both clients
      and servers MUST follow the procedure described there when
      implementing the option described in this document.

4.1.  Route 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
   +-+-+-+-+-+-+-+-+
   | T | prefixlen |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    IPv4 prefix (0 - 4 octets)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 IPv6 nexthop (0, 8 or 16 octets)              |
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   T  Determines the function and nexthop encoding for this route.
      Valid values and their meanings are:

      // This encoding mechanism might be excessive.  The original
      // motivation was to have a way to tell the client that it should
      use
      // the relay's link-local address as next-hop.  Filling that in
      from
      // the DHCP server is annoying, since the server has otherwise no
      // need to know that address.  It's not a problem if the operator
      // configures a fixed LL on all routers (e.g. fe80::1), but
      without
      // that each router would just be using its autoconf'd LL.
      // Having an encoding for 'unreachable' routes and a shorthand for
      // link-local addresses is really just "fluff" too.

   T = 0 - use DHCP packet source  Indicates that this route 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?

      The IPv6 nexthop field for this route has zero length.

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

   T = 1 - unreachable destination  Indicates that the destination
      prefix specified by this route is unreachable.  More specific
      destination prefixes may still be reachable.

      TODO: specify fault mix (unreachable+reachable)

      The IPv6 nexthop field for this route has zero length.

   T = 2 - link-local IPv6 nexthop  Indicates that this route uses a
      link-local IPv6 nexthop address, encoding only the latter 8 bytes
      of the address for space efficiency.  The upper 8 bytes of the
      address are filled in with fe80::.

      The IPv6 nexthop field for this route is 8 octets long.

   T = 3 - generic IPv6 nexthop  Indicates that this route uses the
      specified IPv6 nexthop, encoding the full address.  The encoded
      address may be any type of unicast IPv4 address, including GUA,
      ULA and LL.

      The IPv6 nexthop field for this route is 16 octets long.

   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.  Calculate as
      ceil(prefixlen / 8).

   IPv6 nexthop  encoding as determined by T

5.  YANG model

   _TBD if needed_

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 option described in Section 4.
   // Editor note: 2 places of TBA1

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

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>.

   [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-01, 8
              July 2024, <https://datatracker.ietf.org/doc/html/draft-
              chroboczek-intarea-v4-via-v6-01>.

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>.

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

   [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>.

Acknowledgements

   _TBD, FILL IN_

Example encoded options

      (TBA) 01 00

      A single default route (0.0.0.0/0) using the DHCP packet's source
      address as nexthop.

      (TBA) 0a 88 0a 00 00 00 00 00 00 00 01

      A single route for 10.0.0.0/8 via fe80::1.

      (TBA) 15
      40
      d8 c0 00 02 20 01 0d b8 12 34 56 78 00 00 00 00 00 00 00 00

      A route marking 0.0.0.0/0 as unreachable, and another route for
      192.0.2.0/24 via 2001:db8:1234:5678::.

Editing notes (TO BE REMOVED)

   *  -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 24 April 2025                 [Page 8]