@@ -41,20 +41,23 @@ one. Grouped by each TCP/IP layer and ordered by protocol name alphabetically,
4141the ones outstanding are,
4242
4343* Link Layer: DSL, EAPOL, FDDI, ISDN, NDP, PPP
44- * Internet Layer: ECN, ICMP, ICMPv6, Shim6
44+ * Internet Layer: ECN, Shim6
4545* Transport Layer: DCCP, RSVP
4646* Application Layer: BGP, DHCP, DHCPv6, DNS, IMAP, LDAP, MQTT, NNTP,
4747 NTP, ONC/RPC, POP, QUIC, RIP, RTP, SIP, SMTP, SNMP, SSH, Telnet,
4848 XMPP
4949
5050Several of these come in pairs that want a shared abstract base rather than two
5151independent implementations, in the way
52- :class: `~pcapkit.protocols.internet.ip.IP ` already covers its family: ICMP
53- with ICMPv6, and TLS/SSL with DTLS. **Done ** for TLS/SSL with DTLS:
54- :class: `~pcapkit.protocols.application.ssl.SSL ` is the shared record-layer base
55- of :class: `~pcapkit.protocols.application.tls.TLS ` and
52+ :class: `~pcapkit.protocols.internet.ip.IP ` and
53+ :class: `~pcapkit.protocols.internet.icmp.ICMP ` already cover their families:
54+ IP and IPsec, and TLS/SSL with DTLS. **Done ** for TLS/SSL
55+ with DTLS: :class: `~pcapkit.protocols.application.ssl.SSL ` is the shared
56+ record-layer base of :class: `~pcapkit.protocols.application.tls.TLS ` and
5657:class: `~pcapkit.protocols.application.dtls.DTLS ` -- see the `DTLS `_ section
57- below.
58+ below. Neighbor Discovery (:rfc: `4861 `, the ``NDP `` above) and Multicast
59+ Listener Discovery (:rfc: `9777 `), both carried in ICMPv6, are not implemented,
60+ nor is ICMP/ICMPv6 checksum computation or verification (:issue: `2470 `).
5861:class: `~pcapkit.protocols.link.vlan.VLAN ` is the closer precedent for a pair
5962whose *layout * is identical -- it holds the whole of the tag, and
6063:class: `~pcapkit.protocols.link.c_tag.C_Tag ` and
@@ -362,8 +365,9 @@ Follow-ups to the bindings above:
362365 port number. That depends on the proxy identifying the version positively
363366 instead of guessing, since a guess path is wrong on non-HTTP input.
364367
365- Beyond those, the gaps most likely to be met in a real capture are ICMP (1)
366- and ICMPv6 (58) on the internet layer, each of which has a stub.
368+ **Done. ** ICMP (1), ICMPv6 (58) and IGMP (2) -- the internet layer gaps most
369+ likely to be met in a real capture -- are all now implemented; ECN and Shim6
370+ above remain the open ones.
367371
368372PCAPNG Support
369373--------------
@@ -1082,11 +1086,19 @@ post-wave-1 consistency sweep described under `Release Plan — 1.5.0 in Two
10821086Steps `_ above.
10831087
10841088**Wave 2 — the protocol pairs that want a shared abstract base **, per `More
1085- Protocols, More!!! `_ above: **ICMP with ICMPv6 ** and **TLS/SSL with DTLS **,
1086- plus **IGMP ** and **DCCP ** on their own. These are grouped because the shared-base
1087- question is the design work and doing either half of a pair alone would answer it
1088- twice. **DCCP ** is the transport-layer implementation, tracked by :issue: `2489 `, and
1089- blocked on :issue: `2479 ` for its pseudo-header checksum.
1089+ Protocols, More!!! `_ above: **TLS/SSL with DTLS ** and **IGMP ** and **DCCP ** on
1090+ their own. These are grouped because the shared-base question is the design work
1091+ and doing either half of a pair alone would answer it twice. **DCCP ** is the
1092+ transport-layer implementation, tracked by :issue: `2489 `, and blocked on
1093+ :issue: `2479 ` for its pseudo-header checksum.
1094+
1095+ **Done within wave 2 — ICMP/ICMPv6 shared base. ** :class: `~pcapkit.protocols.internet.icmp.ICMP `
1096+ is the abstract base :class: `~pcapkit.protocols.internet.icmpv4.ICMPv4 ` and
1097+ :class: `~pcapkit.protocols.internet.icmpv6.ICMPv6 ` share for selector composition
1098+ (:issue: `2436 `); each implements its own message-type parsing independently rather than
1099+ through a shared method body. The two are distinguished by whether they carry pseudo-header
1100+ checksums (ICMPv6 does; ICMPv4 does not) and parse without checksum computation or verification
1101+ (:issue: `2470 `).
10901102
10911103**IGMP v1/v2 — done within wave 2 ** (:issue: `2439 `).
10921104The versioned classes :class: `IGMPv1 <pcapkit.protocols.internet.igmpv1.IGMP> ` and
@@ -1132,8 +1144,11 @@ above, which describes the payloads in question and why a registry of their own
11321144is wanted instead of
11331145:meth: `~pcapkit.protocols.protocol.Protocol._decode_next_layer `. It is
11341146sequenced *after * wave 2 rather than by preference: the multicast options embed
1135- :rfc: `3810 ` MLD, which rides in **ICMPv6 **, and :rfc: `3376 ` **IGMPv3 ** group
1136- records — ICMPv6 a wave 2 deliverable, IGMPv3 :issue: `2448 `. Landing the
1147+ :rfc: `9777 ` MLD (which obsoletes :rfc: `3810 `; :rfc: `2710 ` for MLDv1), which
1148+ rides in **ICMPv6 **, and :rfc: `3376 ` **IGMPv3 ** group records. ICMPv6 and
1149+ IGMPv1/v2 are both wave 2 deliverables, now done; MLD itself remains a
1150+ follow-up to ICMPv6 (see `More Protocols, More!!! `_ above), and IGMPv3 is
1151+ :issue: `2448 ` -- neither is part of wave 2's own scope. Landing the
11371152registry first would give a dispatch table with nothing but
11381153:class: `~pcapkit.protocols.misc.raw.Raw ` to register. The
11391154counter-argument is real though, and worth weighing rather than dismissing: changing the
0 commit comments