IP protocol 115 (TransType.L2TP) is registered nowhere, so an L2TP-over-IP capture falls through to Raw

[JarryShaw]

TransType.L2TP is 115, and nothing in the tree dispatches it. A capture carrying IP protocol 115 falls through to Raw.

Found while answering a design question on #514. The owner's recollection there was that "L2TP, iirc we added it to Internet's registry despite it being a Link subclass" — hedged, and it turns out the situation is different and worth recording precisely, because the fix differs from the one that recollection implies.

Measured on main at 691f12ab5, repo venv, PYTHONSAFEPATH=1, pcapkit.__file__ asserted to be the repository tree:

TransType.L2TP = 115
Internet.__proto__ owns 16 entries; 115 present: False
Link.__proto__     owns  7 entries; 115 present: False
classes owning their own __proto__: Frame, PCAPNG, SCTP, TCP, UDP
  -- none of them holds key 115

So L2TP is not misfiled into Internet's registry. It is registered nowhere at all under its IP protocol number.

What is registered, and why that masks the gap

UDP.__proto__ holds key 1701 → pcapkit.protocols.link.l2tpv2.L2TPv2. That is the UDP-encapsulated form on its well-known port, and it works. L2TPv2 subclasses L2TP, which subclasses Link.

So the UDP path is covered and the IP-protocol path is not. Anyone testing L2TP through a UDP capture sees it dissect correctly and would not notice that a capture with IP protocol 115 in the header does not.

Why 115 is the right key to expect

IANA assigns protocol number 115 to L2TP, and pcapkit/const/reg/transtype.py already carries the TransType.L2TP = 115 member — so the constant exists and is correct; only the dispatch entry is missing. pcapkit/protocols/link/l2tp.py exists and implements the protocol.

The design question this sits inside

L2TP is awkward precisely because it is an L2 protocol carried over IP, so "which registry owns key 115" is a real question rather than an oversight to paper over:

• Internet.__proto__ is keyed by TransType, which is where 115 belongs by key type.
• But L2TP is a Link subclass, so registering it there means an Internet registry entry resolving to a Link class.

That tension is the same one #514 is working through — the owner's Q3 there proposes either inferring the destination registry from the Enum class, or taking an explicit destination argument. This issue should probably be fixed as part of whichever mechanism #514 lands, rather than by hand-adding an entry that the new scheme would then have to special-case. Recording it separately so it is not lost if #514's scope narrows.

Coverage

No test asserts that every TransType member with an implementing class is reachable through dispatch, which is why this survived. Such a test would be broadly useful — it would catch the next missing registration rather than just this one — and it belongs with whatever fix lands. Note a related dispatch-registry test already exists at tests/protocols/test_dispatch_registry_unit.py and enumerates 38 __proto__ entries, so the harness for this is already in place.

Not fixed here, and deliberately: pcapkit/protocols/internet/internet.py and the registry machinery are contended by PR #547 (#514's PR (a)) as I write this.

[JarryShaw]

Framing note: the existing UDP entry is correct, and must not be "fixed"

Adding this because the issue as written could be closed the wrong way.

UDP.__proto__[1701] = L2TPv2 is not a misfiling, even though it puts a Link-layer class in a Transport registry. A dispatch registry is keyed by the enclosing layer, not by the layer the protocol itself belongs to — L2TP over UDP port 1701 is RFC 2661's encapsulation, so UDP is exactly the right registry for it and L2TPv2 is exactly the right value.

So the defect here is a missing second registration, not a misplaced first one. Moving the existing entry to Link.__proto__ would break the encapsulation that currently works, place it under a key EtherType does not define, and still leave IP protocol 115 undispatched — strictly worse in three ways.

Why this belongs inside #514's PR (b) rather than being fixed first

The same reasoning settles which of the two mechanisms proposed in #514 is right: infer the destination registry from the enum type, not from the class's parent. Parent-inference would put L2TPv2 in Link.__proto__ for precisely the wrong reason.

Under enum-type inference, fixing this issue is a registration rather than a special case — L2TPv2 declaring TransType.L2TP alongside the port it already answers on, one class naming two enclosing layers. Fixing it now against today's tables means hand-writing an entry and then rewriting it when the mechanism lands.

It is also the honest test of that design: if the mechanism cannot express "a Link class reachable from both Internet and UDP", it is the wrong mechanism. That makes this issue worth keeping open as a constraint on PR (b) rather than closing early with a hand-written entry.

[JarryShaw]

This issue's premise is wrong, and the correction is mine to record. #589 closes it by refusing a bad version nibble rather than by making the registration asked for here.

What this issue asked for was for L2TPv2 to declare TransType.L2TP, IP protocol 115. That binding would misparse. RFC 3931 §4.1.1, verbatim:

L2TPv3 over IP (both versions) utilizes the IANA-assigned IP protocol ID 115.

and §4.7.2 confirms UDP port 1701 is shared between v2 and v3, with the Ver field distinguishing them. So 115 is a missing class, not a missing registration — it belongs to L2TPv3 over IP, whose session header has no version nibble at all, and it should stay unbound until an L2TPv3 class exists.

Four places in the tree already said so and this issue engaged none of them: pcapkit/protocols/link/l2tp.py:35-41, pcapkit/protocols/link/l2tpv2.py:91-95, pcapkit/const/reg/transtype.py:388 (whose IANA citation is literally [:rfc:`3931`]), and a passing test at tests/protocols/test_dispatch_bindings_unit.py:228 asserting assertNotIn(TransType.L2TP, Internet.__proto__).

One thing does need fixing, and it is worse than a missing binding. pcapkit/protocols/link/l2tpv2.py:187 stores the wire version nibble unchecked while :119-128 returns a hard-coded Literal[2], so one object gives two different answers. Measured on 9c240a60e:

000312345678: ACCEPTED  protocol.version=2  info.version=3   tunnelid=0x1234
000f12345678: ACCEPTED  protocol.version=2  info.version=15  tunnelid=0x1234

Because port 1701 is genuinely shared, this affects real capture traffic today: an L2TPv3-over-UDP packet parses as L2TPv2 with fabricated fields rather than degrading to Raw.

A related trap worth naming. #570 shipped this exact wrong binding as its documented worked example at pcapkit/foundation/registry/protocols.py:262:

register_protocol_code(L2TPv2, [TransType.L2TP, {UDP: 1701}])

That line is live on main at 9c240a60e, so anyone following the documentation would have produced the misparse — which is very likely how this issue came to be filed in those terms in the first place. #589 changes it.

The mechanism #570 added is not at fault: [TransType.L2TP, {UDP: 1701}] is a legal, working code=. The declaration was wrong, not the machinery.