| Internet-Draft | dhc-route4via6 | July 2024 |
| Lamparter & Fiebig | Expires 24 January 2025 | [Page] |
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.¶
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 January 2025.¶
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 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.¶
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. ¶
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.¶
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.¶
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.¶
[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:¶
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.¶
TODO: determine what behavior is reasonable here. (The client is likely to be given a /32 subnet mask anyway.) ¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : ... :¶
One or more routes encoded as described below. DHCP Servers 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 allowing multiple occurences of this option. DHCP clients MUST process all instances of this option additively. DHCP servers MAY encode configured routes in as many instances of this option as they choose; they SHOULD however ideally choose a space-efficient 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) | : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
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. ¶
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.¶
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.¶
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.¶
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.¶
TBD if needed¶
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¶
TBD, FILL IN¶