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
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.
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.
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%...
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 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.
I seem to recall general recommendations that ISP's assign at least /56 to customers?
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.
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.
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.
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.
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.
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.
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.
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.
If it's only used in development, it's not too big a deal, but could still be use to compromise things.