DistroWatch Finally Adds Support For IPv6 (distrowatch.com)

We've frequently linked to DistroWatch for their coverage of Linux package and release announcements. Now an anonymous reader writes: The DistroWatch website introduced IPv6 support on Friday and the new protocol has been getting a lot of attention. "Over 8% of our traffic this weekend came from IPv6 addresses," commented DistroWatch contributor Jesse Smith. "It was a pleasant surprise, we were not expecting that many people would be using IPv6 yet."

When asked why DistroWatch enabled IPv6 access to their server at this time, Smith answered: "Partly it was an experiment to see how much interest there was in IPv6. Partly it was because it is a little embarrassing (in 2016) to have a technology focused website that is not making use of IPv6."

Comments

Speaking of embarrassing...

[QuietLagoon]

Partly it was because it is a little embarrassing (in 2016) to have a technology focused website that is not making use of IPv6."

Amazon AWS, are you listening?

Re:IPv6 is a failed technology

[Rising Ape]

BT and Sky are in the process of introducing IPv6. Google are now showing over 11% UK connections via IPv6, compared to something like 2% at the start of the year.

Random is the DEFAULT (which may be silly)

[raymorris]

Well, it's the default setting for the operating systems favored by those "less knowledgeable", so that pretty much covers that, doesn't it. Android (the world's most popular OS), Windows (your grandparents most popular OS), and iOS (hipsters most popular OS) all randomize the address by default.

Whether or not that's a GOOD idea is certainly debateable, but it's what you wanted.

So the less knowledgeable, people who don't even know what IPv6 is, get a randomized address. People even less knowledgeable than that make panicky, mis-informed posts on Slashdot about OMG I'll be tracked.

Re:IPv6 is a failed technology

[Yaztromo]

Since you consider yourself an expert, would you care to explain why you think that IPv6 is especially routable?

Sure. There are a lot of things that will make IPv6 easier to route:

• - Simplified packet processing: there are a variety of features in the IPv6 packet header that simplifies processing by routers. Included here are:
  • - Fixed header size: unlike IPv4, IPv6 has a fixed packet size of 40 octets, whereas IPv4 packets can vary between 20 and 60 octets,
  • - Lack of header checksum: IPv6 has no header checksum (thus removing the need to either compute or verify the checksum). This is actually pretty big, as each router hop needs to recompute the checksum as the TTL value is decremented in order to remain valid,
  • - TTL replaced by Hop Limit: this one is a bit complex. In IPv4, Time-to-Live is specified in the header as the total number of seconds the packet should be routed before it is dropped. This is tricky to compute, so even in IPv4 many nodes simply decrement it by one regardless of how long it has taken to process. In IPv6, this is changed to be a straight hop count; the value in the header basically specifies how many times a packet can hit a router before it is dropped.
  • - Gets rid of unused fields: IPv6 gets rid of a lot of header fields present in IPv4, such as the IHL, DSCP, ECN, and everything related to fragmentation.
  • - Lack of fragmentation: IPv6 packets can't be fragmented. Routers don't have to fragment or defragment packets. This can also mean fewer overall packets, and also means the router doesn't have to parse or generate a pile of fragmentation fields and information from the packets being sent/received.
• - Traffic Class header field: IPv6 has a field that can be used to differentiate services, and can be used for QoS, allowing the router to more easily prioritize and arrange traffic.
• - Flow labelling: IPv6 has a header field for flow labelling, that can be used to do things such as ensure stable routes for packets, such that packets aren't received out-of-order at a destination. This is intended to make streaming data (such as video) more stable, and can replace custom heuristic algorithms at the router layer with something much simpler,
• - Jumbogram support: IPv6 packets can be up to (2**32)-1 octets in size (1 byte less than 4GB). While not practical today on the public internet, bigger packets can mean fewer (albeit bigger) packets that need routing,
• - CIDR and smarter address allocation: CIDR was invented for IPv4 of course, however IPv4 didn't use CIDR until ten years after Flag Day. Pre-CIDR address allocations were ad-hoc; address blocks were classful (A, B, C). Many of these classful allocations still exist, however because of they way they were assigned, it was (and is) difficult to aggregate these routes. IPv6 came about long after these lessons were learned the hard way, and thus the IANA is being much smarter about what addresses are allocated where in order to better aggregate routes. Thus, a given /32 will be doled out only to a single RIR, who can break it up into smaller units to LIR's, to eventually be broken into /48, /64, and /56's for destination routers. IPv4 also works this way, but with the much bigger address space (and the lack of legacy pre-CIDR allocations), and with smarter allocation policies in place, route aggregation will make the possible mess that is the current state of the IPv4 routing tables significantly saner. From a processing perspective, this means that next hop lookups should be significantly quicker and easier. IPv4 currently has over 610000 prefixes; way more than should be needed. This is partly due to, as addresses have run out, large CIDR blocks being broken up into smaller blocks