171–180 of 480 posts
Earlier quoted context omitted.
So, what happened to everything that expected 1.1.1.1 to error out and now is getting something? (not worried about them, just curious)
Well, a lot of Cisco wireless engineers had to reconfigure their guest wifi captive portals.
Earlier quoted context omitted.
Then there are a lot of ISPs to blame: https://www.google.com/intl/en/ipv6/statistics.html
By that chart, the IPv6 rollout will be basically complete by 2030. I suspect it will speed up near the end though as the first few services start to go V6 only.
I sure as hell wouldn't want to be the canary in that coalmine...
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…
Fitting more than 4B numbers into 4 bytes is mathematically impossible, but building a backwards compatible and easier to integrate standard may not be. Take USB for example. The capabilities of USB 3.1, 3.0, 2.0 is impossible to achieve for USB 1.0. So is high-speed charging. However, the end-user experience is generally pleasant, nitpicks around some of USB-IF's specific choices aside.
The "end-user experience" IPv6 equivalent of the USB version transition is that a person browsing to "www.google.com" has no clue whatsoever that it actually went via IPv6 instead of IPv4.
Just like with USB 1 to 4, IPv6 goes down the same cables and works the same at the application layer. Some changes occurred, but changes are mandatory for things to change.
You're asking for USB 4 to be magically "the same" as USB 1.0 while sending tens of gigabits over the wires -- not for the end users -- but for the lazy electrical engineers that can't be bothered to update their designs!
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…
Fitting more than 4B numbers into 4 bytes is mathematically impossible, but building a backwards compatible and easier to integrate standard may not be. Take USB for example. The capabilities of USB 3.1, 3.0, 2.0 is impossible to achieve for USB 1.0. So is high-speed charging. However, the end-user experience is generally pleasant, nitpicks around some of USB-IF's specific choices aside.
This is a fundamental problem. Backwards compatibility (without introducing translation schemes and middleboxes) is literally impossible.
Earlier quoted context omitted.
Could starlink be a way to maintain global connectivity in the face of government control? Would they try to jam satellite connections?
Starlink is under USA jusrisdiction, as far as I know. I'm pretty sure there's no concept of "international waters" for communication satellites.
Earlier quoted context omitted.
How do you not break compatibility with IPv4 while also getting more bytes in the address?
Well again I’m not a network expert but perhaps we could look at the 240.0.0.0/4 reserved for future use block and add more address bytes in the payload or something. It’s not going to be elegant but IPv6 is kinda elegant and failed.
> perhaps we could look at the 240.0.0.0/4 reserved for future use block
What's the current rate of v4 address space consumption? How long will this block last?
> and add more address bytes in the payload or something.
This is, by definition, not backward compatible.
Earlier quoted context omitted.
Fitting more than 4B numbers into 4 bytes is mathematically impossible, but building a backwards compatible and easier to integrate standard may not be. Take USB for example. The capabilities of USB 3.1, 3.0, 2.0 is impossible to achieve for USB 1.0. So is high-speed charging. However, the end-user experience is generally pleasant, nitpicks around some of USB-IF's specific choices aside.
How does a host that thinks there are only 4 billion addresses send a packet to a host with an address that falls outside of the 32 bit v4 space? This is a fundamental problem. Backwards compatibility (without introducing translation schemes and middleboxes) is literally impossible .
But no, someone said we must redo whole stack and we need every piece of sand to have public routable address..so now we are stuck between rock (old fossilized IPv4) and hard place (completely incompatible IPv6).
Earlier quoted context omitted.
> IPv6 is as backward compatible as is possible within this constraint. Yikes, couldn't disagree with that more. There are a ton of things that ipv6 designers could have done to make the transition much easier. This is a (now quite old) blog post that is my "go to" that explains a lot of the problems with ipv6: https://cr.yp.to/djbdns/ipv6mess.html FWIW I couldn't find the link to that post until finding it on one of…
That document has been going around for ages and is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients. This is just not possible. Most of the other criticism is not relevant anymore, since we now have a lot of transition technologies that allow IPv6 clients to interoperate with IPv4 servers (this way around is possible since…
Let me summarize my understanding of what he's saying, because I don't quite see why/how you disagree. I think you (or I) might be misunderstanding his claim.
Imagine this topology: C (client, IPv4-only) R (intermediate router) S (server)
My understanding of djb is he's saying that IPv6 could have been designed such that S could still serve C via only simple software updates -- this means, crucially, without the need for S to separately obtain a public IPv6 address through R, because its IPv4 address would be automatically valid for IPv6.
How can this work? Well, there are two scenarios:
1. If R is IPv4-only, then S could figure that out during some startup/negotiation process, and send only IPv4 packets to R. R only lets IPv4 clients connect to S anyway, so any response (even from IPv6 applications) on S must be going back to an IPv4 address. So the kernel can transparently translate those IPv6 addresses into IPv4 before passing them along to R, and vice-versa.
2. If R supports IPv6, then R can do the same thing S would've done in the previous^ scenario. (In fact, I think S could become IPv6-communication-only in that case, reserving IPv4 for just address leasing? I'm not sure, but in any case, I don't think that matters here.)
Notice that all of this is almost completely stateless. (I think the only state S needs to track here is 1 bit, indicating whether R supports IPv6 or not.) So, S and R can be independently and (importantly, rather trivially) upgraded to support the IPv6 protocol, without losing the ability to talk to any clients within the IPv4 address range.
This is easy and requires no explicit leasing of IPv6 addresses. That step can be implemented and have support for it added later, whenever S is ready to serve clients beyond the IPv4 address space.
Does this make sense? If so, then it seems to show how IPv4-only clients could talk to IPv6 servers without modification. If not, then I'd love to see where I'm mistaken (I very well might be).
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...
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…
That would have saved a lot of pain.
Earlier quoted context omitted.
I actually went through this process with ARIN. So I can give you that perspective. It wasn't a big deal, the only minor concern I had was it felt like you're encouraged to sign up under a business entity. I had an LLC, so it was natural just to use that. I don't know what kind of vetting they do if you decide to use yourself as an organization though instead of a different legal entity. You need to provide justifica…
Is there a way to get a /24 block that I own and has been unused since the mid 90's routed without signing a new contract and paying the new ARIN fees?
https://www.arin.net/resources/fees/fee_schedule/#legacy-reg...
So you won't be subject to the new fee structure.
If you want to route then you will need an ASN and an ISP willing to announce them. So long as you are up on your LSRA dues I don't see how you won't be able to utilize them.