DHCPv4 Option for IPv4 routes with IPv6 nexthops

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

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

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¶