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 IGMP v1/v2 (v3's group-record list as a follow-up) #2439
Is your feature request related to a problem? Please describe.
Wave 2 of the roadmap. IGMP has no implementation -- grep across pcapkit/ finds only protocol-number constants (transtype.py's IGMP = 2, apptype/udp.py's igmpv3lite) and the Mobility Header module carrying IGMP group records as opaque bytes, with its own docstring saying explicitly they belong to IGMP and are "carried opaquely here" for lack of a real IGMP dissector to hand them to. pcapkit/protocols/internet/__init__.py:12 lists IGMP in the maintainer's own standing TODO.
Describe the solution you'd like IGMP v2 (RFC 2236) first, as an Internet subclass (schema/data/protocol split, per discussion #251). v1 (RFC 1112) is a strict subset of v2's 8-byte header -- same shape, fewer message types, no max-response-time field -- and is largely obsolete in the wild, so it's a near-free addition once v2's header is in; v3 (RFC 3376) adds a materially different group-record-list body for source-specific multicast substantial enough to warrant its own follow-up rather than blocking this PR.
Describe alternatives you've considered
v3 first since it's a superset in spirit -- rejected: the group-record list body is a different enough shape that building v2's simpler header first, then extending, is less churn than building v3 and retrofitting v1/v2 compatibility onto it.
Additional context
IGMP's message-type values (0x12/0x16/0x22) are already referenced opaquely in mh.py's mobility-header carrying logic -- landing v1/v2 here gives that registry something real to dispatch records to, ahead of the Mobility Header sub-layer registry work pep.rst sequences behind wave 2.
Done via #2444 (merged): IGMPv1 and IGMPv2 as concrete classes over an abstract IGMP base, exactly this issue's scope. IGMPv3's group-record list was deliberately deferred to its own follow-up per this issue's own text, tracked as #2448 (covered by #2465).
Activity
docs: open the 1.6.0 changelog entry for wave 2
feat(internet): implement IGMP v1/v2 as an Internet subclass
feat(internet): implement IGMP v1/v2 as an Internet subclass
feat(internet): implement IGMP v1/v2 as an Internet subclass
feat(internet): implement IGMP v1/v2 as an Internet subclass
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
13 remaining items
feat(internet): implement ICMP and ICMPv6, sharing a thin dispatch base
fix(internet): refuse non-8-octet IGMP Queries as IGMPv1/v2 (#2439)
feat(internet): add IGMPv1/IGMPv2 behind an IGMP dispatcher (#2439)
feat(internet): add IGMPv1/IGMPv2 behind an IGMP dispatcher (#2439)
feat(internet): add IGMPv1/IGMPv2 behind an IGMP dispatcher (#2439)
feat(internet): add IGMPv1/IGMPv2 behind an IGMP dispatcher (#2439)
feat(internet): add IGMPv1/IGMPv2 behind an IGMP dispatcher (#2439)
feat(internet): add IGMPv1/IGMPv2 with one shared read path (#2439)
feat(internet): add IGMPv1/IGMPv2 with one shared read path (#2439)
JarryShaw commentedon Oct 31, 2026
Done via #2444 (merged): IGMPv1 and IGMPv2 as concrete classes over an abstract
IGMPbase, exactly this issue's scope. IGMPv3's group-record list was deliberately deferred to its own follow-up per this issue's own text, tracked as #2448 (covered by #2465).