[TheusHen]

Author here.

This article focuses on the transport-layer design, not a torrent client replacement. The goal is to provide a reusable IPv6-native P2P connection layer (QUIC-based, NAT-free) that existing clients or new applications can integrate without touching their higher-level logic.

Feedback on design trade-offs is very welcome.

[walkthisway]

https://github.com/TheusHen says you're 14 years old.

The project is very impressive, as is https://github.com/TheusHen/ternary-ibex and having papers: https://orcid.org/0009-0009-5055-5884

What's the education path for a 14 year old that does this stuff?

[TheusHen]

I don’t really follow a “standard” education path. I’ve been interested in technology for as long as I can remember and had early access to computers and the internet. I’m about to turn 15 in a few days, and I’ve been programming for almost 6 years now — I started when I was 9.

Most of what I know comes from self-study, experimentation, reading documentation, breaking things, and rebuilding them. I usually learn by doing projects rather than following a fixed curriculum. As for papers, I mostly write by organizing ideas that come to my head and then grounding them with research and practical knowledge. Lately, I’ve been considering writing one about implantable RFID microchips, just to explore the topic more deeply.

[bflesch]

Thanks for sharing. I want to ask you something: I understand that with IPv6 the idea is that every household receives several of IPv6 addresses so that every single IoT device has their unique IPv6 address and there is no NAT needed.

Would it be possible to use a dozen of IPv6 addresses at the same time? Like send one UDP packet over certain IPv6 interface, next packet over another IPv6 interface, and so on. If both sending and receiving end have access to multiple IPv6 addresses I can see how this significantly increases complexity for tracking.

Could you split up the traffic across dozens or hundreds of IPv6 source addresses?

[krab]

> Could you split up the traffic across dozens or hundreds of IPv6 source addresses?

Yes

> I can see how this significantly increases complexity for tracking

Not really. You just track at some prefix level. In general, the ISP will hand out a /64 per consumer so that's what you can track. From there, you can build more complex and more precise grouping rules for tracking.

[neilalexander]

If you assign a subnet to a host, or allow the host to claim multiple addresses via ND from the link subnet, then you can use as many addresses as you want. You could give every process on your machine its own IPv6 address for example.

[jeroenhd]

The biggest tracking hurdle is to figure out if the ISP that handed out the block of addresses is handing out /64s, /56s, or /48s. The network provided to you is functionally the same as the IP address assigned to you with IPv4.

In theory I could rent an IPv4 /29 (of which 6 addresses are usable) for like 20 euros a month from my home ISP to cause the same confusion but I doubt it'd confuse trackers to use those.

[jasonjayr]

IIRC you could still track because all those mutiple IPv6 addresses will have the same prefix.

[darkr]

yes - this is also part of the privacy extensions spec: https://datatracker.ietf.org/doc/html/rfc4941

[pastage]

It is quite easy todo 100 lines of Python, you can even send ip packets with faked source adress.

[immibis]

Yes, but realistically the guy who is tracking you tracks the first 64 bits of the address, which identify the network.

[fc417fc802]

> QUIC-based, NAT-free

I realize it's intended to be an unsupported edge case but I'm curious. What happens in the event a NAT is present along the IPv6 network path? Do you just forward a port the same as you would with the various IPv4 solutions and move on? Or does it break catastrophically? Something else?