You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(internet): implement ICMP and ICMPv6, sharing a thin dispatch base #2436
Is your feature request related to a problem? Please describe.
Wave 2 of the roadmap (docs/source/contributing/pep.rst, "Wave 2 — the protocol pairs that want a shared abstract base"). ICMP (RFC 792) and ICMPv6 (RFC 4443) have no implementation at all — pcapkit/protocols/application/NotImplemented/icmp.py and icmpv6.py are both 0-byte placeholders, and pcapkit/protocols/internet/__init__.py:12 carries the maintainer's own standing TODO: Implement ECN, ICMP, ICMPv6, IGMP, Shim6.
Describe the solution you'd like
A thin shared ICMP-family base between Internet and ICMP/ICMPv6, following the existing IP (between Internet and IPv4/IPv6) and IPsec (between Internet and AH/ESP) precedent — both of those hold almost nothing beyond a classmethod id() returning the pair's names, for uniform dispatch and documentation grouping, not code reuse.
That's deliberately the right amount of sharing here, not more: past the common 4-byte type/code/checksum header, ICMP and ICMPv6's type registries are completely disjoint, ICMPv6 additionally carries Neighbor Discovery (RFC 4861) and MLD (RFC 3810) with no ICMPv4 equivalent, and the checksum algorithms differ (ICMPv6's includes the IPv6 pseudo-header the way TCP/UDP do; ICMPv4's doesn't). Each concrete class should implement its own schema, type registry, and checksum independently — forcing more into the shared base would misrepresent how little these two protocols actually share.
Each follows the standard schema/data/protocol split (discussion #251): a Schema_ICMP(Schema), a Data_ICMP(Protocol), and the protocol class itself registered onto Internet.
Describe alternatives you've considered
No shared base at all — rejected for inconsistency with the IP/IPsec precedent already in the codebase.
Additional context
MLD (RFC 3810) has no presence anywhere in the tree and is gated on ICMPv6 landing first — tracked as a follow-up, not part of this issue's scope. ICMPv6 should land with at minimum the common error/informational message types (Destination Unreachable, Packet Too Big, Time Exceeded, Parameter Problem, Echo Request/Reply); Neighbor Discovery message types (RFC 4861) can be a separate follow-up given their size.
Activity
docs: open the 1.6.0 changelog entry for wave 2
feat(internet): implement ICMP and ICMPv6, sharing a thin dispatch base
feat(internet): implement ICMP and ICMPv6, sharing a thin dispatch base
feat(internet): implement ICMP and ICMPv6, sharing a thin dispatch base
feat(internet): implement ICMP and ICMPv6, sharing a thin dispatch base
feat(internet): implement ICMP and ICMPv6, sharing a thin dispatch base
feat(internet): implement ICMP and ICMPv6, sharing a thin dispatch base
feat(internet): implement ICMP and ICMPv6, sharing a thin dispatch base
feat(internet): implement ICMP and ICMPv6, sharing a thin dispatch base
10 remaining items
feat(internet): implement ICMP and ICMPv6
feat(internet): implement ICMP and ICMPv6
refactor(link): share thin dispatch base class between LinuxSLL and L…
feat(internet): implement ICMP and ICMPv6
feat(internet): implement ICMP and ICMPv6
feat(internet): implement ICMP and ICMPv6
feat(internet): implement ICMP and ICMPv6
feat(internet): implement ICMP and ICMPv6
feat(internet): implement ICMP and ICMPv6
feat(internet): implement ICMP and ICMPv6