Yes. It offers better scalability! E.g. at my university, our institute has its own IPv4 /24. That means a maximum of ~253 or so devices. We have exhausted that number and for every new client, an old one has to go. Now with a /64 this would be no problem at all.
To mitigate this the IT department is currently using VLAN-tagging for some of the devices. But it gets convoluted. And the more convoluted it gets, the higher is the chance for misconfiguration, errors, and security issues. Yet, they don't want to make the switch to IPv6 already.
In IPv4-land, it's not an 'internal network' if every device must have an externally routable address - if it is required, IPv6 has an obvious advantage.
In the requested scenario (internal Enterprise network), the proper comparison should involved IPv4's 16 million private addresses; I can't see any practical advantage to IPv6 there.
It's an internal network if it's inside your networking perimeter. The type of addresses you use on it are irrelevant to that.
Most enterprise networks need to be routed to other networks -- either other networks inside the enterprise, networks inside other enterprises or the internet. To make that work sanely all of the networks involved need to use address ranges that don't overlap. RFC1918 is pretty much the definition of overlap, and using it makes things way more complicated than they would otherwise be.
It's fine for IPv6 engineers to want to make everything directly routable, but in IPv4 the difference still matters, and therefore that's the scenario we need to compare against.
The IPv6 enterprise argument is 'You might one day have to renumber some devices because some other enterprise might have set up overlapping addresses, therefore you definitely have to renumber everything now, and oh, every time the ISP decides they don't like you, because private addresses are icky'. Obviously that's a hard sell.
> The IPv6 enterprise argument is 'You might one day have to renumber some devices because some other enterprise might have set up overlapping addresses, therefore you definitely have to renumber everything now, and oh, every time the ISP decides they don't like you, because private addresses are icky'. Obviously that's a hard sell.
If you’re an enterprise you would just get your own IPv6 block assignment. It’s not like they’re expensive or hard to get hold of.
Companies already buy and manage domains, this is no different. Using a domain you don’t own is just plain stupid, same applies to IPv6 ranges.
Or you could just say screw it, and use RFC4193, and then all you need to ever worry about is prefix remapping at a few key touch points. Particularly if you don't care about external routing in the first place.
16 million is way too few because of collisions and the birthday paradox. Even with a tiny corporate network, you are likely to connect to other companies’ networks, and, with private addresses, no one coordinates allocations. Collisions are quite likely.
Also, the major players probably have more than 16 million devices, especially if you could VMs.
Every sane large internal network is segmented. I doubt all the "more than 16 million devices" need to talk to every other device. The IPv4 limit is an annoyance, but not a big one for the typical internal networks.
When my internal network connects, via any non-NATed means, to a vendor’s internal network, there is a chance that my addresses conflict with theirs. If the vendors have even a few tens of clients, this risk is quite high.
He didn't say "all", he said "many". And that is factually right. Many ISPs use DSLite/CGNAT and don't hand out public IPv4 addresses to their customers anymore. Yes, some offer the option to change to a public IPv4, some charge extra money for this feature, and some don't offer it at all!
E.g. my ISP doesn't hand out public IPv4 and you can't order it, unless you change to a business contract. However, my ISP is doing some weird 1:1-NAT, so while I don't get assigned a public IPv4 to my router, I do get assigned a single IPv4 on the CGNAT router that also translates back to my home network.
Yes, it seems like it is behind the times. It doesn't matter much at the moment, as there are no real IPv6-only services of relevance (unless you need to connect to the private IPv6-only NAS of a friend or sth like that).
That just proves you haven't understood IPv6 yet. ULA addresses make it much easier, e.g. fd00::1 or fd00:2 (though this is bad practice, should be fdxy:zvwx:xyzw, xyvwz being random).
Their business seems to lie elsewhere. This appears to be a minor service they offer free of charge to the IPv6-interested community, maybe to promote IPv6 usage.
So same trust you put in any 3rd party DNS service. But I agree there's less contractual bindings to this service than an account somewhere that you even might pay some money for it.
I guess the point of all this discussion is "don't trust a random guy on the Internet that offers to host DNS for you", but also we place way too much trust on DNS.
Exactly, but if you own it and add `PTR` to `has-a.name` then in turn you give them power. They can request a new certificate under that name and point that host to another IP. I'm sure there are other ways to abuse it as well.
They can do that even if you don’t set a PTR record... since they own the domain, they can get a certificate for it. The danger comes not because you set a PTR record, but because you use that domain at all.
Really, this is the same risk you take with any registrar... they could give the domain to someone else, or alter the DNS to give themselves a cert. This is basically making has-a.name your domain registrar, and you have to trust them to not behave poorly or have bad security.
Yes, but what's your point? You seem to understand DNS enough and at the same time you don't seem to see the obvious security implication, are you affiliated with that domain?
No, I am not affiliated with them (though we follow each other on Twitter). My point is, I don't see any security implication involved with a wrong PTR record in relation to this service. If I set the PTR of my IP to this domain, but the domain itself resolves to some other IP. Or are you implying they can only request a cert if the PTR matches the domain? At least for LetsEncrypt this is not true, otherwise home owners with dynamic IPs wouldn't be able to request certificates.
If you provide PTR that points back to that name, configure web server to handle requests to that name, you basically makes the domain an official one.
As your users start using it, the owner of the name can now point the AAAA record to another server that will act as a proxy, request a new certificate (he owns the domain) and see all the encrypted communication.
Yes, you are missing something: S3 bucket resolves to Amazon's servers. <ipv6>.has-a.name resolves to the ip address specified in <ipv6>. You will have to install the certificate on the actual server that serves the webpage. For S3 bucket this is Amazon, so they can put their certificate. For your own IP, you need to install the certificate yourself, so they would have to hand you their private key as well, which is not allowed.
Yup. This is one thing I hate about AWS. Oh sure make it nice and easy to use the wildcard cert on any AWS infrastructure. But what if you want to use that wild card cert somewhere else? Too bad. AWS holds the private key for your wildcard cert, and they don't give it to you. They hold it hostage on their server.
Considering the domain is amazonaws.com, it is only fair they keep it with themselves. They can't be in the business of providing arbitrary subdomains under their parent domain just to have it point to some other external IP.
I'm talking about custom domains. You can setup AWS to manage certs for mycompany.com (for example). When you do that they ought to give you a copy of the private key to *.mycompany.com. I am not talking about the amazonaws.com certs.
>Uhhh, I am really glad they don’t share it with me or anyone else
It's your domain, you ought to own it. Obviously no one else should. If you buy a wildcard cert from say Comodo (or a number of other cert houses) you can use that cert on any provider you wish, or use it on your locally own infrastructure. You get the private and public key, as you should.
