feat: added hsrpv2 support layer

[pengsies]

context

hi! This is my first pull request to an open-source project, so please let me know if there is anything I should adjust.

so while working with HSRP packet building for a poc in my uni's hsrp network security project, i noticed that scapy’s existing hsrp layer supports the classic hsrpv1 packet format, but not the tlv-based format of hsrpv2. of course, because Scapy does not currently expose a native hsrpv2 layer, this means that packets of that nature would have to be constructed manually as raw udp payloads which was what i did. for example, the group state tlv and text authentication tlv need to be packed manually before being attached as Raw(load=...).. but in any case, i thought that it would be neat if ____, so i ____.
thought it would be useful for Scapy to support hsrpv2 directly, which resulted in this small contribution :D

tldr; PR adds a hsrpv2 support layer without changing any existing hsrpv1 packet model(s).

description

PR adds native hsrpv2 tlv support, and includes:

• A new hsrpv2 tlv container layer.
• tlv dispatching for hsrpv2 payloads.
• hsrpv2 Group State tlv support.
• hsrpv2 Interface State tlv support.
• hsrpv2 Text Authentication tlv support.
• unknown tlv preservation for unsupported tlv types.
• ipv4 and ipv6virtual IP handling for the hsrpv2 Group State TLV.
• Dispatch logic to distinguish hsrpv1 fixed-format packets from hsrpv2 tlv-based packets on UDP:1985.
• ipv6 hsrpv2 binding on UDP:2029.
• tests that check for hsrpv1 compatibility and hsrpv2 build behavior.

notes

previous behavior is intended to remain unchanged.

for ipv4 hsrpv2, UDP:1985 is shared with hsrpv1. because of that, i thought that Scapy should not automatically change the ipv4 destination address default to 224.0.0.102 in case it was meant for hsrpv1. this would mean that when building ipv4 hsrpv2 packets, users should explicitly set the multicast destination as:

IP(dst="224.0.0.102") / udp(sport=1985, dport=1985) / HSRPv2()

instead of relying scapy to infer the destination automatically usually as shown below

IP() / UDP(sport=1985, dport=1985) / HSRPv2()

however, for IPv6 HSRPv2, there would be no issue, as this change would automatically binds hsrpv2 to UDP:2029 and ff02::66.

MD5 Authentication tlvs are currently preserved as unknown tlvs rather than fully dissected, pending verified packet captures or specification confirmation for the exact ivp4/ipv6 layout.

tests

on top of existing hsrpv1 tests, i checked for:

• tlv build tests for hsrpv2's Group State/Text Authentication/Interface State/other unknowns
• hsrpv2 dispatch on ipv4 (UDP:1985) and binding on ipv6 (UDP:2029)
• ipv4 virtual IP encoding as a 4-byte ipv4 address to the 16-byte hsrpv2 virtual IP field and ipv6 virtual IP encoding as a full 16-byte ipv6 address.

closing remarks!

thanks for reviewing! please do let me know if there are any remarks or changes that i might need to make

[polybassa]

Thanks for the PR!