461–470 of 480 posts
Earlier quoted context omitted.
Maybe just don't? Let it be IPv4 with more bits, the software is already there so dual stacking isn't so bad, adoption might actually be quick if people didn't have to learn much to implement it.
>Let it be IPv4 with more bits Then it's not IPv4 and is not compatible with IPv4.
Earlier quoted context omitted.
> 464xlat allows communication from ipv6 only clients to legacy ipv4 ones without the need for a separate stack on your end device > nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device How does that work if your ISP doesn't support IPv6? Can an OS developer deliver IPv6-only OSs to any end user? How about v4-only VPNs? Ultimately the answer…
If your ISP doesn't support IPv6 today, you should have switched to a competent ISP years ago.
Earlier quoted context omitted.
Your initial claim was that a IPv6 address consists of a 64-bit network address, then a 64-bit device address that could be separated into : as an example. However, SLAAC demands that each device is given a 64-bit prefix that it then chooses many random 64-bit host addresses from, without any other rhyme or reason. So, if you want to know the IP of a host you want to connect to, you have to remember at least a 64-bit…
> you have to remember at least a 64-bit number that changes every day by design A machine using IPv6 privacy extensions would have two addresses; one that changes, and one typically based on the MAC address that remains constant. If you are in the local network with that machine or otherwise are supposed to be in-the-know, you'd know it's fixed address and connect to that.
Earlier quoted context omitted.
Have you ever heard of TCP/IP stack fingerprinting? It is very likely that someone intercepting your traffic can tell apart your phone and your laptop regardless of the originating IP address. Odds are they can even tell your operating systems.
It's not because someone can say whether I'm at home or not by looking at the lights that putting a plate in front of my home saying whether I'm here or not is a good idea ^^ (sorry for the poor metaphor;) )
Anyone who can either man-in-the-middle your traffic or is the intended recipient will be able to do fingerprinting based on your TCP/IP traffic. In addition, a lot of your traffic will likely be HTTP(S), in which case the recipient servers will also be able to set cookies, and perform various additional forms of fingerprinting to learn even more about you. The idea that hiding behind a single IP address gives you any protection is delusional.
Earlier quoted context omitted.
kind of brings up the question if all apps can do this
Here’s the routing table that the HE.net Network Tools shows for my cellular connection shortly after I’ve turned off WiFi on my iPhone 14 Pro. None of the entries in the cellular routing table is IPv6 with my current SIM card. So I am doubting more and more the claim that iPhone is somehow IPv6 only. Seems more like some people have carriers that choose to provide them IPv6 only, and because of that they think that…
Earlier quoted context omitted.
Peer-to-peer still wouldn't work even in a fully IPv6 world without something like STUN or TURN, since endpoints would still be protected by stateful firewalls preventing external connections to them.
With a firewall, the application knows its public-facing ipv6 address/src port number without STUN. A stateful firewall does not alter packets. It can open the firewall simply by sending something. If it can communicate its public-facing ipv6 address/src port number to the remote side using a SIP proxy (ok, for this signalling, you need a relay), it can receive traffic. No TURN needed either. What scenario do you hav…
The second option may not even work with more paranoid firewalls, which might not allow TCP SYN packets on existing connections.
Earlier quoted context omitted.
They only had a 10mbit link. Apparently 50mbit/s was the amount of traffic they received. Mostly everyone could handle this, not just CloudFlare.
CloudFlare reported 10Gib/s when they first switched it on. The 10Mb/s link was deliberately limited.
The last public analysis was done in 2010 by RIPE and APNIC. At the time, 1.1.1.0/24 was 100 to 200Mb/s of traffic, most of it being audio traffic. In March, when Cloudflare announced 1.0.0.0/24 and 1.1.1.0/24, ~10Gbps of unsolicited background traffic appeared on our interfaces.
Earlier quoted context omitted.
No, I describe existing practice with NAT where you in fact have IP addresses extended by TCP/UDP port numbers. You could instead move this "port" directly into IP header in backward-compatible way and fall back to stateful NAT only if the counterparty does not support it.
No, you can't: an IPv4-only device that receives that packet would interpret your extra address bytes as part of the TCP/UDP header. There simply isn't any room in the IPv4 header to squeeze extra bytes in. That is exactly why NAT baked knowledge of TCP & UDP into routers, breaking the layering design in the process. If there were any way to add extra headers to IPv4 without relying on middle boxes to support it, it…