@CandidDevOps@MrCoolCow@davepl1968@geerlingguy For Joe casual, the bandaid keeping IPv4 together, make it appear to be working, it's been completely broken since the introduction of NAT. Whenever an application would benefit from direct connections between 2 parties, you need to jump through lots of hoops to make it work.
@tacogs@davepl1968@geerlingguy You could also represent IPv6 as 16 octets with values between 1 and 255. If you'd like. The computers don't care how humans format the adresses. The IPv6 hex notation were most likely choosen because it's easy to work with, when doing calculations, and shorter.
@tacogs@davepl1968@geerlingguy That's exactly what IPv6 did, in regards to adresses, the addresses are represented as a 128 bit value instead of a 32 with IPv4. With your version, the addresses would be 40 bit, but would still not be compatible with IPv4. IPv4 has 32 bits for addresses, no more, no less.
@tacogs@davepl1968@geerlingguy Well, apart from extending the addr. space, what solution could be implemented that would't break existing stuff? As I see it, there's no way to extend the available number of addrs not breaking compatibility. But had we acted in time, there'd been less legacy crap to consider.
@tacogs@davepl1968@geerlingguy If ISPs get allocations that are easier to split between their customers, they need to advertise fewer routes, which will, if not reduce the tables, at least not add many more entries than we have today. Advertising 1 /32 or larger IPv6 block is less than 100 /24 IPv4 blocks.
@CandidDevOps@MrCoolCow@davepl1968@geerlingguy If we are to critique the protocol, the problem should be in it's design, not how it's used. With that logic we should drop a lot of technologies that are "poorly implemented". Admins not doing thier job properly, can never be the fault of IPv6.
@tacogs@davepl1968@geerlingguy They are huge for ipv4 because aggregation is hard with so many small allocations due to not enough addresses. With IPv6 you can aggregate the subnets much better, as you get a larger allocation. This leads to fewer entries, though granted the entries you do get are larger.
@cnewton_ky@davepl1968@geerlingguy NAT solved NOTHING. It just added more complexity, and caused it’s own problems. Lots of things were REALLY broken, when we moved from single device dialup to always on natted connections. Sure a lot has been solved. But many uses are more complex or even impossible due to NAT.
@FlyingToMarscom@geerlingguy I only hear people hate it, due to the way addresses are written. I’ve heard no other arguments so far, that can not be summed up to “lack of adoption and lack of care by vendors”. What mistakes exists in the IPv6 design, that should be a reason to scrap it?
@LaughingBrook@davepl1968@geerlingguy The /8 were chosen at a time when computer power were limited, but things still needed to be efficient. When decoding the addresses a pattern of 01111111 meant the packet were destined for the computer itself, by examining just 8 bits. Fast and efficient on 1965 hardware.
@cnewton_ky@davepl1968@geerlingguy The only difference in the addresses and addressing, if how we write the addresses for human consumption. Machines handles ipv4 and ipv6 exactly the same.
@tankerkiller125@davepl1968@geerlingguy CGNAT is no different from NAT in your home router. It’s just more users on the inside, and the routers can handle more traffic.
@tacogs@davepl1968@geerlingguy NAT “solved” the issue, by creating lots of new issues. Ask VoIP providers, game developers etc. about how easy it is to broker direct connections between endpoints, when low latency is important. With the way things are going we’ll soon have multiple layers of CGNAT added in.
@NielsGraversen @kjaerulv Der er både en kodeviser man kan bestille gratis og en usb enhed man kan købe der kan bruges i stedet for mobilen. Så man kan godt få mitid uden en smartphone.