351–360 of 480 posts
Can we go back in time and hit the designers of IPv6 upside the head? The decision not to make IPv6 backwards compatible, the belief that a beautiful new standard could magically replace something already so widespread... "Naive" is an inadequate word. We are still futzing with the transition 3 decades later, with no end in sight. Grrr, grumble...
We should probably consider whether the rent-seeking enabled by the scarcity of IPV4 addresses is one of the things holding back IPV6 adoption.
you mean the fact that amazon has around 4.5B reasons to not support ipv6? interesting idea
Earlier quoted context omitted.
These arguments always boil down to these two: "Please just try to fit more than 4 billion numbers into 4 bytes" -- this is mathematically impossible. "Just extend the address size" -- this is an entirely new protocol by the definition of IPv4, which uses fixed-size addresses. The reason for the slow IPv6 adoption is that there was no financial or business pressure. While IPv4 is ubiquitous, nobody individually feels…
We could presumably have done something like: use the IPv4 packet format, treat the 32 bit src/dst address in the header as the first 32 bits of the address and put the remaining 96 bits (+ checksums/etc.) as the first few bytes of the payload. Then create TCPv6, UDPv6, IGMPv6 etc. protocol identifiers for the protocol field to distinguish traffic that's encoding an IPv6 address in the first few bytes of the payload.…
So no router can route it sensibly and no existing client works ? How would that help ?
Earlier quoted context omitted.
No. There would be no NAT box holding IP-port mappings in its internal memory, with the related timeouts, flakiness, port clobbering etc. and no packet re-writing. All routing decisions would be static, based on information in the IP header: the legacy outside routers would just examine the legacy part of the IP address and packet, while the internal IPv4.1 would use the extended bits. So just like any packet routing…
It sounds nice on paper but typically we don't want unsolicited packets to reach internal hosts. Yes, NAT is not a firewall --yet we don't see admins eager to put random lan hosts in the DMZ or enable UPnP.
It's how things work with IPv6, which doesn't have NAT (by default): just because a host has a globally routable address does not mean it is reachable by default.
Earlier quoted context omitted.
You're inventing a new addressing scheme, and proposing that we put a bunch of middleboxen in to mediate connecting the old world to hosts on this new addressing scheme. You're re-inventing IPv6.
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.
Earlier quoted context omitted.
I think this is absolutely one of the reasons. Addresses are very hard to remember in ipv6. You usually just have to remember the first 3 parts of ipv4 and then change the last digit based on the host you want. IPv6 I know it has shorthand but still it doesn’t register in my brain the same way.
What alternative do you suggest for making the IP addresses longer (so more people can connect computers to the Internet) while keeping them equally memorable? The most recent anonymous editor to the IPv6 address article on Wikipedia has address "2602:FBF6:0:0:30C6:7069:6DF0:FD24". An IPv4-like notation of that would be "9730.64502.0.0.12486.28777.28144.64804".
There are some technical advantages to doing things that way of course, but they are arguably rather outweighed by the administrative disadvantages. The protocol could have been designed so that typical layer 3 addresses were not much longer, nor harder to type or remember than IPv4 addresses are.
Earlier quoted context omitted.
Everyone is always quick to complain that we're going through N number of NAT gateways or N number of proxies, but this is virtually never a problem for most of the Internet. Even despite this rats maze of proxies and NAT gateways we're still supporting virtually all the applications that consumers use and love such as VoIP, WebRTC, HTTP(S), DNS, Gaming, Streaming Video, Mobile Apps, etc. NAT seems to always get a ba…
Most of the applications that could communicate peer-to-peer use relay servers that make delay and scalability worse. Some combinations of NAT may sometimes work without a relay server, but figuring this out is complex and increases connection setup time. Every early SIP/VoIP user had the 'the connection only works in one direction' experience, usually caused by NAT. A CGNAT is a stateful component which makes it exp…
Earlier quoted context omitted.
You can have multiple IPv6 addresses on your interface, so you can have both the ULA address for internal use as well as the global address - no need for NAT
However, the priority order on your OS for address selection, even when it comes to stuff like choosing which DNS results to use is IPv6 global address > IPv4 > ULAs. So on a dual stack network, ULAs with not be used unless the only address is a ULA. And even if you run your internal services with only an AAAA record pointing to the ULA, the client's source address will likely be the global address of the client devi…
The problems this caused/s seems to have been an unintended / unforeseen consequence that was more exposed as people gained experience. There's a draft being worked on to officially change the priority:
> The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. The lack of a consistent and supportable way to manipulate this behavior, across all platforms and at scale is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724].
* https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula
Earlier quoted context omitted.
These arguments always boil down to these two: "Please just try to fit more than 4 billion numbers into 4 bytes" -- this is mathematically impossible. "Just extend the address size" -- this is an entirely new protocol by the definition of IPv4, which uses fixed-size addresses. The reason for the slow IPv6 adoption is that there was no financial or business pressure. While IPv4 is ubiquitous, nobody individually feels…
> The IPv6 transition will be like a bankruptcy: very slowly, slowly, then all of a sudden. I don't think that's true. Some services on the internet are already made available through IPv6. Doesn't that mean their migration to IPv6 is done? There are however some ISPs that seem to be dragging their feet. I recall I tried to deprecate IPv4 access to a personal project of mine and it was no longer reachable when I trie…
Can we go back in time and hit the designers of IPv6 upside the head? The decision not to make IPv6 backwards compatible, the belief that a beautiful new standard could magically replace something already so widespread... "Naive" is an inadequate word. We are still futzing with the transition 3 decades later, with no end in sight. Grrr, grumble...
Yeah, I never got any of the articles about how well IPv6 is designed. Any article will get me confused about whether an IPv6 address is a range, a computer, a router, or something that points to a resource inside my computer. (I guess it's all of these things?). But the biggest problems of all: You can write an IPv4 address on a phone call. You might be even able to remember it. Not the case for IPv6, you need to be…
IPv6 had one job: make more addresses available while keeping the addresses easy to manipulate, and it failed at that.
"Well-known" NAT64 prefix: 64:ff9b::
Everything is so confusing in numbering and addressing: http://www.gestioip.net/cgi-bin/subnet_calculator.cgi?ip=006...
=
If problem was allocation, we could have added one number in front: 123.114.123.130.200
Now for backward compatibility:
If your device, operating system and application are compatible with IPv6, congratulations, you receive 123.114.123.130.200 and talk natively in IPv6.
Otherwise, if you are on an IPv4 device, you receive only a portion of the IP address but from a fake IP starting with 250.x.x.x
inetnum: 250.0.0.0 - 250.255.255.255
organisation: Future use
status: RESERVED
For example, your local home/ISP router can send a truncated version of the IP address: 250.123.130.200 and then it's the responsibility of this translation router to remember the routes at least for some time (and there is always possibility to hardcode routes if needed).
=
A bit like Stateful NAT64 or "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments" or "464XLAT: Combination of Stateful and Stateless Translation"
But now, with all these millions of standards it's such a productivity loss for any tech working in networking.
Similarly when switching CPUs over from 32 bits to 64 bits, the idea was to change the size of words stored in memory, not change the size of words and change the alphabet in use.