[inet6] recognize unknown router advertisement options

[evverx]

According to https://www.rfc-editor.org/rfc/rfc4861.html#section-4.6

All options are of the form:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     |              ...              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where

      Length         8-bit unsigned integer.  The length of the option
                     (including the type and length fields) in units of
                     8 octets.

This patch makes it possible to recognize/generate unknown options by introducing a new field where lengths are calculated according to the RFC and options are padded with zeroes if necessary. By default trailing zeroes aren't stripped to make it easier to process options where trailing zeroes can be mixed up with actual data (like the encrypted DNS option for example). The captive portal option was switched to the new field too but there trailing zeroes are still stripped.

fuzz(ICMPv6NDOptUnknown(type=...)) is much more effective now because it generates options valid enough to get past basic checks but nonsensical enough to trigger interesting issues like
systemd/systemd#30952 (comment)
systemd/systemd#30952 (comment)

ICMPv6NDOptUnknown is also used instead of Raw to guess payloads so router advertisements can be parsed even when unknown options pop up in the middle.

The patch was also cross-checked with Wireshark:

>>> tdecode(Ether()/IPv6()/ICMPv6ND_RA()/ICMPv6NDOptSrcLLAddr()/ICMPv6NDOptUnknown(data='watwatwat')/ICMPv6NDOptCaptivePortal())
...
    ICMPv6 Option (Source link-layer address : 00:00:00:00:00:00)
        Type: Source link-layer address (1)
        Length: 1 (8 bytes)
        Link-layer address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    ICMPv6 Option (Unknown 0)
        Type: Unknown (0)
        Length: 2 (16 bytes)
        [Expert Info (Note/Undecoded): Dissector for ICMPv6 Option (0) code not implemented, Contact Wireshark developers if you want this supported]
            [Dissector for ICMPv6 Option (0) code not implemented, Contact Wireshark developers if you want this supported]
            [Severity level: Note]
            [Group: Undecoded]
        Data: 7761747761747761740000000000
    ICMPv6 Option (DHCP Captive-Portal)
        Type: DHCP Captive-Portal (37)
        Length: 1 (8 bytes)
        Captive Portal:

[evverx]

The CI seems to be failing because cryptography switched to Rust in pyca/cryptography@ba9131e and the _p attribute was removed. I pinned it to 41.0.7 in evverx#2 and all the tests passed there.

[codecov]

Codecov Report

Merging #4233 (14f928f) into master (ae79fcb) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4233      +/-   ##
==========================================
- Coverage   81.77%   81.76%   -0.01%     
==========================================
  Files         331      331              
  Lines       76716    76722       +6     
==========================================
  Hits        62731    62731              
- Misses      13985    13991       +6     

Files	Coverage Δ
scapy/layers/inet6.py	88.58% <100.00%> (+0.03%)	⬆️

... and 6 files with indirect coverage changes

[guedou]

Really cool PR! Thanks.

[evverx]

I think it would maybe be useful if the known options that can't be parsed properly turned into ICMPv6NDOptUnknown or something like that by analogy with tshark showing options and their bytes. One recent example where it could have helped would be https://lists.debian.org/debian-security-announce/2024/msg00123.html (which was (partly) powered by scapy FWIW). I'll try to figure out if it makes sense.