This is cool, but keep in mind that the operator can also get SSL certs for your site (they just point the domain somewhere else and use Lets Encrypt or similar to get a certificate). So from a security perspective, you are putting a ton of trust if you use this for anything real.
I don't think they even need to point the A record somewhere else. They can just create a TXT record and some CAs will allow you to validate it that way, if I'm not mistaken.
Presumably they could just get a wildcard certificate for *.has-a.name perfectly legitimately and then they can mimic every IPv6 has-a.name site they want.
whatever.has-a.name is the domain name they are suggesting you use, if you had your own you wouldn't need their service. So yes, you are basically giving them control that way. But for simple solution to temporarily get SSL to work on your container during development it's fine.
But in that case a self signed certificate works too.
I haven't looked at it from that angle yet, but you are right: If you share the whatever.has-a.name address with other people and tell them to trust it, then this is very dangerous.
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.
Obviously if you can sign a cert which is trusted by browsers, then you technically have the ability to impersonate anyone, but processes are used to fight against this.
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.
PSL protects the other way around: it can only prevent whatever.has-a.name to compromise has-a.name or another.has-a.name
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.
PSL could/should also stop sub.has-a.name trusting signed certs such as wildcard.has-a.name, depending on the configuration of the PSL. I'm just not really sure any actual browsers implement it like this though, as reading the PSL "how this is used page" doesn't turn up any such thing.
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.
If a CA "forgets" to add a certificate to the CT log, they need a really good excuse to not get distrusted immediately. That's part of the reasoning: malicious certs are almost useless if you don't present them to a client. And if that client manages to exfiltrate the cert...
You're a little out of date on Certificate Transparency.
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.
Wow, that's really good to hear. One of the chief complaints I have about CT is the lack of agency. Not that this solves all problems, but good on Chrome and Safari for enforcing it
They can get an SSL certificate for "example.has-a.name", i.e. your subdomain, in one of two ways:
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.
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.
ACME is entirely based on DNS. The HTTP and ALPN challenges look up which IP address to speak to via DNS. The DNS challenges look for a TXT record in DNS. (Letsencrypt tries pretty hard to ensure that the DNS is legitimately being served by looking up the IP address from multiple networks, so you can't disrupt one of their networks to issue fake certs. But it has no idea who really controls your DNS server or glue records.)
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.
As far as I understand, all they are doing is resolving the ipv6 address in the domain name to an AAAA record that matches the IP address in the name.
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.
No, this is nothing specific for Lets Encrypt, this is how PKI works.
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.
I think the implication is if there is a security breech at their end, someone could hijack the service to point IPv6 addresses to somewhere unexpected.
If it's only used in development, it's not too big a deal, but could still be use to compromise things.
In case anyone wants to know the difference it's that the third "section" on the first URL is "9adc" and the third "section" on the second URL is "9abc".
Same/similar working mechanism is built-in into Windows since Vista:
1234-5678--abcd.ipv6-literal.net
This doesn't even need functioning DNS and can work offline (add s<devnumber> for link-local addresses).
The fundamental problem with this whole scheme is that it is still just trying to memorize the entire IP address. The point of a name is to make it something that feels natural for actual people.
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:
This scheme isn't designed to make the addresses memorable though. It's designed as a workaround for cases where hostnames are supported but v6 literals aren't, for example in UNC paths to Windows network shares.
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.
Kinda like https://what3words.com/. Question is, how long would the string of words have to be to enable such a scheme for the entire IPv6 address space?
8 words. 128 bit address space and 65k English words gives you 16 bits per word, so you need 8 words to cover the entire space.
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.
Once you really get into IPv6 you tend to find that the addresses are not actually that bad or at least not as bad as you might expect. For starters, your prefix stays the same and probably looks like this 2001:wwww:xxxx::/48 ISP is wwww and your allocation is xxxx. There are lots of ways you can break up your allocation: yyzz. For me yy is the first dot1Q and zz is the second tag. yy = 00 is for single tagged 802.1Q VLANs. I have quite a lot of "spare" space for expansion, VPNs or whatever. So using the https://tools.ietf.org/html/rfc3849 documentation prefix 2001:DB8::/32 - that's my "ISP". Let's say I am :2d1:, I give my routers ::1 ie the first address and therefore on my default VLAN with no tags, I get an address of:
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.
/48 for work (actually I have six of the bloody things!) and /56 for home which is reasonable. /64 is ridiculous unless they will give you more on request but then why not /56 so you can plan. We really are not going to run out of those and even /48 for all is pretty reasonable. At work I have an additional /64 just for WAN but I understand /112 and the like are popular for that as well.
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.
When you see an IPv6 address mentally block out the last 64 bits. A /64 in IPv6 land is the equivelent of a single public IPv4 address for most practical purposes.
Back in the 80s or possibly 90s that might have worked, but an experienced admin today will look at a /24 and go "I can support 16 sites with that", whereas a /64 is really the smallest allocation you should see with IPv6, like a single IP address in IPv4.
My old ISP gave me only a /64. That's absolutely useless for doing anything more than there most basic of configuration. This seemed to be because of limitations in their own infrastructure as they were using 6rd. I ended up switching ISP's to one that gave me a /48.
I seem to recall general recommendations that ISP's assign at least /56 to customers?
One of the biggest things that keeps me using IPv4 is that I can memorize all the IPv4 addresses for most of my servers. That alone is a huge mental hurdle.
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).
I thought this would be an issue when I deployed IPv6 on my home network, but it turns out that I memorized the prefix pretty quick and the host part you mostly end up ignoring.
It would be interesting if there was even an informal URL extension that was able to specify alternative name resolution protocols. Maybe overload scheme in the url otherns-https://name
Usually when you use a service to manage domain names for you, you have a contract with the managing party, which puts your relationship on much firmer legal grounds than when you use a random service provided for free and without legal guarantees.
the xip.io is primarily used by private addresses (I hope no one uses it for public ones) there are no real private ipv6 addresses so by using the original service it's risky.
I was sure there is a similar concept in IP6 to the IP4 private ranges. And indeed: Unique local address[0] serves the same purpose.
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.
Not sure what you mean by "point a routable address to it"... you don't point an address at a domain, you point a domain at an address. And you can point your domain at any address, whether you own it or not.
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.
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.
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.
Letsencrypt won't issue certificates to IP addresses - but will to domain names (including those assigned by dynamic DNS providers, but most dynamic DNS providers need manual sign-up with username and password)
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...
I feel like I'm missing something. How is this different than AWS providing a wildcard certificate for every S3 bucket via https://<bucket>.s3.amazonaws.com. Is it the same thing?
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.
Because that DNS entry resolves to an Amazon owned servers which have the certificate and key. This service resolves the DNS entries to your own server, meaning requests would hit your server which would require your server respond with the signed certificate and have control of the accompanying private key.
In theory you can get a certificate for anything that vaguely resembles X.500 directory object. Whether some CA will sign such certificate and whether it is accepted by clients is different issue.
With this you can refer to a machine in the IP6 space without setting up any DNS yourself. In some situations a hostname works where an IP-Address doesn't. They gave one such example: Getting SSL certs.
Clearly it's not a good idea to rely on this for anything serious so the value is mainly convenience during prototyping.
Nice! I had been thinking for a while on building something like this but that provided reverse PTR records, too.
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).
you're trusting the operator to return the right ip address, and not returning something nefarious. it's definitely not as secure as using the raw address, for example.
Nice! I run a similar service at https://ip6.name/. The service also supports empty groups, e.g. 2001.db8.8000.x.1.ip6.name resolves to 2001:db8:8000::1, as well as 2001.db8.8000.0.0.0.0.1.ip6.name.
A neat one is x.ip6.name, which resolves to ::, e.g. localhost...
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.
There is no business model behind has-a.name. It's main motivation came from our customers, who are using the IPv6VPN quite intensive.
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.
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).
Mobile networks typically use 464XLAT. Deployment is not hard. The main hold up for resi networks is CPE vendors don't typically support CLAT, but most established players can do dual stack for now.
Curious why the rfc didn't choose base64 as the representation format. It won't change what it looks like on the wire but will result in shorter addresses that can in part have some meaning. Matter of fact has there even been such a proposal.
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.
> 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!
My ISP doesn't seem to support ipv6
If I check on https://test-ipv6.com/ I geta bunch of blue dot warnings.
Like:
"You appear to be able to browse the IPv4 Internet only. You will not be able to reach IPv6-only sites."
Is this common or is my ISP behind the times and could this become a problem?
I have done some development with CoAP and ipv6 so it has been an issue for me.
On the name issue I think its a great idea, even if its a name that resolves to native ipv6 addresses it would be very useful to me
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).
120 comments
[ 5.1 ms ] story [ 197 ms ] threadAll 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.
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
http://xip.io/
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
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.
[0] https://en.wikipedia.org/wiki/Unique_local_address
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.
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.
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.
Clearly it's not a good idea to rely on this for anything serious so the value is mainly convenience during prototyping.
[0] https://en.wikipedia.org/wiki/PGP_word_list
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).
Also, it's dangerous.
A neat one is x.ip6.name, which resolves to ::, e.g. localhost...
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 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.
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.
> 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!