stardreamer

0. I agree LEO Sat is different from 60GHz. But the detrimental effects of wireless is completely overblown. People running into issues should just run a signal test first to make sure it's not their setup that's the problem.

1. There is no such thing as weather in SoCal (other than that one week of continuous rain each year).

2. If you are just looking at 4 9s or 3 9s latency while the link is not saturated, it's fine for general use (assuming my first bullet point holds). It's not like I'm running aws off of my home network.

3. Even in the rain, the latency is mostly fine. It's usually just the minute it starts raining that the latency goes through the roof. My assumption is that it's sampling and adjusting the modulation/coding scheme.

I don't run starlink, but I run Starry (fixed point wireless) when AT&T and Spectrum are available because:

1. I do networking for a living, including wireless (or technically my coworkers do). I know how this thing works and what it's limitations are
2. I live in an area where it almost never rains, so little to no attenuation
3. AT&T is on my banlist after shutting down my account for migrating to a 5G phone not on their approved list. Customer service didn't even let me transfer the sim back to the old 4G phone. The account termination was immediate. I ended up convincing customer service that I needed my phone number for emergency contact, and immediately transferred the number elsewhere upon it being restored.
4. Spectrum routing is shit
5. Wireless can be as good (or even better) than wired in ideal conditions (see 1), my current 1Gbps plan also only costs $20/month.

Sorry, but the fungus has been burping and slurping on radiation.

The point I'm making is that IP addresses are useful/used because they are the canonical way of reaching a service. If you have a name (via DNS), it still needs to be translated into an address because routing depends on arbitrary numerical addresses.

But they shouldn't be, and they don't have to be. They identify an interface, not the host. We have services on a single host running across multiple interfaces (multiple ports), or in some cases multiple services running on a single interface (k8s, cloudflare), or even sometimes multiple interfaces/servers masquerading as a single interface (DNS root servers).

The correct way to handle this is to identify services by a name, which means routing itself should be handled via name, not IP addresses. This is one of the things Named Data Networks (NDN) tries to solve. In this scheme, everything has a name. Not a numeric address. Memorizing 10.0.0.1 becomes a lot less important when you can always reach your service at "foo/bar/service".

Needless to say, this is currently not feasible because every single IP router in the world needs to be replaced with a NDN router, in which nobody would do. Vendors have already shown that when they can adapt new technologies or implement NAT, they will implement NAT.

Edit NDN wikipedia article https://en.wikipedia.org/wiki/Named_data_networking

link local

IPv4 has this too. It's normally not routable so it's safe to ignore in both IPv4 and IPv6.

Instead of DHCP...

The following is a gross simplification, but works for understanding the most common cases:

The original (heavy emphasis on this word) idea of IP is that addresses are unique for every interface. Additionally MAC addresses (48 bits) are also unique for every interface.

In IPv4, you're trying to make interfaces that are unique in 48 bit IDs unique in 32 bit IDs. It doesn't take a pigeon to realize there will be collisions. Therefore you need a person to manually assign addresses. If you automate that person, that becomes DHCP.

In IPv6, you're making a 48 bit unique ID unique in a 128 bit namespace. You literally don't need to do anything and you can still guarantee it's unique. That's how you automatically assign IPv6 addresses without DHCPv6.

As for how MAC addresses are assigned uniquely, the first 24 bits are a vendor prefix. The vendors then ensure each device they produce is unique.

With ipv6 the address is too long and incomprehensible to remember.

The problem is that nobody should be memorizing arbitrary 128 bit numbers, or even 32 bit arbitrary numbers. Especially since the numbers don't even correspond to a machine, but instead an interface on the machine. Yes, 32 bit IPv4 addresses are easier to memorize, but you shouldn't be memorizing them in the first place. Services run off of names. If the names aren't working, fix the name service.

Ideally NDN solves this problem completely. Every host/packet is identified by a name, not an address. If you need to fetch something, all you need to do is provide the name and somebody (doesn't have to be the original machine) will provide it to you.

How is IPv6 harder to understand? It's just IPv4 with all the uncommon stuff stripped out and put into optional headers (which IPv4 also has), and a much longer address now written in hex.

CGNAT is just a fancy term for NAT done by a carrier. They get a special private IP address range for doing so, but fundamentally it's still NAT.

Now IP multicast, THAT is complicated for humans to understand. Especially the whole subscriber logic.

Networking researcher here chiming in.

All IPv4 addresses can already be represented in the IPv6 address space, by the same method you describe here.

As for "backwards compatible with IPv4", I'm afraid that's not possible for the same reason IPv6 isn't getting major traction. Right now, we literally CANNOT upgrade our entire networking infrastructure. What you're proposing requires updating every switch and middlebox to support routing using additional bytes, which is physically impossible. The biggest problem would be middleboxes, which includes NAT router, firewalls, etc. For context: most middleboxes drop anything that is not IPv4/TCP or IPv4/UDP. This is why QUIC is encapsulated inside a UDP header (and funny enough, these vendors STILL didn't learn, trying to match a "QUIC header" despite Google themselves saying there is no fixed QUIC header), and RoCEv2 using a header that looks like UDP. There is absolutely no way a new L3 protocol that is not IPv4 (and in some cases, IPv6) can be supported by these boxes.

The only time we successfully replaced the L3 protocol was with the adaption of IPv4. In which networks were much smaller, and networking research was under the US DoD. The DoD basically gave an ultimatum that "if you don't switch to IP by this date we will cut your funding". That won't fly now that the Internet is managed by a cluster of ISPs.

Also: IPv6 is stupid simple. It's basically IPv4, with everything not commonly used stripped out (and added back with "optional headers", and a much larger address field. Since the address field is much larger, it is recommended to write them in hexadecimal, which looks more scary than IPv4.

Side note: I don't think any of these IP protocols is the solution here. If you only keep extending the address field, you're still gonna run into IP problems (routing, ddos, caching). The future of the Internet should be something like NDN. But for the same reason I described above, I don't think that's going to happen unless the Internet is a pile of smoldering ruins.