Skip to content

fix(internet): IGMPv3 and IGMP base id() disagree with the family-grouping ruling #2512

Closed

Description

@JarryShaw

On main (94185da93), IGMP.id() is ('IGMP', 'IGMPv1', 'IGMPv2', 'IGMPv3') and IGMPv3.id() is ('IGMP', 'IGMPv3'). protocol-family-grouping.rst says the base is ('IGMP', 'IGMPv2') and that each member narrows to itself, per the ruling behind #2506. #2465 and #2506 both edited igmp.py, and the 4-tuple is what survived the two merges.

Fix, following the written ruling

  • IGMPv3.id() becomes ('IGMPv3',), since RFC 3376 names it with a version.
  • IGMP.id() becomes ('IGMP', 'IGMPv2', 'IGMPv3'). No member's id() is 'IGMPv1' any more; that selector still works through its registry key.
  • The doc's member-shapes table and its Canonical Names section gain IGMPv3.

If the 4-tuple was deliberate at merge time, say so here and this closes as intended.

Activity

  1. added
    fixPull requests that fix a defect (fix: subject prefix)
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    on Nov 1, 2026
  2. moved this to Pending in PyPCAPKiton Nov 1, 2026
  3. added
    wipWork in flight - a covering PR is open or an agent is actively on it
    and removed
    pendingAccepted and unstarted - nobody is on it and nothing blocks it
    on Nov 1, 2026
  4. moved this from Pending to WIP in PyPCAPKiton Nov 1, 2026
  5. removed
    wipWork in flight - a covering PR is open or an agent is actively on it
    on Nov 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    fixPull requests that fix a defect (fix: subject prefix)

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions