eMuleAI network parity: interest, and the libutp vendoring question

[kno]

Summary

I maintain a fork at kno/amule that implements the
wire-level extensions an eMuleAI peer expects, so that aMule and eMuleAI
recognise each other's capabilities instead of falling back to the plain eD2k
subset. It is built on 3.0.1 and tracks this repository.

The code for everything described here, including the rendezvous framing
discussed in this thread, lives on the
integration/network-parity
branch. The fork's master mirrors this repository plus downstream tooling
only, so a branch cut from it starts clean.

Before preparing any pull request I would rather ask whether you want this at
all, and under what conditions — particularly the one in "Open question" below,
which decides whether two of the pieces are even offerable.

What it consists of

Seven pieces, each with its own tests, in dependency order:

#	Piece	Depends on
1	Peer capability recognition — the CT_MOD_MISCOPTIONS tag and its bits, plus demultiplexing of OP_UDPRESERVEDPROT2 frame types	—
2	Kademlia protocol 0x0a — version advertisement and the AICH gate	—
3	Address widening — a family-agnostic address type, so an IPv6 peer is not a peer with "no address"	—
4	IPv6 dual stack — one listening socket per family; reachability advertised only after inbound IPv6 is observed	3
5	uTP transport — sharing the eD2k UDP port	1, 3
6	NAT traversal — answering a relayed rendezvous, rate-limited, with bounded hole punches	1, 5
7	QUIC NAT-T transport	6

1 and 2 are small and self-contained. 3 is the one that unblocks the rest and
also the most invasive of the early ones.

Why the formats can be trusted

These are not guesses at eMuleAI's wire format. They were measured against a
running eMuleAI v1.6.0:

• CT_MOD_MISCOPTIONS reads 0x0000001F from it — every bit of the mask this
  work defines, matching bit for bit.
• The EAQN1 proof magic and the ALPN string ed2k-ai-natt-quic-v1 both appear
  verbatim in its binary.
• Its GnuTLS priority string offers the same four TLS 1.3 ciphers in the same
  order, over a subset of the same groups.
• An eD2k handshake over native IPv6 completes between the two
  implementations — a hand-built OP_HELLO to its port answered with
  OP_HELLOANSWER.

Open question, and the reason for asking first

Piece 5 vendors libutp under src/extern/, as a byte-identical copy of
transmission/libutp at 490874c44a2e
(MIT), with no local patches and a provenance note. Pieces 5, 6 and 7 have no
meaning without a uTP implementation.

To be precise about what is and is not proposed: the bundled copy is the
default, not the only route. cmake/libutp.cmake offers both, following the
same bundled-or-system convention this project already uses for picojson
(USE_SYSTEM_PICOJSON):

• USE_SYSTEM_LIBUTP=OFF (default) — the vendored copy.
• USE_SYSTEM_LIBUTP=ON — a system-installed libutp; fails loudly if absent,
  rather than silently downgrading to a green build with the transport missing at
  runtime.

The default is the bundled copy because libutp is not packaged anywhere I can
find. Measured rather than assumed:

• Debian trixie: no libutp-dev, no libutp, and apt-cache search returns
  nothing; sources.debian.org reports no exact match.
• Homebrew: no formula (brew search libutp offers only unrelated names).

So making the system route the default would break the build on most machines
with a FATAL_ERROR asking the user to install something that does not exist as
a package.

Vendoring is still a project-policy decision rather than an engineering one, which
is why I would rather hear your position than write a pull request that assumes
it. If it is unacceptable, uTP does not disappear — it becomes conditional on a
library your users would have to build by hand, and that changes what pieces 5–7
can honestly promise.

One property worth stating because it is what makes the copy maintainable: it is
byte-identical to the pinned upstream commit, with no local patches, and the
vendored CMakeLists.txt is not edited either — the build adapts to upstream's
target name instead. A patched third-party file turns every version bump into a
merge and makes the provenance note untrue.

What I would not offer yet

Being explicit so this is not discovered in review:

• QUIC (piece 7) is not ready. It compiles, negotiates TLS, classifies frames
  and advertises its capability bit, but no QUIC connection has ever completed
  with another implementation, and one decision inside its authentication proof
  was made without evidence. I would not ask anyone to maintain that yet.
• NAT traversal (piece 6) answers but does not initiate. Choosing a relay is
  deliberately gated off, because whether a candidate relay can reach a firewalled
  peer is not knowable from the requesting side. IPv6 hole punches encode and parse
  but are not sent.
• Nothing in the fork's own packaging, container images or translation catalogs is
  proposed — those are downstream concerns and would conflict with your Weblate
  pipeline.

What I am asking

1. Is this direction something you want in aMule at all?
2. What is your position on vendoring libutp under src/extern/?
3. If yes to (1): would you prefer one piece at a time in the order above,
   starting with capability recognition, or a different shape?

Happy to adapt to whatever review process suits you, including splitting
pieces further.

Test plan

Each piece carries unit tests. The current fork tip is at 73/73 in both build
configurations, with CI green across Ubuntu, macOS and mingw-w64 (Debug and
Release), plus clang-tidy and clang-format. Per-piece test counts and evidence
would come with each pull request.

[kno]

I'm not familiar with the repository's policy on this matter, but all the code and documentation—including this issue—have been generated using AI.

[got3nks]

Thanks for asking first, and for being specific about what is not ready. Taking your three questions in order.

1. Is the direction wanted? Yes, but not on the 3.1.0 timeline. NAT-T is planned for 3.2.0; 3.1.0 is closing out. That is a scheduling answer, not a lukewarm one, and it works in your favour: it leaves room to land the early pieces properly rather than rushing a large surface in behind a release.

Worth knowing before you go further: there is already a work-in-progress NAT-T + uTP branch you should look at, got3nks/amule@feat/nat-t-utp. Fair warning, it is well behind master (branched around 2026-05-16, master is ~1250 commits ahead), so read it as a design reference rather than something to rebase onto. It covers roughly your pieces 1, 5 and 6: OP_UDPRESERVEDPROT2 dispatch, a uTP layer over the eD2k UDP port, the Key Frame encoder/parser, encryption wrapping, a rendezvous coordinator with buddy roles, and OP_RENDEZVOUS / OP_HOLEPUNCH wire formats. Fourteen NAT-T/uTP test files, including loopback and 3-node rendezvous integration tests.

It stopped at the same wall you describe for piece 6: answering a rendezvous is tractable, initiating one is where it gets hard. There is also a known open defect on it (the encryption gate reads a bogus 127.0.1.1 public IP), so treat any single file as unreviewed.

I would rather converge on one implementation than run two, so if you are willing, comparing wire formats early is the highest-value thing: if your measurements against eMuleAI v1.6.0 disagree with what that branch encodes, your measurements win, and it would be good to know before either of us writes more.

2. Vendoring libutp. Acceptable, and already the position in practice: that branch vendors it too, for the same reason you give. It pins bittorrent/libutp at 2b364cbb, verbatim, MIT, with a provenance note and a stated no-local-patches rule, built as a static library so packagers do not need a libutp-dev that does not exist.

Two differences worth settling rather than inheriting:

• Which upstream. You pin transmission/libutp; that branch pins bittorrent/libutp. Transmission's fork is the one that still sees maintenance, so yours is probably the better choice. Say so explicitly in the provenance note either way.
• Where it lives. That branch put it at top-level utp/; you propose src/extern/. src/extern/ is right, it is where vendored code already goes.

Your USE_SYSTEM_LIBUTP toggle that hard-fails when the system copy is absent matches our feature-gating policy: an explicitly requested option with a missing dependency must fail the configure, never silently downgrade to a green build with the feature missing at runtime. Keep that behaviour.

3. Shape. One piece at a time, in your order, with one change: separate NAT-T from IPv6. Your own dependency table already allows it, since 5 depends on 1 and 3 but not on 4. IPv6 dual stack is the more complicated and more invasive change and it should not be the thing gating uTP review. So: 1, 2, 3, then 5 and 6, with 4 as its own track on its own schedule.

Piece 3 is the one to be careful with. It is a wide refactor whose benefit is invisible until something later uses it, which is the shape of change that is hardest to review and easiest to regress. Splitting it further would help: a mechanical address-type introduction that changes no behaviour, then the call sites.

Do not offer 7 until a QUIC connection has completed with another implementation, which is what you already said.

On AI-generated code. Not a problem here, and thank you for saying so up front. We accept it on the same terms as anything else: it has to be well tested and the code quality has to meet the project's standards. Both are judged from the diff, not from how it was produced. In practice that means tests that fail when the behaviour is wrong rather than tests that pass alongside it, and code a maintainer can still reason about a year from now. Expect review to push on both.

[kno]

Thank you — that is a more useful answer than I expected, and the branch pointer
changes what is worth doing next. Taking your points in order, then the wire
comparison you asked for.

3.2.0, and the shape

Both accepted, including the split you propose: 1, 2, 3, then 5 and 6, with
IPv6 (4) on its own track. You are right that 5 depends on 1 and 3 but not on
4, and that letting the invasive change gate uTP review helps nobody.

Piece 3 split further, as you suggest: a mechanical address-type introduction
that changes no behaviour, then the call sites. That is also the honest shape —
the type landed first here too, and everything after it is a consumer.

QUIC stays where it is. No connection has completed with another implementation,
so there is nothing to offer.

Wire formats: no divergence

I read feat/nat-t-utp against this tree. Every value we both encode agrees:

	your branch	here
OP_UDPRESERVEDPROT2	0xB2	0xB2
uTP sub-byte	0x00	0x00
Key Frame sub-byte	0xFF	0xFF
OP_RENDEZVOUS	0xA0	0xA0
OP_HOLEPUNCH	0xA1	0xA1
CT_MOD_MISCOPTIONS tag id	0xAA	0xAA
misc-options NAT-T bit	0x02	0x02
connect-options NAT-T bit	0x80	0x80

Two implementations arriving independently at the same encoding is the strongest
evidence either of us has that the format was read correctly.

Where we differ, and why your rule does not favour me here

This tree also uses 0x20 (endpoint hint) and 0x40 (relayed) in the
connect-options byte — bits your header lists as reserved.

You said that if my measurements disagree with what your branch encodes, my
measurements win. They do not apply here. I did not measure those two; I
chose them, and the header says so: "0x40 is the one value in this header the
proposal does not pin, and eMuleAI's use of that bit is unknown to this tree."
So treat both as unallocated space that this tree occupied, not as findings. If
eMuleAI uses either bit for something else, we are wrong and your reserved
marking is the safer default.

What I did measure, against a running eMuleAI v1.6.0, is narrower and I will
keep it separate from the above:

• CT_MOD_MISCOPTIONS reads 0x0000001F from it — all five bits of the mask.
• EAQN1 and the ALPN ed2k-ai-natt-quic-v1 appear verbatim in its binary.
• Its GnuTLS priority string offers the same four TLS 1.3 ciphers in the same
  order over a subset of the same groups.
• An eD2k handshake over native IPv6 completes between the two
  implementations.

Your bit-7 note is better than my silence

Your treat_bit7_as_nat_t parameter, and the comment explaining that
source-exchange packets overload bit 7 to mean "the source's user hash follows",
document a hazard this tree does not mention anywhere.

We are safe by confinement rather than by design: CONNECT_OPT_NAT_TRAVERSAL_UTP
is only ever read from frame[1] of an OP_RENDEZVOUS message, inside an
OP_UDPRESERVEDPROT2 envelope, and no path reads a connect-options byte from a
Hello or a source exchange as NAT-T. That holds today and nothing enforces it.

Concretely, the hazard is live in this tree too: CUpDownClient::SetConnectOptions()
reads only bits 0-3, and it is called from five places — one of them the
source-exchange path in CPartFile, where the very same byte is read as
if ((byCryptOptions & 0x80) > 0) { achUserHash = sources.ReadHash(); }. Adding a
bit-7 read to that function without a context parameter would report "this peer
speaks NAT-T" every time a source exchange said "a hash follows".

So your explicit-context parameter is the better construction, and with no default
argument, so the compiler makes each of those five call sites declare which context
it is in rather than letting a new one inherit the wrong answer. I would rather
adopt that than keep relying on where the constant happens to be used today. It is
not urgent — NAT-T here already negotiates through CT_MOD_MISCOPTIONS, which is
what I measured against eMuleAI — so I would bring it with the piece 6 pull request
rather than as a change on its own.

libutp

• Which fork. Recorded explicitly, as you asked — the provenance note now
  says why transmission/libutp rather than bittorrent/libutp: the original
  has seen no maintenance in years, transmission's is the one that still ships
  and carries the CMake packaging and libutp/ include prefix this vendoring
  relies on. Licence and copyright are unchanged either way. It also warns that a
  tree pinning the other fork will differ, so nobody reads that as drift.
• Location. src/extern/ it is.
• USE_SYSTEM_LIBUTP. Hard-fail behaviour kept, and now I know it matches
  policy rather than merely being defensible.

uTP frame encryption, and the defect you flagged

I implemented the encryption wrapping here after reading yours, and the
127.0.1.1 defect is worth more than a footnote because the mechanism is in
aMule itself, not in your branch.

CamuleApp::GetPublicIP(bool ignorelocal = false) returns, when no public IP is
known and Kad is not connected, ignorelocal ? 0 : m_localip. The default is
false, so a bare GetPublicIP() yields the local address — 127.0.1.1 on
a Debian host, the loopback entry /etc/hosts gives the hostname. A gate reading
GetPublicIP() != 0 then passes while holding loopback.

What this tree does instead: GetPublicIP(true), so absence is zero, and a
routability predicate that refuses loopback, link-local, RFC1918 and
carrier-grade NAT (100.64.0.0/10 — not private, still not reachable, and the
case a naive gate lets through). Twenty-two tests pin it, including the boundary
cases that a lazy implementation would pass: addresses just outside the 172.16/12
and CGNAT blocks must still obfuscate, and "I do not know my address" is refused
as unknown rather than as unroutable, because the same outcome from different
causes hides bugs.

Note src/MuleUDPSocket.cpp uses the bare form for the existing eD2k path, so
the hazard is not confined to NAT-T. I deliberately did not touch it — that is
upstream behaviour and changing it alters eD2k traffic — but you may want it on
your list independently of any of this.

On review standards

Understood, and that is the right bar. Everything above was measured rather than
asserted, and where it was not — the 0x20/0x40 bits — I have said so. Expect
the same in the pull requests: I would rather have a finding contradicted early
than carried into review.

[got3nks]

Worth knowing before either of us settles a wire format: there is a third NAT-T implementation, eMule v0.72a-community, and it is a different design.

https://forum.emule-project.net/index.php?showtopic=167228&view=findpost&p=1110927

It coordinates through a modified eD2k index server rather than a peer relay, and tunnels over QUIC (quiche). Not interoperable with the rendezvous approach, and not fixable by bit allocation: it needs a server almost nobody runs.

I checked its sources against your allocation. No collisions:

	eMule 0.72a-community	you / feat/nat-t-utp
capability	login tag CT_EMULE_UDPPORTS 0xF9	CT_MOD_MISCOPTIONS 0xAA
coordination	0x60-0x62 on the server link, 0x9F UDP keepalive	OP_RENDEZVOUS 0xA0 inside 0xB2
hole punch	OP_NATT_HOLEPUNCH 0xB3	OP_HOLEPUNCH 0xA1 inside 0xB2
transport	QUIC, 0xD0-0xD7	uTP, sub-byte 0x00 inside 0xB2

Your 0x20 / 0x40 bits are safe against it

Its OP_NATT_HOLEPUNCH payload is <tcp_port 2><userhash 16><conn_opts 1>, so it does carry a connect-options byte on a NAT-T path, which is where a clash would have appeared. It does not: the sender writes WriteUInt8(0) ("connect options (plain; safe default)"), and its SetConnectOptions() reads only bits 0-3, exactly as aMule's does. Bits 4-6 are unread and unwritten by both shipping clients.

That is not the same as safe against eMuleAI, which neither of us has measured for those bits, so keep them marked as occupied-not-measured the way you already do.

Two smaller things

Its SetConnectOptions(uint8, bool bEncryption = true, bool bCallback = true) already gates bits on caller context, the same idea as treat_bit7_as_nat_t, but with defaults, so a new call site silently inherits an answer. Worth keeping yours without them.

That thread has several implementers (Andrey23, BuyukBang, ModderMule). One remark worth chasing is BuyukBang's, that every packet is wrapped in a valid uTP (BEP-29) header so DPI classifies the flow as ordinary BitTorrent and lets it through. That is not this tree, which has no uTP framing at all, so it describes another client. If it holds up it is an argument for uTP unrelated to congestion control, and they will give you a straighter answer than either of us reading binaries.

Speaking both: probably not worth it

The namespaces do not collide, so a client could carry both and pick whichever coordination is available. The coordination half is cheap. The transport half is a dependency and licensing question:

• libutp is MIT, plain C++, vendored, no toolchain beyond a compiler. It fits.
• quiche is BSD-2-Clause, fine in itself, but it is Rust, so every platform we package gains a Rust toolchain including the static musl build. On Windows that guide does not build it at all, it ships a prebuilt quiche.dll from the Jetty project with a hand-generated import library. And its TLS backend is not stated anywhere, which matters: aMule is GPLv2-or-later, so a transitive Apache-2.0 dependency would force the combined work to GPLv3+.

So I would not ask for QUIC interop. What it does argue for is free: the demultiplexer in piece 1 should not assume it will only ever see one NAT-T family. Recognising 0xB3 and 0xD0-0xD7 as known-but-unhandled keeps the door open at no cost.

On GetPublicIP()

Confirmed, and it is narrower upstream than it looks. Two bare gates, MuleUDPSocket.cpp:269 and CUpDownClient::ShouldReceiveCryptUDPPackets(). CClientCreditsList already gets it right: it tests GetPublicIP(true) and only falls back to the bare form deliberately, with a warning. The remaining bare uses are == comparisons where a loopback value simply never matches a real peer, plus tray-icon display.

The reason it stays latent is that stock eD2k and Kad never self-declare an address. HighID is the ID the server assigned by connecting back to you; a server callback carries the IP the server saw; and in the Kad buddy path your KADEMLIA_CALLBACK_REQ carries buddy ID, file hash and your TCP port only, with the buddy filling in your IP from the datagram source before relaying OP_CALLBACK. Every path has a third party observing you, so a wrong GetPublicIP() cannot put an unreachable address on the wire.

Rendezvous inverts exactly that: you assert your own endpoint and nobody corrects it. That is why your routability predicate is the right call and != 0 is too weak a test once an address is being asserted rather than observed.

We will file the two gates separately, out of the NAT-T series, since as you say changing them alters eD2k traffic.

[got3nks]

Correcting myself on the two gates: I said we would file them separately, and having traced what they actually protect, there is nothing to file.

Both MuleUDPSocket.cpp:269 and ShouldReceiveCryptUDPPackets() decide the same thing, whether to obfuscate an outgoing client UDP packet. Obfuscation never uses our own address: Kad packets are keyed on the receiver verify key or the target Kad ID, client packets on the target's client hash. Our public IP appears once in CEncryptedDatagramSocket::EncryptSendClient(), as wxASSERT(theApp->GetPublicIP() != 0 || kad), which uses the same bare call and so does not fire either.

So when the local address makes those gates pass early, we obfuscate slightly sooner than intended, the packet is still well formed, and the peer still decrypts it with its own hash. I could not construct a configuration where anything fails. Changing them to GetPublicIP(true) would make us obfuscate less in that window, which is a real change to eD2k traffic for no benefit, exactly the caution you raised.

Latent inconsistency, then, not a defect. What does stand is the NAT-T half: rendezvous asserts an address that nothing corrects, so != 0 really is too weak there and your routability predicate is the right construction. That belongs with piece 6 rather than as an upstream fix.

[got3nks]

Stating the goal we would be designing against, because it decides most of the open questions here.

aMule should be able to reach a firewalled peer by whichever mechanism that peer supports, rather than picking one camp:

1. IPv6 directly, the way emule-qt does it, so a dual-stack peer needs no traversal at all.
2. Peer-coordinated NAT-T over IPv4, so we can reach eMuleAI peers.
3. Server-coordinated NAT-T, so we can use a modified eD2k server where one is available.

Those are not competing designs; they cover different populations, and IPv6 removes the need for the other two wherever it applies.

On ordering: NAT-T over IPv4 is what we would implement end to end first. It is the case with no alternative at all today, since an IPv4-only pair of LowID peers has nothing else to fall back on, and it is the part of your series that is furthest along and testable against a shipping peer. IPv6 and server coordination are things the design should not foreclose, not things to build first.

I pulled the current sources for all three and read the constants out of the code:

	version	provenance
eMuleAI	v1.6 (2026-07-25)	git
emule-qt	tip 2026-08-25	git
eMule 0.72a-community	0.72.0	source drop from the forum thread, no VCS

1. eMuleAI, peer-coordinated: the first thing to ship

If reaching eMuleAI peers is a goal, our rendezvous has to be theirs. Framing at v1.6:

	eMuleAI v1.6	feat/nat-t-utp	your fork
envelope	OP_EMULEPROT 0xC5	OP_EMULEPROT 0xC5	0xB2 + frame 0x00
body order	hash(16), options(1)	same	options(1), hash(16)
file-hash block	optional 16	optional 16	absent
inline hint	tail IPv4(4)+port(2) then an optional transport byte	tail IPv4(4)+port(2)	TLV element, 8 or 20
optional blocks detected by	remaining length	remaining length	the 0x20 bit
endpoint hint packet	standalone 0xAA under OP_EMULEPROT, fixed 56 bytes	-	element inside the rendezvous body

feat/nat-t-utp already matches them; your fork does not. Note 0xAA is defined in both trees and means different things: a standalone packet with ver, targetHash, servingBuddyID, fileHash, IPv4, port, connectOptions on their side, an inline element on yours.

Your TLV is the better construction, and I would rather see it adopted than dropped. But as a proposal to eMuleAI to extend their format, not as a reason to diverge from it: a rendezvous that cannot reach their clients has nobody to talk to except us. If they take the TLV, everyone gets the family-tagged hint and nobody loses interop.

Two things to know about their direction. Bit 1 of CT_MOD_MISCOPTIONS is now commented "Legacy uTP NAT-T" and bit 4 is SupportsNatTraversalQuic, with a capability handshake and a 1500 ms fallback, the same 1500 ms your kNattFrameTypeFallbackWaitMs uses. And 0x40 in the connect-options byte is now taken:

#define CONNECT_OPT_NAT_TRAVERSAL_QUIC  0x40

which answers the question your header leaves open about that bit. Yours is in the NAT-T control byte rather than byCryptOptions, so not a literal clash, but worth not carrying "relayed" against their "QUIC" in an enum that already mirrors their 0x80.

2. IPv6: keep the gates open

Not the first delivery, but the one most easily foreclosed by a wire format, so it is worth designing for now. emule-qt's rule is the one to keep room for: a LowID peer with an IPv6 MUST be dialled directly. LowID is a property of the IPv4 identity; a routable IPv6 stands on its own. That converts CGNAT users with a working v6 prefix from unreachable to directly dialable with no traversal machinery at all.

Kad stays IPv4-only in every implementation, deliberately: a node's identity is a 32-bit address throughout the routing table, nodes.dat, the per-subnet caps and the UDP verify keys. IPv6 travels there as payload tags (ip6, bi6) rather than as contacts, so discovery still happens over IPv4 while the connection is made over v6. Their docs/protocol/ipv6-spec.md is worth reading before piece 4.

One caveat that shapes the rest: consumer CPE usually blocks unsolicited inbound IPv6 by default, so dual-stack does not automatically mean reachable. emule-qt answers that with PCP / NAT-PMP / UPnP IPv6 pinholes rather than with traversal, which is a cheaper answer where it works.

3. eMule 0.72a, server-coordinated: keep the gates open

Different shape entirely: coordination runs over the eD2k server link, and the server has to be modified. Nothing collides with the peer-coordinated family.

The coordination half is cheap for us. The transport half is not: theirs is QUIC via quiche, which means a Rust toolchain on every platform we package including the static musl build, a prebuilt quiche.dll of third-party provenance on Windows, and a TLS backend the integration guide never names, against a GPLv2-or-later codebase.

So the honest split is that we can implement their coordination but not their transport. That is still worth something: two aMule peers could use server coordination with uTP between them wherever such a server exists.

What that implies for the design

Keep coordination and transport separate. Three ways to be introduced to a peer (peer rendezvous, server coordination, Kad buddy) and a negotiated transport over whichever hole gets opened. That is what lets one implementation serve all three goals instead of forking per peer type.

Concretely, and cheaply, now:

• The demultiplexer in piece 1 should not assume one NAT-T family. Recognising 0xB3 and 0xD0-0xD7 as known-but-unhandled costs nothing and keeps the server-coordinated door open.
• Answer eMuleAI's OP_NATT_FRAME_CAPS / _ACK negotiation, and advertise uTP only. Their fallback path is designed for exactly that.
• Keep the address handling family-agnostic as piece 3 already does, so IPv6 stays reachable later without another wire change. That is the gate worth holding open while IPv4 NAT-T is built.

Constant map

CT_MOD_MISCOPTIONS (0xAA, eD2k hello tag)

bit	meaning	source
0	SupportsExtendedXS	eMuleAI, emule-qt
1	SupportsNatTraversal, labelled legacy uTP	eMuleAI
2	SupportsIPv6	eMuleAI, emule-qt
3	SupportsServingBuddyPull	eMuleAI
4	SupportsNatTraversalQuic	eMuleAI
5	MODMISC_EXTXS_SKIPTAGS	emule-qt
6-9	left unclaimed on purpose, room for eMuleAI to grow	emule-qt convention
10	MODMISC_HTTPCACHE	emule-qt

Your measured 0x0000001F is bits 0-4, exactly this set through QUIC.

eD2k connect-options byte (byCryptOptions)

bit	meaning	read by
0x01 0x02 0x04	crypt supported / requested / required	all four
0x08	direct UDP callback	all four
0x10	unallocated	none
0x20	CONNECT_OPT_NATT_ENDPOINT_HINT, a request asking the buddy to reply with the target's endpoint	eMuleAI v1.6
0x40	QUIC NAT-T	eMuleAI v1.6
0x80	uTP NAT-T in hello/callback context; "user hash follows" in source exchange	eMuleAI, feat/nat-t-utp

eMule 0.72a writes 0 here in its hole punch and reads only bits 0-3. emule-qt reads bits 0-3 and implements no NAT-T.

Frames inside OP_UDPRESERVEDPROT2 (0xB2)

sub-byte	meaning	source
0x00	uTP payload	eMuleAI, your fork, feat/nat-t-utp
0x01	QUIC payload	eMuleAI, your fork
0x02 / 0x03	capability negotiation and ack	eMuleAI v1.6
0xFF	key frame	eMuleAI, your fork, feat/nat-t-utp

Stock Kad LowID mechanism

opcode	value	namespace	payload
KADEMLIA_FIREWALLED_REQ	0x50	Kad C2C UDP	<TCP port 2>
KADEMLIA_CALLBACK_REQ	0x52	Kad C2C UDP	<buddyID 16><fileHash 16><TCP port 2>
KADEMLIA_FIREWALLED_RES	0x58	Kad C2C UDP	<IP 4>
OP_CALLBACK	0x99	eD2k C2C TCP	<buddyID 16><fileHash 16><requester IP 4><TCP port 2>
OP_BUDDYPING / OP_BUDDYPONG	0x9F / 0xA0	eD2k C2C TCP	none

The requester's address appears only in OP_CALLBACK, inserted by the buddy from the datagram source. Nothing here takes a client's word for its own address, which is why NAT-T is the case that needs a routability predicate.

eD2k server coordination, eMule 0.72a-community

opcode	value	direction	payload
CT_EMULE_UDPPORTS	0xF9	login tag	(kadUDPPort << 16) | clientUDPPort, doubles as capability flag
OP_LOWID_HOLEPUNCH_REQUEST	0x60	client -> server	<target_id 4><our_udp_port 2>
OP_LOWID_HOLEPUNCH_INFO	0x61	server -> both	<peer_ip 4><tcp 2><udp 2><userhash 16><role 1>
OP_LOWID_HOLEPUNCH_FAIL	0x62	server -> client	<target_id 4><reason 1>
OP_SERVER_NATT_KEEPALIVE	0x9F	client -> server, UDP	<userhash 16>
OP_NATT_HOLEPUNCH	0xB3	peer <-> peer, UDP	<tcp 2><userhash 16><conn_opts 1>(<nonce 4>)
OP_NAT_SYN ... OP_NAT_PING	0xD0-0xD7	peer <-> peer	tunnel handshake, QUIC data, close

emule-qt also parses and ignores a PR_NAT server capability flag 0x00008000 and an ST_NAT_PORT tag; nobody implements them, but they are allocated.

Values that repeat across namespaces

• 0xA0: OP_RENDEZVOUS here, OP_BUDDYPONG in eD2k C2C TCP, OP_SERVER_LIST_REQ in C2S UDP.
• 0x9F: OP_SERVER_NATT_KEEPALIVE on the server UDP link, OP_BUDDYPING in eD2k C2C TCP.
• 0xAA: CT_MOD_MISCOPTIONS as a hello tag, OP_NATT_ENDPOINT_HINT in both NAT-T trees with different meanings.

One hazard

emule-qt documents that eMuleAI's extended source exchange reader appends every unknown tag to an error string and then returns out of the whole parse, so one unrecognised tag in the first record drops every source in that packet. Its bit 5 gates against exactly that. Worth knowing before widening source exchange.