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

[Sebbo]

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]

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]

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