A basic understanding of what an IPv6 world will look like really didn't click for me until I read the IPv6 Address Planning book by Tom Coffeen. Before that, I really just saw it as IPv4 with longer addresses.
Once you dig into the details, you come to the realization that it's a nearly complete reinvention of IPv4. Network planning looks quite different (especially when it comes to subnets) when you plan them with only IPv6 in mind.
Earlier this year, I was like:
"Wow, Comcast gives me a /60! That should be more address space than I could ever want or use."
Now, I'm thinking:
"A /60 is way too limited, I wish I had a /52 or a /56 instead -- why is Comcast so restrictive with giving out address space?"
I'm currently reading the IPv6 for IPv4 Experts book to try to fill in more details:
[not OP, but hey…] There’s no need for DHCP with IPv6. Clients choose the last 64 bits of an address randomly. The address space is huge — zero probability of a duplicate address.
The first 64 bits therefore identify the network. If your ISP routes a /60 to you then you get to split that into 16x /64s.
That’s probably fine, but the IETF recommendation is to dish out a /56 to small sites and give them a /48 if they ask for it. ISPs usually have multiple /32s at their disposal.
It’s not about number of available addresses or networks. The joy of IPv6 is the addresses are so wide you can bring back hierarchical addressing. No internal routing chicanery is needed.
If your site has 64 buildings then a /56 lets you assign a /62 to each, with 4x VLANs in each building eg for printers, guest net, phones, lighting, admin, with even a subnet for each business function in the building.
Some way of automatically propagating that network prefix to anything connected to the network would be nice. Otherwise we're just stuck punching in IP addresses like barbarians.
Not sure what you mean, but there's definitely no need to type addresses anywhere.
Router Advertisements propagate the subnet information (prefix, dns server, etc.) to clients in the network. Prefix delegation allows downstream routers to request subnets from upstream routers. MDNS lets network devices announce their services to the subnet.
The good riddance part of IPv4 DHCP is the server maintained state. The broadcast-config thing is still there. RADVD is the standard Linux daemon for this.
> The address space is huge — zero probability of a duplicate address.
Not necessarily, there could be a flawed SLAAC implementation where the programmer just hard coded the default address after getting the PD. Or other some such silliness.
Yes it breaks spec. But there's enough devices out there that break the link local configuration spec that I would not be surprised one but if someone pushed out a broken implementation of SLAAC on a commercial product.
The idea is that there's SO much address space -- you should never need to consider a question like: "is /60 to /64 enough for all of my subnets?" when planning your network. Subnets should be created because they make sense from an organizational point of view. The amount of available bits shouldn't be a practical consideration.
Also, remember, NAT is highly discouraged, so you'll (maybe) eat up another subnet if you run something like Minikube on a laptop.
IPv6 has Stateless Address Auto-Configuration (SLAAC) as preferred method for address assignment. This allows clients to generate addresses for themselves as needed. For that to work efficiently, the address space needs to be sufficiently large that collisions are unlikely even in larger networks. Because of that, it mandates a subnet size of /64.
More generally, a big difference in v6 is that you no longer have to plan subnet sizes at all. Whereas previously you'd carefully choose the next available address to minimize address waste, with v6 you can just assign the addresses in whatever way makes sense to you.
How useful would that book (IPv6 Address Planning) be to someone not working specifically in networking/ops? I like developing applications and i manage, of course, my home network.
I'd love a book that gives me everything i need to know about IPv6. From justifications, to things to know when working with it, implementing it, using it in my local network, etc.
I don't perhaps need or care to learn it at a super low level, but i do want a complete understanding of it for my specific use cases. Applications and home networks, i imagine. For a novice in networks, to be clear.
For home you probably care about SLAAC, PD, the standard subnet size of /64, and possibly the Link Local differences (more out of curiosity of what those addresses show up on your machines for than needing to know to do anything with it). Also DNS is going to have AAAA records instead of A records and reverse lookups use a different zone, the changes in DNS are pretty 1:1 translational for admins though. If you want to go full on v6 you'll want to read about NAT64 so you can still reach the v4 internet from your v6 only home network. Also take a look at http://shouldiblockicmp.com/ even if you don't go down the path of v6.
For applications programming you'll want to have a feel for the above, IPv4-mapped IPv6 addresses, and review link local again to in particular note how to encode the interface in a socket call (useful for configurationless cluster communication).
Most every other detail of IPv6 changes should only matter to those that write networking stacks or make routers.
For all of the above info I'd recommend just reading the Wikipedia article on IPv6. Most of these are straightforward wrote memorization of best practices or background reasoning things so it's not "read a book" worthy if you're not trying to do this for a living IMO (coming from someone who does networking for a living).
They should have had either a smaller scope / simpler extension to IPv4 with a better backwards compat story for IPv6 only clients (some have since shown up a bit).
Or really done the reinvent - there were some interesting ideas especially for folks with lots of link handoffs (ie cell phones driving down a road etc) - can't find the write-up quickly.
I understand ISPs giving people subnets because there's an expectation that you'll be using a router. Each of your devices will have a public IPv6 address, obviating the need for NATs and CGNATs. That's neat, and that enables you to do all sorts of things like reliable p2p communication and servers.
But what doesn't make much sense for me is when you're given a subnet many IPv4 address spaces worth addresses on a single network interface on something like a server. Sure you could use that for a VPN, and I did set one up like that, but are there any more use cases? Surely there must be a good explanation why everyone is doing that?
It's actually crazy how late this was. Because customers don't like to see forty surcharges, you have an incentive to bundle relatively cheap things most or all customers want.
What gets bundled and what doesn't is somewhat† a matter of company preference. And once IPv4 exhaustion was on the horizon, charging IPv4 separately made a lot of sense yet very few providers did it.
† The EU hates "hidden fees". If your product claims to cost €100 but actually there's no way to only buy the €100 product, you need "delivery" for €25 more because there's no practical way to avoid getting it delivered - that's not legal. Likewise if you claim it costs €100 but there's no way to pay cash, and all card payments have a 5% surcharge, you're going to either have to eat that surcharge, or advertise the price including the card surcharge.
CGNAT is standard on mobile connections, it's more common than getting your own IPv4 address. Over the last few years, it's becoming increasingly common for residential connections, because ISPs can no longer get additional IPs for free from their regional numbering registry.
It's now cheaper for ISPs to deploy CGNAT than to purchase new IP blocks. Since IPv4 is provided for legacy compatibility, performance is not a priority.
> users' modem/router combos, and those are pretty fast and reliable
What? No, most of the infrastructure you see deployed at users home is trash. Majority of people don't buy their own network gear to replace the ISP gear they receive when signing up and ISP skimps on the costs of hardware for customers.
I was referring to Hacker News' lack of support for IPv6, however it is nice to see that ipv6.watch does support it.
To elaborate: I feel that the irony comes from an apparent desire by this website's users towards supporting IPv6, as evidenced by a few articles about the topic on the first page today; Raising awareness of IPv6 support on a site that does not.
> I wonder how many customers can realistically hide behind a single IPv4 (CGNAT), given that there are 65535 TCP/UDP ports.
In theory, one IPv4 address can maintain 65535 connections with every HTTPS server (TCP port 443) on the Internet simultaneously. The main cause of port depletion would be when lots of users connect to the same server.
A reasonable number is 1000 users with 64 ports each, but you could probably squeeze in another 10X.
It seems this site relies on a check for the domains' AAAA records to see if they support IPv6. Doesn't have anything to do with IPv6 in the products/apps that those sites offer.
We should have both, that's the point, to which you replied that "the site's intent is to show the general population's ability to organically reach those sites". I disagree with you, for many of those apps having only the website's status in the dashboard is insufficient.
I host Internet facing docker containers that support IPv6 with '--net=host'. For those who don't know, this allows to run a container with exactly the same characteristics as a normal process network wise.
I am not comfortable giving a container full control over the host network though. I have not looked into the security implications of it but I would expect it is dangerous for the host.
The problem with Docker is that assumptions of NAT and proxies are built-in quite deeply into the v4 networking functionality and defaults. With v4 it just exposes NATed rfc1918 space subnets to containers with a hardcoded prefix that's by default the same for all Docker installations in the world.
The sensible way to use it in the ipv6 world would be to give Docker its own globally routable prefix(es) acquired via eg dhcpv6 prefix delegation. The current manual prefix configuration is not how things should work in v6.
the 'funny' factor is totally unnecessary.. "yes" "no" or "somewhat" would have been much better and straightforward if you wanted to convey some information about the ipv6 status of these sites.
I've supported v6 on a few small sites hosting OSS projects for almost a decade now, and I kept statistics over the years. The increase in v6 adoption has been glacial. Less than 1% increase per year.
My own connectivity at home doesn't support v6 due to my ISP. At work, v6 is so badly managed it's the first thing we rule out when diagnosing connectivity issues.
Kind of a sad state really. I wish v4 prices increased tenfold, not barely double.
If I were to go to my CTO tomorrow and try to pitch them that this is a priority, what would I tell them? How do I justify this work? Marginally cheaper addresses don’t impact our scale compared to the work cost involved. We are big enough to be mentioned front page NYT at least once a month, but this just doesn’t seem to matter (yet) for us
There are latency benefits, which translate into higher user engagement metrics. If your site sells things or has advertising, that means you get more money.
It shouldn't be much extra work if you roll it into your other admin tasks. Any time you're turning v4 up, turn v6 up too and you'll get there easily enough.
Seems like it tests a limited list[0] of domains associated with the site or service, with the final result based on a check of their DNS records. For Steam, looks like it only checks <store.steampowered.com>, <steamcommunity.com>, and <help.steampowered.com>.
It'd be nice if the site provided an explanation of the process, maybe with some way to expand a particular entry and see which associated domains were tested and which succeeded/failed.
Like another commenter mentioned, it would be nice if there was a detail page showing what no, partial, or full support means. I plugged a few of these into https://ipv6-test.com/validate.php (a random site I found) and store.steampowered.com has no AAAA record, twitter.com has no AAAA record (this site says it has partial support), www.ubuntu.com has an AAAA DNS record, an IPv6 webserver, but not an IPv6 DNS server (this site says its supported).
There’s probably a good reason for it, but I’ve never understood why IPv6 couldn’t be fully backwards compatible. Then there would be no need to migrate - everyone would be already on IPv6 by definition.
I’m mostly still annoyed about the colon. Come on, ip:port is a pretty widely used convention people! The number of parsing bugs I had to fix with the migration…
It is today, but what about at the time it was picked? Software from that era (e.g. telnet) take their hostname/service arguments as two strings (e.g. `telnet 127.1 ssh`). I believe ip:port comes from URLs, the RFC for which was published at the end of 1994, which is about the same time that v6 was being developed. So it's not clear that the fault isn't on the URL side, or on the side of software using URL conventions when they're not using URLs.
Note that staying with "." wasn't an option, due to ambiguity with DNS. (Consider something like "2001.db8.3.4.5.6.7.be": is that an IP or a hostname under .be?)
You can't fit the bigger address into the v4 address field, on the wire or in API/ABI. Also, conflating them would bring massive confusiin when v6 and v4 hosts can't reach the same addresses.
They could have at least let ipv6 only folks talk to ipv4 more easily. Something like 464XLAT maybe built in out the gate more? You go ipv6 until next hop is IPv4. If you are in IPv4 mapped address space translate to IPv4 there and continue.
NAT64/464XLAT exists and it works. It can't really be "part of the protocol" because it depends on stateful IPv4 devices in the middle of the network. Ultimately it's up to the ISPs which IPv4-as-a-service mechanism they want to deploy.
> They could have at least let ipv6 only folks talk to ipv4 more easily.
And how do the IPv4 hosts talk back?
464XLAT is one solution, but it requires infrastructure to be in place to perform the protocol translation. The protocol alone isn't enough to allow interoperation.
That table isn't very helpful. What does it mean for Arch Linux to have IPv6 support? When you say "Amazon" doesn't have IPv6 support, do you mean AWS, the retail store?
It would be better if instead of linking to say, archlinux.org, you link to the actual page describing what specifically about Arch is IPv6, same for all the other endpoints. I would also replace the support sentence with a green/yellow/red color checkbox, and get rid of the twitter link.
Generally, when people write "Amazon" they mean the store (amazon.com) and when people write "AWS" they are referring to the infrastructure provider.
I agree that the URLs being tested should be visible on the page, so you don't have to lookup the source.
With that said, not sure how useful it is to say that (aur.)archlinux.org has IPv6 enabled, what you really care about is the repositories and so on, but those are all spread out so it'll be hard to test all of them. At least could test the official mirrors.
You and I have very different opinions about what constitutes a major website. Gentoo isn't exactly on a lot of people's bookmarks bar. Maybe try https://www.alexa.com/topsites instead, and you can give adoption statistics by hits/population rather than number of sites.
I assume this is referring to SLAAC? SLAAC is...fine. Most managed networks will want the extra control offered by DHCP though and DHCPv6 is currently in a much much worse state than DHCPv4. Also a single interface having at least 2, usually 3 or more (link-local, autogenerated, privacy) v6 addresses on the network is definitely not simpler in any way. Also clients still have not figured out which configuration methods they should actually support - Linux network managers generally default to SLAAC-only and DHCP needs to be explicitly enabled, for Windows setting managed flag in RA works, I believe. Android does not support DCHPv6 at all.
> network renumbering and router announcements when changing network connectivity providers.
Absolutely not. Network renumbering is a breeze when all you need to change is the public address of your gateway and the local network keeps the same local addresses. Prefix translation is awful and no firewalls have good tools to handle changing your v6 prefix.
> It simplifies processing of packets in routers by placing the responsibility for packet fragmentation into the end points.
With respect to fragmentation - yes, but overall this statement is blatantly false. v6 packet processing by routers is much much harder due to the variable length headers.
> The IPv6 subnet size is standardized by fixing the size of the host identifier portion of an address to 64 bits.
Ok, this one is true. Not entirely sure why the author considers this better, but sure, I'll agree.
To add to this, what I would like to see in IPv6 personally:
1) Ability to get a personal prefix as a private individual or a small company (not a LIR or LIR-sponsored)
2) Ability to use that prefix with any ISP I choose - similar to how a consumer can migrate their cellphone number to a different provider.
3) RFC 6275 actually implemented
There are other bits and pieces, but I believe if these with 3 things were done, IPv6 would actually have a "killer app" which would make a strong argument for migrating over to v6.
> the local network keeps the same local addresses
If you need that, you can assign local addresses from the ULA range. No one is forcibly taking your local addressing away. Now, yes, the "V6 ideology" is about globally routable public all the things, but you don't have to follow it.
1) You generally do not need prefix delegation in v6: you use IPv6 like it has been designed too: routable address everywhere, /64 per default and prefix over it.
2) SLAAC is stateless and deterministic: One MAC address will always gives you the same IP. That makes DDNS mostly useless.
But even if you really want to do it, it is also possible with SLAAC.
1) Precisely because you are not supposed to use NAT with IPv6 you need prefix delegation: CPE (home router) in addition to an external address (can be obtained via SLAAC) needs a network prefix (/64 or more) which it can use for LAN segment(s). DHCPv6 PD is also used in 464XLAT.
2) Address with SLAAC is deterministic but you need to know MAC address for each device to generate DNS zone. In home LAN I don't want to maintain a database of MAC address for all devices (with internet connected everything there are quite a few of them) and also at home I trust my devices not to spoof hostname in DHCP request so DHCP based DDNS works fine for me.
At this point most of them do, but also require customers to explicitly opt-in. I think cloudflare is the only exception there, it won't even let you opt out unless you're on a paid plan.
The low Ipv6 domain adoption is due (in my opinion)
To not every one have Ipv6 so in your dns you need to have ipv4,to not lost this audience.
After it can be related to protection system like waf.
The majority of isp give a /60 cidr to every one so it's easy to have a lot of ip. Some company like cloudflare have a mapping system from Ipv6 to ipv4 (of course with a lot of collision) and low number of procetion service provide a good detection system for Ipv6 one
So majority of system in customer stack is not ready for Ipv6
I can understand you will not consume some time for low number of benefits.
That is not advisable right now as you'll cut off a lot of users. Some providers like unglei.ch do offer an IPv4->IPv6 proxy if you absolutely don't want to deal with IPv4 though.
Sort of seems like it doesn't matter who uses ipv6 on their servers, then. If ipv4 is mandatory, who cares that you COULD connect another way? Isn't the first step getting all clients able to use it?
Once you dig into the details, you come to the realization that it's a nearly complete reinvention of IPv4. Network planning looks quite different (especially when it comes to subnets) when you plan them with only IPv6 in mind.
Earlier this year, I was like:
"Wow, Comcast gives me a /60! That should be more address space than I could ever want or use."
Now, I'm thinking:
"A /60 is way too limited, I wish I had a /52 or a /56 instead -- why is Comcast so restrictive with giving out address space?"
I'm currently reading the IPv6 for IPv4 Experts book to try to fill in more details:
https://sites.google.com/site/yartikhiy/home/ipv6book
The more I read about it, the more I feel like I have a long way to go before I really get an intuitive understanding.