Issues with Classless Static Route Option for DHCP (not fully supported RFC3442)

Sebbo · Oct 22, 2015, 12:15 PM

Hi,

in cooperation with my cloud hoster we've experienced an issue with the "Classless Static Route Option" for DHCP.

The "Classless Static Routing Option" is defined as RFC3442 and is used for configurations regarding the routes:
@IETF/RFC3442:

Classless Route Option Format

The code for this option is 121, and its minimum length is 5 bytes.
This option can contain one or more static routes, each of which
consists of a destination descriptor and the IP address of the router
that should be used to reach that destination.

Code Len Destination 1 Router 1
+–---+---+----+-----+----+----+----+----+----+
| 121 | n | d1 | ... | dN | r1 | r2 | r3 | r4 |
+-----+---+----+-----+----+----+----+----+----+

Destination 2 Router 2
+----+-----+----+----+----+----+----+
| d1 | ... | dN | r1 | r2 | r3 | r4 |
+----+-----+----+----+----+----+----+

In the above example, two static routes are specified.

[…]

DHCP Client Behavior

DHCP clients that do not support this option MUST ignore it if it is
received from a DHCP server. DHCP clients that support this option
MUST install the routes specified in the option, except as specified
in the Local Subnet Routes section. DHCP clients that support this
option MUST NOT install the routes specified in the Static Routes
option (option code 33) if both a Static Routes option and the
Classless Static Routes option are provided.

DHCP clients that support this option and that send a DHCP Parameter
Request List option MUST request both this option and the Router
option [4] in the DHCP Parameter Request List.

DHCP clients that support this option and send a parameter request
list MAY also request the Static Routes option, for compatibility
with older servers that don't support Classless Static Routes. The
Classless Static Routes option code MUST appear in the parameter
request list prior to both the Router option code and the Static
Routes option code, if present.

If the DHCP server returns both a Classless Static Routes option and
a Router option, the DHCP client MUST ignore the Router option.

Similarly, if the DHCP server returns both a Classless Static Routes
option and a Static Routes option, the DHCP client MUST ignore the
Static Routes option.

After deriving a subnet number and subnet mask from each destination
descriptor, the DHCP client MUST zero any bits in the subnet number
where the corresponding bit in the mask is zero. In other words, the
subnet number installed in the routing table is the logical AND of
the subnet number and subnet mask given in the Classless Static
Routes option. For example, if the server sends a route with a
destination of 129.210.177.132 (hexadecimal 81D4B184) and a subnet
mask of 255.255.255.128 (hexadecimal FFFFFF80), the client will
install a route with a destination of 129.210.177.128 (hexadecimal
81D4B180).

Our issue was, that pfSense wasn't able to set the default route with the correct IP address and the result of it was, that pfSense wasn't able to reach any host, because any ping returned "No route to host". (The default route was just missing in the "netstat -rn" output.)

Public WAN IP addresses are reserved to specific MAC addresses by their DHCP server. Each client will receive it's IP with a default /32 subnet mask, while the router is always the x.x.x.1.

Example (with private IPs):
Client IP: 192.168.2.123/32
Router for this client: 192.168.2.1

It's confusing, but it works, if I configure it with following commands manual:

ifconfig vtnet0 192.168.2.123 255.255.255.255
route add default 192.168.178.1

I've added those lines in the /etc/rc.conf to load this configuration after a reboot.

My cloud hoster checked this issue and said, that the package "isc-dhcp43-client" would solve all those issues.

I also have a suggestion regarding the console configuration for IP addresses: Please add the option to set a /32 subnet mask for IP addresses. Regarding the above explained situation it also would be better to not validate, if the gateway IP address is within the provided subnet of the NICs IP address. Or you just don't validate the gateway, if the subnet mask of the IP address is /32.

Hope, you can fix this issue as soon as possible. For further information, please don't hesitate to contact me.

rubic · Oct 26, 2015, 4:10 AM

Hi, pfSense seems to work fine with option 121. As far as I can see, your scenario is so-called "foreign gateway" within the same shared medium. Thereby the hoster should provide not only gateway IP with DHCP option 121 but also "SameSM" route to the gateway.

For example, assuming gateway IP is 203.0.113.1, 121-option data looks like this: 20:cb:00:71:01:00:00:00:00:00:cb:00:71:01

Here:

20:cb:00:71:01:00:00:00:00 means 203.0.113.1/32 via 0.0.0.0 - "SameSM" or "On-Link" route to the gateway
00:cb:00:71:01 means 0.0.0.0 via 203.0.113.1 - default route

As a result, RT of the pfSense box recieved the data is:

Can you share full detail packet capture of the DHCP ACK the hoster sends to you?

PS sorry for bad english

Sebbo · Oct 28, 2015, 7:48 PM

Thanks for your answer!

I've forwarded your answer to the network team of my provider and they told me, that this isn't supported.

Well… Ok, it's no issue of pfSense. Great! :)

#Closed