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



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



  • 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



  • 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


Log in to reply