The problem has nothing to do with over engineering, or really anything to do with the actual contents of the IPv6 standard. It is just devilishly hard to make any backwards-incompatible change to layer 3, and address expansion is always going to be backwards incompatible.
IPv4 addresses are in fact a subspace of IPv6 (that's NAT64). They were not by fiat declared invalid. The actual thing I think you're complaining about - the necessity for NAT64 at all - is unavoidable, because you need a NAT/protocol-translation layer for packets to actually move between the new address space and the old one.
SLAAC-by-default is not, in my experience implementing IT automation, an actual barrier for adopters. You have a router sending out RS instead of a DHCP server, to an admin this is not a meaningful change.
NAT64 is a temp bolt on and also not the same thing. If I own 1.1.1.1 in v4, that doesn't mean I own some equivalent of 1.1.1.1 in v6. They had router nat64 and relay nat64, both with dealbreaker problems.
You don't exactly need a translation layer. If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual. Then after v4 is abandoned enough, I can sell 1.1.1.1.2:: to someone or use it instead of NAT.
SLAAC is a good design as a non-default that people who know what they're doing could enable, but a lot of people don't even want public v6 addrs for hosts, they just want NAT/DHCP.
> You don't exactly need a translation layer. If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual.
Think about this on a concrete, packet by packet level - I, from a v6 network, with a 128-bit address that cannot be represented by IPv4, decide to open a connection to 1.1.1.1. 1.1.1.1 doesn't have v6 set up, and so can't read my v6 packet and craft a response packet, because its address is invalid in v4. We need a gateway in the middle that will translate the packets from one format to another and perform the NAT function from one address space to another. This is an irreducible complexity.
> a lot of people don't even want public v6 addrs for hosts, they just want NAT/DHCP.
People don't care about whether their address is public or not, they want connectivity. SLAAC gives that to them; it is you that are insisting on adding complexity for the sake of having a non-routable address. As a user, I enable IPv6 on my router and go on my merry way; as an ISP, I assign my customer's router a /60 or /56 via DHCPv6 instead of a /24 and go on my merry way. Running an IPv6 address allocation system is a an easy, solved problem and has been for decades.
The hard problem is dual-stacking, and there is no way around that.
I mean, you own 2002:101:101::/48. You also own ::1.1.1.1, ::ffff:1.1.1.1 and 64:ff9b::1.1.1.1.
> If they just gave me 1.1.1.1:: in v6, anyone migrating v4 to v6 would have the same route to me as before, and other changes like DNS6 could be gradual
That's not really how routes work. Or DNS.
I think you're mainly arguing we should import v4's allocations into v6, but about the only benefit is that people don't have to bother requesting new allocations. It doesn't help with any other aspect of the transition, and there are good reasons to avoid doing it -- the v4 address space is highly fragmented and also very unfairly allocated.
Plus we have plenty of people saying we should take back v4 allocations from companies that own them. That's not possible, but _not_ giving owners of v4 /8s an entire 1/256th of the v6 address space certainly is.
It was a somewhat flippant (given that GitHub doesn't implement DNSSEC either) dig at the idea of using hand-entered/hand-updated IP addresses for access control, rather than having the access control system look addresses up in the system designed to securely attest owner/ip mappings.
(Almost nobody signs zones.) How is that any easier than just having an https:// URL from which you pull an (arbitrarily-formatted) list of IP addresses to block? Is the idea that you'd otherwise be able to do real-time DNS lookups on incoming IP addresses?
Yes - delay SYNs until an authenticated reverse lookup confirmed the IP was owned by a trusted domain. With caching to reduce common-case latency, which would otherwise be intolerable.
Assuming you're both referring to the events of 19 March, they did not eject from the F-35. I know of no event during this war where an F-35 crew ejected.
Commander-In-Chief is not a career military post, it is an elected politician. Your barefaced assertion that he would have professional-level knowledge is resting on one an array of assumptions - that he has an interest in the details, that he respects and listens to professionals, that he has the attention span to read written briefings - that reporting indicated are false.
The Nigerian type scams typically prey on greed; time pressure isn't part of the draw.
There's another class of scams where the draw is fear - "your son is in jail", "your bank account is under investigation and will be closed in 24 hours if you don't act now", &c. They rely on time pressure to prevent the victim from reaching out directly to the parties they're lying about and disproving the scam.
This is aimed at that particular type of scam and that particular type of victim.
1. Many Israeli Jewish Zionists are either "traditional" (religious but not that much) or Religious Zionist, and they are generally part of the right wing coalition. Actual atheists tend to be in the Israeli (still-Zionist) left.
2. The Zionist conception of Jewish identity is not "racial" in the American sense. The most obvious sense in which this is true is that it considers converts and their descendants full members of the nation. Probably the closest analogies are some Native American nations' identities or Armenian nationalism.
But you're directionally correct - Zionism is not a particularly religious ideology within the Jewish world, and outside of the Religious Zionist minority the political class is (openly!) on the less observant end even on the right.
reply