|
| ▲ | krab 8 hours ago | parent | next [-] |
| > 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. |
| |
| ▲ | bflesch 8 hours ago | parent [-] | | I'd mix in some IPv4 of course, maybe pipe some of the connection via VPN interface so the physical route is not same for all packets. |
|
|
| ▲ | neilalexander 8 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | bflesch 8 hours ago | parent | next [-] | | Yes, and if your host has access to several IPv6 addresses and maybe an IPv4 address it'd be nice to have something like wireguard actually utilize all of them in some random order. Same on the receiving end, wireguard server listenes both on IPv4 and IPv6 at same time and internally puts received packets in the proper order. I feel this would create significant struggles for any surveillance software because most firewalls I know are modeled on a source address / target address basis. If you have access to enough source IPv6 addresses you might even put your whole wireguard traffic into ICMP packet payload? | |
| ▲ | vaylian 7 hours ago | parent | prev [-] | | > via ND What is ND? Do you have a link with details? | | |
|
|
| ▲ | jeroenhd 7 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | tucnak 6 hours ago | parent [-] | | I thought most ISP's give out at least /64's for free these days? Telia gives out a /56, although unfortunately there's no way to migrate them. This was a big deal for my homelab when I was moving, as I had to manually update all prefixes everywhere. A pain in the ass. | | |
| ▲ | jeroenhd 3 hours ago | parent | next [-] | | ISPs do, cloud providers often give smaller ranges. Re: renaming all the prefixes, that's why I use a ULA within my home network. Not as useful if you want your services available from the outside if you move ISPs (NAT66 can help on the inside but you'd still need to update all DNS records to use the new prefix). I'll stick with my ULA + VPN fallback for now, I don't expect the prefix to change more than once every five or six years. If you want a static prefix with a changing prefix, you're probably better off with getting a Hurricane Electric tunnel. Or if you want to go hard on the IPv6 homelab hobby, get your personal IPv6 address space and a bring-your-own-IP business ISP. | |
| ▲ | fc417fc802 5 hours ago | parent | prev [-] | | By convention they're supposed to DHCP you at least a /64 if not something wider. I don't believe there's any expectation it be static (although it typically is AFAIK) and there are some providers that defy expectations by handing out narrower slices (up to and including /128). |
|
|
|
| ▲ | darkr 7 hours ago | parent | prev | next [-] |
| yes - this is also part of the privacy extensions spec: https://datatracker.ietf.org/doc/html/rfc4941 |
|
| ▲ | jasonjayr 8 hours ago | parent | prev | next [-] |
| IIRC you could still track because all those mutiple IPv6 addresses will have the same prefix. |
|
| ▲ | pastage 8 hours ago | parent | prev | next [-] |
| It is quite easy todo 100 lines of Python, you can even send ip packets with faked source adress. |
| |
| ▲ | ale42 7 hours ago | parent | next [-] | | Networks are supposed to do egress filtering to prevent any packets with fake IPs from ever leaving the network. In practice it's not always so, but it mostly is. So you'd be limited to fake IP addresses in your own network, and doing so might raise alerts depending on the network infrastructure you live in. | |
| ▲ | bflesch 8 hours ago | parent | prev [-] | | Packets with fake source address can easily be spotted, and will raise an alert. In terms of using multiple interfaces for a single service it might be easy to hack together in a python script, but last time I checked the linux kernel support for bundling multiple interfaces is limited to redundancy and failover. What I'd like to have is a single service dynamically using many network interfaces with randomized packet timings and randomized packet scheduling (5 packets on first interface, pause on 2nd, some on third interface, sometimes send traffic simultaneously). |
|
|
| ▲ | immibis 6 hours ago | parent | prev [-] |
| Yes, but realistically the guy who is tracking you tracks the first 64 bits of the address, which identify the network. |
| |
| ▲ | fc417fc802 6 hours ago | parent [-] | | That's merely convention. I've encountered at least one VPS provider handing out /128's. | | |
| ▲ | Dylan16807 3 hours ago | parent | next [-] | | While a situation like that is really annoying, I bet it's still generally following the rule of one /64 per network. What you're not getting is control over your IPs on that network. | |
| ▲ | craftkiller 6 hours ago | parent | prev [-] | | It is more than convention, the /64 is the minimum allocation to support SLAAC. If you're getting less than a /64 you're not getting full support for IPv6. | | |
| ▲ | fc417fc802 5 hours ago | parent [-] | | Well you're not getting support for SLAAC but I didn't understand that to be a core requirement to qualify as a functional IPv6 implementation. Regardless, my point is that allocations narrower than /64 exist in the wild for better or worse. So do IPv6 NAT implementations for that matter. If you assume either of those things don't exist then you might be in for a surprise. |
|
|
|
