RouterSolicit with no options generates an error

[leshow]

A pcap from my network shows that router solicitations are sent with no options.

If I construct a RouterSolicit packet with the pnet lib however, leaving the options field empty leads to an invalid message.

This message is constructed with:

 let adv = ndp::RouterSolicit {
            icmpv6_type: Icmpv6Types::RouterSolicit,
            icmpv6_code: Icmpv6Code(0),
            checksum: 0,
            options: Vec::new(),
            reserved: 0,
            payload: Vec::new(),
};

wireshark shows it as an error

[stappersg]

And what should be the outcome of this issue?

[leshow]

Right, sorry. The options section is a variable length block at the end of the packet, in the good screenshot there are no options and the packet ends after the reserved bytes. In the pnet case the options section exists with an option of type Unknown(0) and then length 0.

Router solicitations sometimes have a link-layer address included in the options section, but according to the RFC this is not always the case.

Valid Options:
Source link-layer address The link-layer address of the sender, if
known. MUST NOT be included if the Source Address
is the unspecified address. Otherwise, it SHOULD
be included on link layers that have addresses.
https://www.rfc-editor.org/rfc/rfc4861#section-4.1

I would be open to fixing this but would need some direction, I have not touched the source yet.

edit: Make this what you will, but in practical testing, the malformed packet won't get a router advertisement response from my router. If I include an option, I get a response. It could be a red herring because this code is very rough, but some evidence that this produces an incorrect packet.

It is likely this is also an issue with other NDP types like RouterAdvert or NeighbourSolicit/Advert but I haven't specifically tried

[stappersg]

What I think:

• It is fine that libpnet allows to do stupid things as sending empty packets.
• It is great that libpnet doesn't prevent doing smart things.
• This issue will linger for a long time. (Please prove me wrong.)

[leshow]

Rather than being a "stupid thing", the sending of a packet with no options data should be expected, that is how the protocol works as far as I know

The issue is that libpnet creates an incorrect packet when the options field is empty. We should be able to create a router solicit with no data in the opts section, but instead an option is added with a type of 0 and a length of 0 (see the second screenshot). I don't think there is anything super complicated going on here. It is just a bug, I think.