Update inet6.py for Destination Option#4695
Update inet6.py for Destination Option#4695arnavdas88 wants to merge 4 commits intosecdev:masterfrom
Conversation
Extension Headers can show weird behavious. Linux's sk_buff considers the IPv6 Payload to be either TCP, UDP or ICMP. It does not consider Extension Headers to be the payload. Following similar architecture, This small modification let's packet flow with Destination Option on both, request and response packets be captured as well.
|
Thanks for this PR! This looks good to me. Could you add corresponding unit tests into https://github.com/secdev/scapy/edit/master/test/scapy/layers/inet6.uts ? This will ensure that your code works as expected, and catch future regressions. |
There was a problem hiding this comment.
Pull Request Overview
This PR updates the IPv6 packet answer logic to properly handle Destination Option extension headers by checking for UDP/TCP layers directly instead of relying solely on the payload chain. This follows Linux's sk_buff architecture which considers TCP, UDP, or ICMP as the IPv6 payload rather than extension headers.
- Modified the
answers()method in IPv6 class to handle Destination Option extension headers differently - Added direct UDP/TCP layer checking when processing packets with Destination Option headers
- Preserved backward compatibility by falling back to the previous implementation for other cases
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #4695 +/- ##
==========================================
- Coverage 82.13% 80.64% -1.50%
==========================================
Files 361 370 +9
Lines 86830 91731 +4901
==========================================
+ Hits 71319 73973 +2654
- Misses 15511 17758 +2247
🚀 New features to boost your workflow:
|
Extension Headers can show weird behavious. Linux's
sk_buffconsiders the IPv6 Payload to be either TCP, UDP or ICMP. It does not consider Extension Headers to be the payload.Following similar architecture, This small modification let's packet flow with Destination Option on both, request and response packets be captured as well, which was not the case before, as a packet flow with DestOpt ExtHdr in both request and response will be skipped by the previously implemented logic.
No current GitHub issue exists, because there are no publicly available PDM (RFC8250) Server available, and for the same reason, the Unit Tests are not relevent.
Checklist:
cd test && ./run_testsortox)