Giving every IPv6 address a name
has-a.name
has-a.name
Maybe it would make more sense to choose the 65,536 most common English words (or whatever language you want) and break the address up into 8 words to form a crazy looking phrase. This is still difficult to memorize but not as bad as just stuffing 128 bits of hex down your throat. You could even allow for the collapsing 0s by making entry 0 be "and" and adding a bit of logic that does the collapse.
For fun I wrote a tiny script that does this and tried it with their example domain:
1234:5678:9abc:def0:1234:5678:9abc:def0 -> balcony gaining pawn toothill balcony gaining pawn toothill
Or Google's address from that page:
2a00:1450:4009:811::200e -> chinker bauchle dorter amor and bromidic
So maybe this wasn't the best idea, but at least they're a bit more amusing than the hex noise in the article.
Anyway, if anybody else wants to play around with it I have a tiny demo: http://jubei.ceyah.org/cgi-bin/ipv6toenglish
2001:db8:2d1::1 for the router on that VLAN (10.10.0.1)
My DNS servers are on a single tagged vlan 10 (they are 10.10.10.11 and 10.10.10.12):
2001:db8:2d1:a::11 and 2001:db8:2d1:a::12
I wont be using that site or anything like it. DNS does the trick for me along with documentation, just as it does for IPv4. I toyed with ULA addresses (a bit like RFC 1918) but dropped it because it adds complexity. You only need a few addresses to bootstrap a network and a change of ISP will have more hassles to deal with than a prefix change.
I seem to recall general recommendations that ISP's assign at least /56 to customers?
I suggest you have a play with the /64 just for fun and to get the hang of things but the future has a shed load of IoT in it and all networks will need breaking up into subnets for security, including residential networks. Even if only to separate guest wifi.
In the UK we have the relative luxury of being able to choose from a fairly long list of ISPs. Some of them nearly get IPv6. Funnily enough dear old BT (business) is one of the few that gets it all correct out of the box, when you order a leased line.
You have my sympathies.
There are cases where you simply want to use a name during development because it generalizes better for the eventual production case, but you don't care what the name is, you don't care if anyone can memorize it, you just need it to be a name and not an IP address.
Number of IPv6 addresses: ~340 undecillion [1]
Length of string of words: ~8.4 [2]
Probably closer to 8 as what3words likely doesn't cover the full 3-word-address-space of the English language.
[0] https://en.wikipedia.org/wiki/What3words#cite_note-16 [1] https://en.wikipedia.org/wiki/IPv6#cite_ref-rfc2460_2-2 [2] https://www.wolframalpha.com/input/?i=log+base+38485+of+340%...
My dictionary excludes all proper nouns and all words longer than 8 characters. Only about 60% of the 8 character words were used, chosen completely at random. Even so, given a full IPv6 address the resulting "phrase" is a mouthful. Shortened addresses are a little easier to deal with.
sprint.net has address 208.24.22.50
sprint.net has IPv6 address 2600::
wonder which one is easiest to remember? =)
/s
All they are doing if pointing to your IPv6 address, anyone can do that, that is why DNS TXT validation if needed in the first place.
If you host your site at foo.example.com, then example.com can get a wildcard certificate for *.example.com that will be valid even if you have your own foo.example.com certificate and they can also change the A or AAAA record for foo.example.com to get a certificate with an HTTP challenge.
You could always petition browser vendors to pin your foo.example.com certificate, and thus override any tampering by the example.com DNS server. It is exceedingly unlikely they would do this for you.
TLS certificates these days only prove one thing: control over the DNS server at the time of provisioning.
However, the OP wrote this:
> but keep in mind that the operator can also get SSL certs for your site
Which made it sound as if they can get a cert for your domain, which they cannot.
Why? They own and operate the DNS server for has-a.name, so (if they wish to) they can just add any record that they wish, to any domain, right?
Of course this is true for any registrar, but that's also why not anyone can just become a registrar.
PSL (https://publicsuffix.org/), DNS Certification Authority Authorization , and Certificate Transparency could be combined so browsers are allowed to know who can sign what, who's a registrar, and who's doing what.
DNS Certification Authority Authorization assumes trust of the DNS server. Doesn't work if the DNS server itself is compromised / malicious. (Maybe with DNSSEC, but DNSSEC has its own problems and definitely doesn't work when your TLD itself is compromised.)
CT is really the only thing that works in this scenario (attackers/third party gaining write access to DNS records), but not every CA has CT and not everyone has the means to monitor CT logs. CT isn't even required for every browser/certificate (only EV certs (dead) for Chrome, and you need HPKP (dead) or Expect-CT (no browser support) for this to work reliably). Plus, what are you supposed to do when you find out there's a bad cert for your domain out there? Yell at someone on Twitter? It's going to be hard to convince a CA that you're not doing business with that someone with write access to DNS does not own the domain. Attackers are already impersonating you while it takes hours to sort things out.
... all of this is not to say that these security measures are bad, just not enough. We really put more trust on DNS servers than we ought to.
Chrome and Safari both require SCTs (the signed timestamps which prove a certificate was logged) for all new certificates, have done for quite some time. There are CAs which issue certs without logging but largely it's for applications which themselves know about SCTs so they can do the fix-up at runtime not issuance, because again if you just added these certs to a generic web server Chrome and Safari, two very popular browsers, will reject the certificates outright.
Since they'd be next to useless to lay people without, all the certs offered to the general public these days have SCTs baked in by the issuer. Let's Encrypt were ironically among the last to do this.
CAA does rely on DNS working, which your registrar can probably hijack. Fair point.
CT would help protect against the registrar but not against a malicious CA who simply wouldn't log if they were going to sign a cert maliciously.
You're generally right though.
1. They complete a DNS challenge and get a certificate for "\\*.has-a.name" - which obviously includes your subdomain.
2. They sneakily point "your-address-here.has-a.name" to an IP they control, get a certificate issued, then point it back to where it should go.
The second option is more hassle, and easier to notice, but the first makes it needlessly complex.
Of course if your actual domain is "bob.com" then this is just a distraction. We're using "your domain" in this case to refer to the subdomain that points to your IPv6 address.
The domain name will still be 'has-a.name', so I don't understand how the certificate part is supposed to work. If anything you'd have to get their TLS cert for this to work, not the other way around.
If it's only used in development, it's not too big a deal, but could still be use to compromise things.
A certificate is for a domain name, not an IP address.
Anyone can point a (sub)domain that they own to an IP address that they do not own. And then get a valid certificate for that domain.
I can point an A record to [your-ip].[my-domain] and I will be able to get a valid cert for that address. However, the address in your address bar will still point to [my-domain], not yours.
A neat one is x.ip6.name, which resolves to ::, e.g. localhost...
https://1234:5678:9abc:def0:1234:5678:9abc:def0. should work just as well as https://1234-5678-9abc-def0-1234-5678-9abc-def0.has-a.name.
Right?
Of course, has-a.name will be rate-limited to 50 certificate a week by Letsencrypt until they get themselves onto the public suffix list. And whether it's a good idea to bypass LE's no-certs-for-ip-addresses policy is another matter...
In order for a wildcard to work, every single user of the service needs the private key for that wildcard certificate.
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.
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.
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.
Some providers like Tunnelbroker easily allow you to change the delegation for the reverse records for your delegated range: if you have the 1234:5678:9abc:def0::/64 subnet, they let you change the delegation of the *.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.ip6.arpa DNS zone or add records to it as you please.
So having a public service that responded to those (following the example, all you would need is the server to respond to 0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.ip6.arpa with a PTR record to 1234-5678-9abc-def0-1234-5678-9abc-def0.has-a.name) would enable you to also make reverse DNS work for all your network easily, as long as you delegate your reverse zone to that server.
Unfortunately probably only Tunnelbroker and hosting providers allow you to do this - I don't expect any residential ISP would (they would also probably provide their own reverse DNS, though).
Many of our customers are app developers (ruby, python, clojure, you name it) and they develop on their notebooks that are IPv6 enabled (usually a /64 or /48 per device).
To be able to share in-development state with other remote developers, the common thing to do would be to pass around a http://[2a0a:e5c0:...] url that was http only.
This is not only cumbersome (no one likes to type square brackets), but also potentially risky, as there is no MITM protection whatsoever.
To fix this problem we created has-a.name, because customers/developers now go ahead and just create a docker container and share it as https://2a0a-e5c0-...has-a.name with their co-developers.
Because our whole company consists of a bunch of Open Source Hackers we decided to make it public to allow others work around the same problem.
Even though we promise to never change the automatic resolution (that's work, doesn't make sense to do that for us), you don't have to trust has-a.name. You can register your own domain and replicate our setup and use your domain instead.
I hope that clarifies a bit the business model question.
https://www.ripe.net/manage-ips-and-asns/db/support/document...
DNS doesn't technically have the concept of forward and reverse - it's just record types and an agreed format that the PTR records should be.
I naively think '2001:ALN:LabNet01::' or somethig of the like is not only better but displaces some of the need to use dns (at least in a lan). I am so curious about this, I hope someone more knowledgeable can explain.
Clearly it's not a good idea to rely on this for anything serious so the value is mainly convenience during prototyping.
> With has-a.name you can now also use SSL certificates on any IPv6 address. Even better: any docker container can now have an official, valid certificate!
And you can use them with has-a.name: The domain fde4-8dba-82e1-0000-0000-0000-0000-0000.has-a.name is translated to address fde4:8dba:82e1:: just as expected.
Also, it's dangerous.
I always see these ingenious developments with IPv6. But we kind of forget that deployment is a nightmare.
I think we need forget that we're putting the cart before the horse.
I don't see a future for IPv6 while there's no officially endorsed transition plan that has an actual incentive.
IPv6 only makes sense for mobile since carriers use it to shed load off CGNAT. In turn this incentivises large traffic sites that cater to mobile (e.g. Youtube, Google, etc.) to also help out by operating over IPv6. The only reason carriers can do this is because they usually have full control to configure the IP stack connecting to the network.
Penetrating the residential is a pipe dream.
Let's not forget in the early to mid 90s IPv6 was decided on to mitigate the address exhaustion issue. Its use has basically made a scratch.
So many other technologies have come and gone and a few paradigm shifts (e.g. cloud everything).
And IPv6 continue to sits idle.
IPv6 is at about 30% of traffic now.