Hacker News new | past | comments | ask | show | jobs | submit login
Giving every IPv6 address a name (has-a.name)
209 points by Sami_Lehtinen 40 days ago | hide | past | web | favorite | 119 comments



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.


Also don't use for anything real, because you should not be teaching users that https://1234-5678-9adc-def0-1234-5678-9abc-def0.has-a.name is the proper, trusted domain for your service. Because it was supposed to be https://1234-5678-9abc-def0-1234-5678-9abc-def0.has-a.name and I just tricked you.


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:

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


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.


Were you given a /48 for your residential IP, or is that for a business? Residential AT&T in Georgia assigned a /64 for me.


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?


/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.

You have my sympathies.


/64 is a lot of addresses. That's 2^32 internets.


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.


I would prefer to "A /64 in IPv6 land is the equivalent of a single public IPv4/24 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.


But it’s only a single subnet or point-to-point link, you can’t do anything interesting with that space


Typically it's pretty easy to get an ISP to cough up a /48 if you ask.


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.


I don't think they're proposing this for anything other than a prototyping solution along the lines of this:

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.


I'm guessing you are referring to the "config needs a hostname" problem. Been there myself.


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?


Dictionary size of what3words: (57*10^12)^(1/3) ~= 38485 [0]

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%...


I call dibs on Buffalo.buffalo.Buffalo.buffalo.buffalo.buffalo.Buffalo.buffalo


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.


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.


$ host sprint.net

sprint.net has address 208.24.22.50

sprint.net has IPv6 address 2600::

wonder which one is easiest to remember? =)



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).


I actually had to look three times before I spotted it. Good one!


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".


I had to diff it! Even if there was no difference, the time it would've taken to be sure really illustrates the problem.


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


Neither of those loaded. Not tricked.

/s


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.


Not without the ability to add a TXT record to the root domain.


Which root domain? If they own has-a.name then that is good enough, right?


No, they'd have to get a cert for your domain name. Which they can't, because they cannot prove they own your domain name.

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.


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.


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.


> 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.


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.


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


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.

You're generally right though.


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 have a very good point.


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.


And then they have a certificate. What are they going to do with it? It's still not installed on your server.


Suddenly whatever.has-a.name is pointing to a different IP address and that server has the cert installed. Oops.


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.


Can all the nice people who have downvoted explain what I said wrong?


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.


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.


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.


Maybe that's restriction for LetsEncrypt (I haven't used it myself) but certificates aren't restricted to 2nd level.


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.


You can get a certificate for an IP address, but LetsEncrypt doesn't support it. So this might be somewhat specific for LetsEncrypt.


The same amount of trust you put into any service managing domain names for you?


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.


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...


Why you need this? You can get SSL certificates IP addresses Anything that is 'common name'.

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?


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...


Couldn't they just get a wildcard cert for "*.has-a.name"?


And give it to everyone?


not sure what you mean by give it to everyone. who are they giving it to?


Anyone who then wants their site accessible through this. It’s not a proxy, they’re just returning your IPv6 address based on what subdomain you type.

In order for a wildcard to work, every single user of the service needs the private key for that wildcard certificate.


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... if they did, then any other customer of AWS could impersonate me.


>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.


Are there others who issue?


You need to wrap IPv6 addresses in brackets, else it gets confused with the :port# syntax. http://[::1]/ or http://[::1]:123/ for instance.


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.


Shouldn't this been appropriately named has-aaaa.name?


Oh, I was hoping this was going to be like the What 3 Words of IP addresses. Like "fourteen-mangled-yellow-squirrels.has-a.name".


Oh boy, this is dangerous. A lot of things are tied to DNS name, so you're giving a lot of power if you point a routable address to it.


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.


It was brain shortcut, I meant point your reverse DNS of a routable IP to that name.


How is that dangerous? If you don't "own" the IP, you can't add PTR for it.


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.


But if they point to a new IP, the other IP's PTR is useless.


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.


But you don't need PTR in any of these steps.


It would be interesting to combine this with something like the PGP word list [0] to get human readable names for an IP address.

[0] https://en.wikipedia.org/wiki/PGP_word_list


Omg. That is super cool. I want to turn this as a phone interview question. Sounds like fun.


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).


TLS concerns aside, there appears to be no business model here, so it's not clear how this would become reliable


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.


And from a position of active defense, it’s not clear how this free product monetizes our usage. I’m skeptical.


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.



No, ip6.arpa is for reverse DNS; this is forward DNS.


If you are able to have the reverse zone for your subnet delegated to nameservers under your control, you can use it as a "forward" zone too.

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.


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).


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.


Or base58


What would the value of this be? Why does it even matter? I am struggling to decide if this is even valuable.


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.


This is nice:

> 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!


Meanwhile, we're still waiting for VZ to put Fios on IPv6...


Note that xip.io does this for IPv4


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.

[0] https://en.wikipedia.org/wiki/Unique_local_address


What is a IPv6 application?


This sounds like a solution looking for a problem.

Also, it's dangerous.


Can you elaborate on #2?


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.


This is all well and good and all.

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.


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.

IPv6 is at about 30% of traffic now.


Yep, any day now.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: