Hacker News new | past | comments | ask | show | jobs | submit login
The Ripe NCC Has Run Out of IPv4 Addresses (ripe.net)
416 points by cnorthwood 60 days ago | hide | past | web | favorite | 419 comments



I’m in the ARIN region. Two things:

1. My home has Verizon fiber. No native IPv6. I have a tunnel for this, but such solutions aren’t going to work for the masses. The other in-region residential provider, Comcast, has great native IPv6 service, but had layer 2 performance issues versus price.

2. At $dayjob I just ordered a circuit from Level3/Centurylink for a branch site. No IP justification form was required if I needed only IPv4 /30. But for dual IPv4 /30 + IPv6 /126, I was required to provide written justification. Shouldn’t this be the other way around? Unencumbered IPv6 for all, with paperwork for IPv4?

EDIT: these are not site allocations, just point-to-point link addresses, hence the /126. Still, I’m being asked to justify IPv6 but not IPv4.


> IPv6 /126

Uh, unless you're running BGP over this or getting a larger subnet statically routed to you, get a larger prefix. A /48 or /56 is the current recommendation [1] for business end site allocations.

[1] - https://tools.ietf.org/html/rfc6177


Of course, this is just a “point-to-point Ethernet” not an allocation.

That said, I think the original intent was that such “point-to-point Ethernets” should have been issued /64, but seems /126 is common practice.


Actually many ISPs do not even give out a fully routable /126, but simply use an LL fe80:: address for the CPE:

* https://www.ripe.net/publications/docs/ripe-690#4-1-2--unnum...


Comcast gives out /64s at least. I got my router to successfully ask for 2 on different interfaces.


Same story on Spectrum. On their residential plans they will give out a /64 by default. However w/ DHCPv6-PD I was able to successfully request a /56. What I found mildly interesting was they wouldn't allocate a /60. (My guess was: whatever silicon they've got pushing IPv6 packets around probably likes segmenting the routing table on a clean byte boundary.)


Providers don't give out publicly routable /126. Generally most providers aren't going to give out anything longer than a /64 partially because they don't need to and partially because routing tables [0]. They want to route to you via a prefix that's pre-allocated to carve up for the region you're in.

[0] https://www.ripe.net/publications/docs/ripe-690


A /48 is the minimum folks will pass via bgp on the internets (it's the /24 of the ipv6 world).

Also another fyi: if you're rolling commodity hw (bcm tridents etc) after a /64 up to /128 you are dipping into another constrained forwarding table - can't fill your box with too many of those.


> A /48 or /56 is the current recommendation [1] for business end site allocations.

I can get a /56 even at my apartment just by setting my router to request it.


Many VPS providers (for ex. OVH) also do the same thing and provide a single IPv6 address.


Here's another fun one: how many usable IPs do you get out of the 4 consumed by that /30? Not sure about L3 specifically but it seems a lot of ISPs haven't yet figured out that it's not necessary to waste half the IPs in every /30 allocation with gateway and broadcast IP.


Spectrum/Charter and Verizon have finally started allocating a single IP out of a /24 instead of giving me a whole /30 when all I need is one routable address. Too little too late though.


I think you're missing the parent's point, that you can use a /31 without separate network (not gateway) and broadcast addresses.

Putting multiple customers on the same /24 introduces all kinds of issues. Either you leave it open leaving IP's vulnerable to hijacking, or you have to create static ARP and/or MAC entries, and deal with all the hassle of managing that. Presumably, you're describing consumer service where they don't really have to care about your security unlike a business/enterprise level service.


Unfortunately we're just not at a stage yet where anyone can easily associate a static IPv6 to an EC2 instance and expect it to "just work". My phone isn't always happy visiting IPv6 addresses. Many coffee shops and university wifi I regularly use don't support IPv6. My home router doesn't seem to route IPv6 correctly (or maybe it's Comcast's problem; I don't know; I gave up because everything I use can work over IPv4 as well :-/). My work internet connection doesn't route IPv6, either.

I'm all for IPv6 but it's not widespread enough to ditch the need for static IPv4 addresses.


Transitioning to native IPv6 requires running dual stack for quite some time, we'll never get there if we don't start


Not necessarily. A network can go entirely IPv6 internally and just have adaptors at the edge to translate parts of the Internet that aren't IPv6 yet.

Doing this means all IPv4 network addressing headaches vanish internally. Oh there are going to be 260 remote offices instead of 100 like you said at the kick off meeting? No problem, my subnets are easily big enough either way.

And with this approach your budget for the edge reduces over time as more of the network supports IPv6, whereas with a NAT gateway your budget increases as throughput rises.

You do need to be really firm during purchases, if the "IPv6 support" in that shiny new product is actually more of a wishlist item than an actual feature, you're getting a full refund, no second chances. That goes for desk phone (if your outfit still has those), printer/ copiers, IoT devices, and everything.


I’ve heard some variant of that for over two decades and still here we are.


In the early 2000s the issue was the routing hardware did ipv6 shitty. That took a few years to get to a better spot (and a few years more to get it almost at IPv4 parity feature wise). Then it took a few more years for transit providers to roll it out...then the broadband networks. Now we're in a time when v6 support is mixed across cloud companies and there are large swaths of geographical areas that are lagging (sup Central and South America + china). Were closer...


A /126, seriously? Comcast Business gave us a /56, unprompted, as part of our account setup.


This sounds like a simple P2P link to do BGP over. I highly doubt CL is using /126’s as standard allocation sizes.


That makes a lot more sense! Good call.


My home connection has a /56 (o2/telephonica de) ....


Yeah, I too got a /56, same country, different ISP. It just showed up one day, which confused me at first.


> It just showed up one day, which confused me at first.

I've heard this pretty often. One day it gets rolled out without any notice, and surprise, you're on V6. Plays havoc.


Maybe their thinking is that if you are just requesting IPv4 you probably aren't set up to support IPv6, but if you ask for IPv4 + IPv6 then they want to know why you can't just use IPv6 for everything and so ask for justification for using IPv4?


Can you really use ipv6 for everything? I thought only ipv4 could do that?


If you are a user sure. There are ways to bridge IPv6 to IPv4 (A router someplace translates for you, I suppose NAT but I'm not an expert on how this works), while going the reverse is harder because there is no way to bridge IPv4 to IPv6. There are a lot of people running IPv6 only who don't even know it. (most cell phones for example)

Only server administrators need to care, and there they have a problem. If you run real IPv4 only: then IPv6 only users can talk to your server no problem and won't even realize anything is happening. If you run IPv6 only there are a lot of IPv4 only users who cannot connect to you. Thus if you run a server it is critical to have a real IPv4 address.

Did you notice the "real" qualifier to IPv4 in that last paragraph? many (most?) IPv4 only users are behind a NAT system such that they cannot run a server anyway. If you are running a IPv4 Server you need an address of the type that RIPE just ran out of. If you are a user you can use a fake IPv4 address and keep on working.

If you are a server administrator you should ensure that all your servers have IPv6 addresses. You should then collect statistics on use. There may be a date in the future where you can suggest to your management that you can cut off [small number]% of your users by going IPv6 only and selling your existing IPv4 address to the highest bidder for $$$. That is a business decision, but once it starts happening it will make headlines, but I wouldn't want to be first. (if you wait too long enough others will have gone IPv6 only that there isn't a real customer cost to being IPv6 only and then the market for IPv4 will disappear - and interesting value maximization problem if you want to play that game)


NAT is an acronym for "Network Address Translation" so that's the right term to use.

NAT approaches to bridge IPv6 and IPv4 exist and work as well as IPv4-to-IPv4 NATs, that is to say pretty poorly: but we've long since adjusted the architecture of Internet-enabled software to cope with the flaws, so practically speaking they work just fine.

We've been down a road for a while now of funnelling all of the Internet's services into something-over-HTTP, so running a server might need a public IPv4 address, but as the supplies already assigned to LIRs by the RIPE NCC (and other RIRs) start to dwindle I expect we'll see more services offered whereby you can share an HTTP front end with a bunch of other people, proxied to an IPv6 (or private space) server you run.


I don't think that the use of NAT at that level is really feasible to bridge IPv4 networks to IPv6 ones. While you can easily map the entire IPv4 address space into an IPv6 subnet of your choosing this is obviously not possible the other way around. Address mapping would have to be highly dynamic to work at all and there would be no real guarantee addresses stay the same that way. Additionally in order to make this work more or less transparently DNS responses have to be modified breaking in presence of DNSSEC validation (the same as DNS64 in reverse). One could probably avoid this by using something like reverse DS-Lite which is more or less NAT with tunneling combined.

A more common approach to reach IPv6 networks from IPv4 ones is tunneling the traffic on top of your existing IPv4 network. This way you become fully addressable and able to reach both networks almost like you would have been able to with a dual stack setup except that the tunnel reduces your MTU because of the tunneling and that you need an remote endpoint with support for both networks that routes packets to your tunnel accordingly.

Using IPv6 only makes it impossible to reach you from an IPv4 only node while still making it easy to reach other IPv4 host from your side using only NAT techniques. Using IPv4 only its unfeasible to reach arbitrary IPv6 hosts using NAT only and a tunnel setup is more or less required to make it work properly.


> I don't think that the use of NAT at that level is really feasible to bridge IPv4 networks to IPv6 ones.

Not only has CGNAT existed doing this at scale for many years in SE Asia, it commonly happens on cell networks in the US now even, so yes, it’s feasible.


that would be quite uncommon. what happens often though is the reverse. maybe you misread my point?


One more reason to reconsider the design of DNSSEC and take it back to the drawing board, since it has virtually no meaningful deployment today anyways, and is already badly flawed.


There's nothing wrong with the design of DNSSEC. It's just doing its job, making sure that the addresses in the DNS replies match the RRs configured by the domain owner and preventing MitM attacks against the DNS system. The issue is DNS64, which for all intents and purposes is a form of MitM attack: If you can run a transparent DNS64 service you can redirect traffic however you want. You're not limited to faking "equivalent" AAAA records which send traffic to the correct IPv4 server. This is incompatible not only with DNSSEC in particular but with any attempt to ensure the end-to-end integrity of domain resolution. Anyway, we already have a solution to the problem of IPv6-only networks connecting to IPv4 servers which doesn't depend on manipulating DNS entries: DS-Lite.


The job it does has very little operational value, and it breaks things we care about. In just a few months of deployment, DoH has done more to protect DNS queries than DNSSEC has in almost 25 years of work. Any time you look at something that DNSSEC makes harder, your first thought should be, "is the real problem here that we're trying to do tree-PKI DNSSEC in the first place"? I'd content that's always the case.


DoH and DNSSEC are orthogonal systems. DoH protects the connection from the client to the resolver from eavesdropping or tampering, but doesn't do anything to ensure the integrity of the records reported to the resolver (which still uses regular DNS) and doesn't prevent the resolver itself from tampering with the data. The aim of DNSSEC is to provide for the end-to-end integrity of the RRs so that a client can be sure that the reported data matches the data entered by owner of the domain. This is essential for protocols such as DANE. The introduction of DoH does not eliminate the need for DNSSEC and the two protocols can be used together.


At this point, I'd say DANE is more essential for DNSSEC than DNSSEC is essential for DANE. But both are solutions casting about desperately for a problem to solve; in DNSSEC's case, for more than 20 years, through repeated false starts in design.

The comparison with DoH is imperfect, certainly, but still probative. DoH does something, today; it protects queries to sites all around the Internet, and doesn't depend on a boil-the-ocean deployment that must occur simultaneously in two directions (from the service operators who must sign their zones and from the end systems which must upgrade and enable DNSSEC). DoH is a relatively young protocol and will, within the next year or two, be almost completely mainstream, a feature of most of the deployed base of browsers. DNSSEC will still be languishing, because we aren't humane enough to drag it out to the yard, rifle in hand, to put it out of its misery.


Which would be about the most braindead reasoning ever?!


There are five regional internet registries (RIRs), and Ripe NCC is one of them. Here's a map of which services what region[0]

Does this mean we've finally run out of new allocatable IPv4 addresses with the RIRs?

[0]: https://en.wikipedia.org/wiki/Regional_Internet_registry#/me...


ARIN (North America) and APNIC (Asia-Pacific) ran out of addresses some time ago (2015 I guess).

Game over IPv4.


All it means is the free lunch is over and people have to start buying their IPs off of an informal market.

Theoretically we could have transitioned to IPv6 instead and avoided this hassle, but too many incumbents are dragging their feet on the whole IPv6 issue.


They don't need an "informal market" when there's a perfectly good formal market. You can sell some of your IPv4 allocation to another LIR party which needs the addresses, the only case that you can't do through the formal mechanism is speculation. You can't buy a /16 and then sit on it hoping to sell it later when the prices are highest before a collapse. Good.

One thing you don't see enough of yet is providers charging for the IPv4 address their customers probably don't need. Those have a real cost, and economics 101 tells us if something has a cost, even a small cost, and you surface that cost to your customers, suddenly they're a lot more interested in helping avoid that cost than they were when you just ate it as part of the service. Plastic carrier bags weren't free back when grocery stories didn't charge for them -- they just absorbed the financial cost and externalised the environmental cost. Charge for the bags and suddenly customers remember they already have a bag, they don't need a bag. Same with IPv4.


AWS does charge for unused IPv4 addresses, but used addresses (i.e. attached to a running VM) are "free" (price included in service).

Do other cloud providers (Azure, Google Cloud, Digital Ocean) do this?


Yeah, I've seen this at Digital Ocean, if you have a floating ip (can go to anything in the datacenter) and it's not attached, it has a price.


Yep same on Azure


Why, do you think? We're talking about computer people, not exactly Luddites. We all upgrade to new tech all the time, but IPv6 is more than 20 years old and adoption is still shit.


IPv6 is a mess, over-engineered, non-intuitive, magic addresses etc.

All they needed to do was expand the address space, but it looks like the kitchen sink got thrown in.


It's not more of a mess than IPv4. It's okay, people can learn it as they learned the weirdness of IPv4 (DHCP, ARP, NAT, RFC1918, IP fragmentation, ...).


But it's a different, backwards incompatible mess.


Will any device made of matter / operating in polynomial time ever be able to hold the full 2^128 address space? It seems like we will forever be sub-netting into huge blocks simply because the entire space if mathematically infeasible to operate on. I think its fair to ask: Whats the point?


You are completely misunderstanding the purpose of IP address space. The purpose of IP address space is not to all be used, the point of address space is to enable connectivity. You enable connectivity by (a) having addresses available whereever you need them while (b) allowing for efficient delivery of messages. Both of those you achieve with sparse allocations, where it is easy to add machines and networks with minimal changes to the overall structure and minimal administrative overhead.

Designing the IPv6 address space to be filled with devices is about as sensible as designing the DNS system to be filled with domains. Like, instead of allowing for domain names with 63 characters per label, we could have just said DNS names are alphanumeric strings 7 characters long, and you get assigned a random one if you register a domain, to maximize the utilization of the address space. But that would be simply idiotic, because the purpose of that address space is to provide readable names, not to "use all the addresses".


For IPv6, the Internet routing table will never be split into more than 2^64 blocks, as a /64 is the general minimum BGP-announcable IPv6 block.

Regardless, I don't get your argument. Why would not being able to address all of a given address space be a bad thing? Isn't the whole point to have more address space than will ever by physically possible to need?


>Isn't the whole point to have more address space than will ever by physically possible to need?

Is that not the definition of over-engineering?


It is over-engineering the same way that setting the maximum length of a database field longer than absolutely necessary is over-engineering, so not at all, except even far less so, because resizing a database field tends to be trivial, resizing the IP address size we've been working on for 20 years already and there is still no end in sight.

Really, this has absolutely nothing to do with "over-engineering", as there is absolutely no "engineering" in making the address larger, it adds zero complexity, and it massively simplifies network design because it removes constraints that really complicate the building and maintenance of networks.


Nah, in this case I agree. We thought the IPv4 space was more than we were ever going to need, and see where that left us...

Now we just took what we thought we needed, and added a few tens of orders of magnitude.


Let me give you an example to illustrate the scale.

An average human cell is composed of 100 trillion atoms. [0]

An average human body is composed of 100 trillion cells.

By that we see there are about 10^28 atoms in a human body.

Let’s be conservative, and say the world population for the next fifty years stays under 10 billion (most estimates say closer to 100 years).

That gives us about 10^38 atoms across all human beings on earth.

Why does this matter? Because 2^128 is 3.4 × 10^38.

That’s three IPv6 addresses for each and every atom in all the humans on earth for at least the next 50 years.

If that’s not the definition of overkill, I dunno what is.

[0] https://www.thoughtco.com/how-many-atoms-in-human-cell-60388...

Edit: And if you say the real routable space of IPv6 is only 2^64, then my point still stands. Rather than it being 3 IPs for every atom, it’s still an IP for essentially every cell of every human on earth for the foreseeable future.


Do you also have a problem with 64-bit systems that have provisions for 64 bits of address space? In your book they also seem like a waste, and we should have designed something closer to ~48 bits of address space.


No, I wouldn’t make the same comment if it was just a 64bit address space. Some excess isn’t necessarily bad, but excess on top of excess is. If that makes sense.

My edit I made last night might seem to imply otherwise, but that was due to me being a bit terse with that part and I can’t go back and edit further now.


A 64 bit address space wouldn't be an excess though, it would be outright too small.

The whole point of L3 is to provide a layer of routing and aggregation on top of L2. Routing and aggregation requires sparse allocations, so L3 requires more address space than L2 does. L2 is 64 bits for new protocols today (which are supposed to be using EUI-64), so L3 needs to be more than 64 bits.

People would complain loudly if we didn't use a power of two, so here we are at 128 bits.


> If that’s not the definition of overkill, I dunno what is.

Or perhaps you are short sighted. :)

Look at all the drama and effort that we have had to go through over a decade or two to get past IPv4: if we went with "only" 64 bits for addresses, and we miscalculated and ran out again, we would have to go through that all over again.

It's the same reason why the ZFS folks (Jeff Bonwick) designed in 128 bit from the start:

* https://blogs.oracle.com/bonwick/128-bit-storage:-are-you-hi...


> A fully-populated 128-bit storage pool would contain 2^128 blocks = 2^137 bytes = 2^140 bits; therefore the minimum mass required to hold the bits would be (2^140 bits) / (10^31 bits/kg) = 136 billion kg.

> Thus, fully populating a 128-bit storage pool would, literally, require more energy than boiling the oceans.

Very definition of excess as well, so thanks for proving my point!


> Very definition of excess as well, so thanks for proving my point!

Except you're skipping over the part about running out at 2^64:

> Some customers already have datasets on the order of a petabyte, or 250 bytes. Thus the 64-bit capacity limit of 264 bytes is only 14 doublings away. Moore's Law for storage predicts that capacity will continue to double every 9-12 months, which means we'll start to hit the 64-bit limit in about a decade.

2^64 bits ought to be enough for anybody. -- jsjohnst


Never once did I say 2^64 ought to be enough for anybody, so how about stop being a jerk?

Try reading what you quoted again, nobody is running out yet.

There are a lot of intermediate steps between 2^64 and 2^128! ;)


And then we expand to the stars, and suddenly one planet full of people isn't that great. And we'll develop nanomachines that need to be individually addressed, and suddenly our nice and new IPv6 space only lasts us only a hundred years.

These are just silly examples, but the point is that we don't yet know what will happen to make us run out of space.


> only lasts us only a hundred years

Even if that’s true, that’s about 3x longer than IPv4.

A hundred years ago, computers didn’t exist. Can you imagine how well a network address scheme invented back then would work for our needs?

Why do you presume we can do a better job of predicting what the networking needs of a hundred years from now will be?


then why stop at 2^128...why didn't they use 2^256?


Not if this extra bit space is cheap (and it is, both on the wire and in routing tables / TCAMs / tries).


No, it's a /48.

Login to a route server and see for yourself.


You're right!

That makes it even less possible routes then, 248.


A subnet (i.e. a layer 2 network) always gets a /64 in IPv6; so the actual address space available for layer 3 routing is 64 bits.

The point of this ridiculously large space is that it makes routing tables smaller, because topologically-near areas can be given common prefixes without worrying about address exhaustion.


also in IPv6 there are regional allocations so you can have a route that covers for Europe and another for APAC


What were the changes in IPv6, beyond just expanding the address space?


IP Fragmentation at routers was removed from the protocol for one.

Another is that it changes the way you think about IP addresses, with endpoints getting a /64 instead of a single address like you did in IPv4. This allows users to change their IP address for every connection if they want, so if you want to apply policy to them you need to apply it to the entire subnet they are on. Granted, this also happens in IPv4 if you are doing NAT, so it's not really a change for most people.

There are a few other changes to stuff like QoS to better reflect modern practice, but for the most part it's pretty similar. Also, the IP header lost its checksum, as it was basically never useful.


> Another is that it changes the way you think about IP addresses, with endpoints getting a /64 instead of a single address like you did in IPv4.

End points get /128, it's just that subnets are now /64.

That simply means that endpoints can auto-assign themselves a new /128 because--instead ofhaving only space for 2^8 hosts in the typical /24 subnet of IPv4--there is now space for 2^64 hosts, which makes it unlikely that collisions will occur.


> Another is that it changes the way you think about IP addresses,

Only if you don't have a clue of IPv4 either.

> with endpoints getting a /64 instead of a single address like you did in IPv4.

That's just wrong. And endpoint gets one address, just as with IPv4 (and can optionally assign additional addresses where address space is available, also just as with IPv4).

What gets a /64 by default is a link, like, an ethernet. Which is also exactly like in IPv4, except, of course, with IPv4 you had shorter/fewer addresses, and thus obviously also smaller prefixes/fewer addresses per link.

> This allows users to change their IP address for every connection if they want, so if you want to apply policy to them you need to apply it to the entire subnet they are on.

Which is also exactly the same as with IPv4. If your LAN has an IPv4 /24, you can also change you address for every connection.

> Granted, this also happens in IPv4 if you are doing NAT, so it's not really a change for most people.

You have it all backwards?! NAT is what makes this impossible for connections to the public internet, in that no matter how you change your RFC1918 address, you keep the same address to the outside world? But that obviously is not a property of IPv4, but of NAT.


I wasn't quite precise, because there are cases where you do DHCPv6, but as Android doesn't support it the protocol is a bit dead in the water.

SLAAC the router gives you the 64 bit prefix and the host chooses its own 64 bit host address, which can be any address not already in use. With IPv4 you are typically assigned a single IP address via DHCP. While it is true that you are free to ignore the DHCP address assigned to your host and select something else on the same subnet, this is not typical. With SLAAC however it is the norm for the host to figure out its own address, and to leverage the enormous IP space available in IPv6 to change up their source address at will.

Filtering individual hosts by IP has always been leaky, but IPv6 makes it more or less impossible. You have to filter by subnet.

IPv6 does have some braindamage. SLAAC didn't have a way to communicate the local DNS server address to hosts, nor a way for hosts to update the DNS with their selected addresses and hostnames. This is something that has just worked in DHCP for decades and was completely ignored by the IETF. There was some handwaving about mDNS and anycasting but the actual protocol for doing the updates was never nailed down and it ignored the fact that multicast on wireless networks has always been fragile and plagued by hardware/driver issues.


> I wasn't quite precise, because there are cases where you do DHCPv6, but as Android doesn't support it the protocol is a bit dead in the water.

Arguably, it's alive and well for the use case where it actually makes sense: For prefix delegation.

> With IPv4 you are typically assigned a single IP address via DHCP.

Well, sure, and with IPv6 you are "typically assigned a single IPv6 address via SLAAC"!?

I mean, if you are talking about a controlled environment, that's not exactly difficult to achieve, by either using MAC-address based v6 addresses, or by configuring a fixed host suffix on the respective machine, just as you would configure DHCP. If you are talking about random people/devices on your network, neither case prevents them from assigning themselves whatever addresses they please.

> Filtering individual hosts by IP has always been leaky, but IPv6 makes it more or less impossible. You have to filter by subnet.

But that is what you are doing with IPv4 as well? Just because you can't see the individual addresses of individual machines, and thus have no other choice but to block the whole subnet (that is, the NAT gateway address that proxies for it), doesn't mean you aren't blocking whole subnets!?

> SLAAC didn't have a way to communicate the local DNS server address to hosts

Well, yeah, but that's been resolved, as you seem to know.

> nor a way for hosts to update the DNS with their selected addresses and hostnames.

Except it does? If you ask me, it does not make any sense for the DHCP server to update the DNS server anyway: It's the host that owns the host name and that knows where it is reachable, and also a host in principle could be getting its connectivity from anywhere, not just a particular fixed DHCP server. The host should have the credentials for updating its DNS name, should select the address to publish for inbound connections based on its local policy, and then publish that address to the DNS. It makes no sense to tightly couple naming services and connectivity: When my laptop switches from ethernet to LTE, it should just update its DNS name to point to the address it obtained from the LTE provider, and obviously that should not involve the DHCP server of the LTE provider.


> Well, sure, and with IPv6 you are "typically assigned a single IPv6 address via SLAAC"!?

Unlike DHCP, SLAAC doesn't assign specific addresses to hosts. It communicates the network prefix via periodic broadcasts, and hosts choose their own addresses within that prefix.


No, SLAAC is the name of the configuration mechanism, the network protocol that is used for SLAAC is NDP, specifically router advertisements (RA), and SLAAC assigns a specific address to a host, based on the information in the RA and local policy on the host that specifies how specifically to generate the host part of that specific address.


SLAAC is autonomous. It's more accurate to say that it tells a host to assign itself an address, rather than that it assigns an address to the host.


No, SLAAC is the name of the configuration mechanism, the network protocol that is used for SLAAC is NDP, specifically router advertisements (RA), and SLAAC assigns a specific address to a host, based on the information in the RA and local policy on the host that specifies how specifically to generate the host part of that specific address.


...you seem to have just copied and pasted the post I replied to.


> IP Fragmentation at routers was removed from the protocol for one.

Everyone that I talked to about this seemed to like the change.


If someone is smart enough to hop IP addresses to avoid your firewall, surely they can come up with ways to tunnel a VPN out of your network (eg through DNS or over port 443...)


Changes to the way that DHCP works. There are now different methods if you're handing out subnets to a router, IPs to an end device or allowing devices to (automatically) self assign. And not all devices support all methods.


Every device that I saw as of 4 years ago (when I was working on edge IPv6 implementation) supported the NDP/SLAAC method of assigning IP addresses, which is the default for most leaf node use cases. It's optimized for a unidirectional transmission of information from routers to leaf nodes.

DHCPv6 is used for routers, which need to be given not just an individual address on the local interface but also a prefix that they can hand out to their clients. It's optimized for flows that require a confirmation from the client that it has accepted/reserved the configuration that it's been given.

It is technically possible to use DHCPv6 to hand out IPs to endpoints, but I have not seen any production network in the wild that does this.


Aside from what everyone else is saying about the semantics, there were also a lot of changes in the header format to make it easier to parse in hardware by ASICs. Fixed-length basic header, a single integer flag that indicates to routers when they need to parse variable-length options, a requirement that in the unlikely event they are used that those options need to be 64-bit-aligned, etc.

As long as they were breaking compatibility, all kinds of details were changed to make things easier on implementers.


Router advertisement via ICMP is one I can name off the top of my head.


There is no router advertisement/NDP/SLAAC in IPv4, so that's not a fair comparison. NDP/SLAAC has a vastly different architecture and behavior than DHCP(v4), and also deprecates other hacked-on IPv4 features (like DHCPv4 link local addresses and ARP).


ndp in ipv4 is called "arp" =D


I would have understood this, as well as making it clear just how ginormous the IPv6 space is.

65536.65536.65536.65536.65536.65536.65536.65536


1.8442.16384.20.9000.42.1337.999 looks half like somebody dropped a phone number into a mass-doubling machine, and half like an overgrown object identifier.


I'm seeing IPv6 popping up more and more lately, so I don't think it will be much longer.


Can I ask how old you are or how long you’ve been in the industry? I have been hearing about the impending coming up IPv6 since I was in school 15 years ago.


Things have changed a lot in 15 years. When you sign up with a major cable company like Spectrum and open up your browser and visit Google or Facebook, IPv6 is being used.

I feel like the adoption problem is now firmly on "us". Last time I was setting up an internal network, I was afraid of the consequences of using IPv6 internally, so I just didn't. I imagine a lot of people are in the same boat, and they are the stragglers preventing us from turning off IPv4. The big players are ready.

(I will say that jrock.us has worked over IPv6 for almost as long as Google, though. When you only have one computer on the network, IPv6 is not much work.)


Do any of these incumbents stand to gain financially from IPv4 scarcity?


Yes, Residential ISP's can sell or lease their space to AWS, etc. for example and just start moving their customers over to CGNAT. Why bother upgrading your entire network, planning allocations, etc when you can just NAT everyone for cheap?


Can confirm this is happening. If you're lucky enough to have a choice in ISP, there are a few that won't CGNAT you. I pay a little extra for this ($10 a month) but it's worth it for me. Ask your ISP if that sounds interesting.


Is that really a feasible long term solution though? I require port forwarding and also work from home so require my service not get blocked due to some spammer on my block.


I’m sure your ISP would love to sell you a business connection for 3x the price


This honestly sounds like a perfect case for a business connection. Not only does it give you a static IP without NAT, possibly in an address block with other high paying (==reputable) people, it also bumps you up a lot in terms of customer service and service availability. Usually the first two questions in an outage are "how many customers are offline, and are any business connections impacted".


That assumes the ISP is willing to run a business connection to a residential address. Not every ISP will, especially if you're just a home user with special requirements and not an actual business.


Perhaps not, but two years in and still going fine. Maybe once IPv6 is more widely adopted I won't need it anymore.


That's such a ridiculous overcharge. Even a dollar a month would be well into overkill.


It includes a static IP, but yeah I agree it's a bit steep. Other ISPs would make me buy a business line, which would cost a lot more than $10 extra.


have you considered just using IPv6 instead of paying that charge?


NAT requires planning and expensive equipment; it's not obviously cheaper than IPv6.


Yes, but it doesn’t require upgrading all your routing hardware and the planning involved with adapting your physical network design to work with the hierarchical structure of IPv6 (we’ve had TCAM large enough to map every /24 of the v4 space for some time now, you can’t get away with that shit with v6 even if your hardware optimizes TCAM usage for routes up to /64’s).

This is why many residential ISPs and business haven’t implemented IPv6 yet (well, the later enjoys the false sense of security NAT provides too).


I would be very, very upset if my ISP decided to throw me into a NAT.

Fingers crossed they don't lol.


I'm behind CGNAT for my home connection :(

However, I also have native ipv6 to the home for as many devices as I want. It's easy to forget that carrier NAT is expensive for ISPs as NAT hardware needs a lot of fast RAM.


I feel like I would mind NAT less if they gave all the devices IPv6, similar to how it works on some LTE networks.

But IPv6 prefix delegation doesn't always work if you put your own router behind the ISP box...


As long as you have a public IPv6 address, just use that.


Kind of. IPv6 addresses are for the most part worthless. They're only useful to shed load for CGNAT but that's only workable if you can configure the end user devices, hence why it's taken off with carriers.


Not just incumbents. Have you seen a single startup that uses IPv6 for all their internal networking (running NAT on their internet uplink if needed)?

If every single incumbent and every single newcomer is dragging their feet on IPv6, maybe, just maybe, the problem isn't every single engineer in the industry, the problem is IPv6.

Theoretically we could have had a straightforward extension of IPv4 to a longer address length and the exact same design, but some architecture astronauts took over the IETF and they think it's more valuable to push their weird redesign of the internet than to actually solve IPv4 address exhaustion.


This sounds a lot like "These newfangled automobiles are scaring the horses!"

The situation feels like chicken-and-egg to me. If I had the option to use IPv6 at home, I'd be on it 100%... as-is, there's little motivation to move off of v4 internally since I'd have to NAT/tunnel to get to the v6 internet over Fios. That said, most of my link-local intranet traffic is on the fe80:: network, because that's what avahi and mDNS prefer as answers.


Game over IPv4.

There's still a lot of waste that can be reclaimed before it's game over for IPv4. For just two examples - both Ford Motor Company and Prudential Securities are currently assigned over 16.7 million public IPv4 addresses each.

https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...

So do Apple, AT&T, the U.S. Postal Service and others.


The problem isn't the number of addresses, it's the address space fragmentation. The IPv4 global routing table is already 3x the size it should be. At the point where you're just giving every device an arbitrary number, the addresses cease to function as addresses.


LISP is meant to solve this problem, but it's yet to be deployed outside of the test network. It could also be used to address exhaustion to some extent by allowing the use of prefixes longer than /24 on the internet, although that is not the intention.

https://www.lisp4.net/

https://neverthenetwork.com/notes/lisp/

Full disclosure, the second link is my blog.


I guess this would give us a few years of breathing room by letting us fragment ipv4? Does anyone support this other than Cisco (ie Broadcom/Cavium/Intel/Barefoot)?


Really it's meant to solve the fragmentation that already exists. Cisco developed the standard, but it's completely open.

I believe Cisco is the only large vendor that's implemented it, but there are Linux and BSD implementations, which should make it easy for any Linux or BSD based NOS to implement it in the future.

Honestly this problem will probably be mostly solved in hardware with larger FIBs/TCAMs

Edit - I should clarify the problem I'm referring to here is fragmentation, not exhaustion.


Especially if you stop allocating TCAM memory for the much larger v6 addresses. I hate to think how much memory is sitting out there in routers, configured for 128 bit v6 addresses and never used...


You only need 64 bits for routing v6, and since the address space isn't fragmented the routing table ends up at a similar efficiency level to the v4 one - probably better once you take into account not needing CIDR.


Indeed, until now there has been no financial incentive for those companies to sell the IPs. At a certain point demand and willingness to pay rise making sellers interested in selling. Or maybe IPv6 will happen instead. The problem is IPv6 requires a lot of very complex inventive alignment, whereas an IPv4 market will just result in a well understood price/scarcity relationship.


The going rate for an IPv4 address is at least $10 each. Selling a /8 block would be a nice $160 million profit.


Ouch! That makes Stanford's voluntary surrender of their /8 block back in 2004 extraordinarily expensive! Think about how many scholarships that could have paid for!


That price is based on what Microsoft paid for Nortel's block in 2011.[0] I think there was another purchase of IP addresses since (by Amazon, maybe), but I'm not able to locate a price.

[0] https://www.networkworld.com/article/2228854/microsoft-pays-...


DuPont sold off their 52.a.b.c to Microsoft and Amazon 5 years ago.


I've been sitting on a /23 for almost 10 years for this day. Who wants to lease my block


First reaction (after looking up that this is 8 million addresses): wow, nice!

Second reaction (after the "$10/IP" part clicked): oooh, this person is going to have a lot of money soon o.o

But you don't have any contact info in your bio!

(I'm in no position to seriously respond - I'd only want one or two addresses to play with)


Er no, a /23 means they control the last 32-23 = 9 bits, so that's 512 addresses. So /if/ they sold that for $10 per address which is plausible that would be about $5000.


._.

Thanks.


It's well over 10 today.


AT&T is an ISP, with millions of customers. I'd expect them to need a /8, or more.


AT&T (the ISP's) allocations are to AT&T Corp, not AT&T Services.


AT&T's 12/8 is used for end-user address assignments by AT&T Services. See https://bgp.he.net/AS7018#_prefixes for their announcements.


Most of their broadband subs are from legacy SBC (ameritech, swbell, nvbell, pacbell, snet). They got all their allocations separately. None of them came out of 12/8 or 32/8 traditionally.


Apple and USPS are not ISPs. It doesn't seem like they need a /8 though.


Comically when Apple would setup a store they'd ask their isps to provide an allocation rather than dip into their allocation.


From a global routing perspective this makes sense. Otherwise every store has to advertise its netblock on BGP. Not impossible, but it bloats the routing table unnecessarily. Better for Apple to keep those addresses on its campus and let the stores connect like regular Internet endpoints.

Even better would be for Apple to return most of those addresses and only use a handful of /16s for its hosted services like any other business and switch the internal nets to RFC1918.


So, in the speeds ipv4 was handed out before they ran out, how long would two /8s last? Weeks? Months? You'd be able to slack on moving to ipv6 for those weeks, months. Whee.


The last two /8s were handed out in January of 2011 so quite a bit longer than weeks or months.

https://en.wikipedia.org/wiki/IPv4_address_exhaustion#Addres...

Entire networks of computers can share a single public IP address so the 33.5 million public IP addresses supplied by two /8s could last quite a long time. Or we can let Ford sit on them.


So given the rate at the time,

https://en.wikipedia.org/wiki/IPv4_address_exhaustion#/media...

with some 1M ips given out PER DAY, how long would two /8s last? 4 weeks, or 33 days. That is not "quite a bit longer", it is literally what I suggested.

It is only now, long after the crunch that thinking entire networks would share a single ip (hopefully never running any SIP,bittorrent or something that needs more than one port simultaneously) or the entire network would quickly run out of the 64k ports usable...

So, if Ford and whoever had that second net did give it back when it started to get scarce, all of 33 days is what we would have "won". Good margin for writing up that ipv6 migration plan I guess.


Ford? is there a listing of what companies own the largest blocks?

EDIT: just found it https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...


I don't think Apple will ever give up their IPv4 block unless forced by legal means of some sort. They use the massive IPv4 block internally if I recall correctly.

I could see most others doing it though.


Yes I heard the same thing. Must be really convenient having a publicly addressable (probably not publicly routable) IP address for every machine internally.


Yes, it does make a lot of stuff much easier. Which is why it is so painful to see IPv6 mired in the mud for year after year.


AfriNIC still have space. They're expected to run out sometime before the end of January (20% chance) to the end of April (90% chance) next year.


They're making some seriously questionable allocations, for example nearly /9 or /10 of v4 to a Hong Kong company that has zero connections to anything in the Afrinic region, that appears to almost all be announced in Los Angeles and running proxies, with the rest being used for fraud/spam.

I'm wondering how much justification validation they are actually doing, or if something worse is going on.


>or if something worse is going on.

given the recent corruption allegations with PIR/ICANN, I wouldn't be surprised if it was corruption.


Well, that sounds like awfully little validation. I guess they are in good company with the rest of the world then.


So out of the five RIRs:

- APNIC ran out

- ARIN ran out

- RIPE NCC just ran out

- AfriNIC is expected to run out in 2020

- LACNIC is expected to run out in May 2020 https://www.lacnic.net/1039/1/lacnic/ipv4-depletion-phases


Soooo...raiding party to Africa then?

They're pretty low too though

>AFRINIC has no more than one /11 of non-reserved IPv4


And yet my ISP still doesn't support IPv6...

Until something forces the transition nothing is going to change.


I think economics are the best candidate to force it. Until IPv4 addresses get actually scarce, in a practical way that directly impacts people (not just a future, we gotta solve this eventually way), people won't feel the heat.

And before now, there were still some unused addresses available. We've just begun the phase where we have to scrounge for loose change in the couch cushions. Previously there was money in the wallet. (Only a little, but that's what you use first.)

My guess is scrounging will initially be easy. Then it will get gradually harder, until eventually it becomes easier to just use IPv6, and then people will switch over.


I bet Residential ISP's turn to CGNAT before they roll out IPV6.


I recall hearing a while ago that those who were early adopters of CGNAT (predominantly mobile providers) are backing away from it due to problems, and shifting more rapidly to IPv6.

(And apparently the police are not big fans either, as it makes it more difficult to track down miscreants).


Would be interested in hearing more about the problems.

From a consumer standpoint the problems I've run into and heard about are:

1. Can't use port-forwarding anymore since you can't configure the ISPs router doing the NAT

2. A bad neighbor sharing your IP can get you IP banned on sites that still think IP address is a good way to block/throttle bad players

3. Connections can be unstable if there's a lot of connections going on, so prime-time can often run into issues.


2 is an interesting point. Let's say you want to rate limit login attempts to help reduce brute force attacks. How would you recommend doing it if not by ip? You can tie it to the specific username being requested but this has other downsides, ie. you can DOS someones account by sending fraudulent login attempts to it, and it also doesn't prevent attacks where people just test previously leaked username / password combos against your site.


Rate limiting by IP is trivial to work around. If you’re doing something white/grayhat there are plenty of services that will allow you to affordably "lease" as many IP addresswas as you need for very short amounts of time. For blackhat purposes it’s only slightly more effort and even cheaper to do the same thing, illegally of course.


> How would you recommend doing it if not by ip?

Not at all, it's a stupid idea. You are trying to nail down an identity without authentication, that can not work. If you use credentials with sufficiently high entropy, which you should do anyway, you don't have a problem that this could be the solution to.


This is where CAPTCHAs come in, unfortunately.


Depends on the country. Whenever I visit Belgium I get IPv6 in random guest houses. Google sees nearly 50% adoption. https://www.google.com/ipv6

In Finland 2 out of 3 mobile operators give you IPv6 by default (and mobile data usage is very high).


Why is the graph so perfectly periodic?


Weekend vs workdays. Shows that IPv6 penetration for residential ISPs is higher than IPv6 adoption at corporations.


Exactly. And you can see Christmas. As soon as a paid network administrator is involved IPv6 seems to be a problem :)


They are alaready doing so. IPv6 test enviroments has been a disaster in the ISP I work for, too many devices don't support IPv6 in the domestic market and solution to router IPv4 over IPv6 are problematic.


The largest ISP in the US, Comcast, has deployed IPv6 on 100% of their network. If they can do it, why can't you?


To the best of my knowledge, Comcast is running dual-stack v4 and v6. The GP was talking about running a purely v6 network, and pointing out that it wasn't yet feasible. Your example of Comcast doesn't really fit the bill because Comcast already has a v4 network to all of their customers, and they are not migrating customers to a solely-v6 network.

This is the chicken-and-egg problem that all new networks are facing with regard to IPv6 adoption. In order to have a usable network, you have to support IPv4 to all endpoints. But once you have v4 at all endpoints, the incentive to run v6 is greatly diminished.

As always, v6 needs a "killer app" that Grandma wants to use that is unavailable over the v4 internet, and then network administrators could use the actual demand from their customers as a justification for moving to v6. Unfortunately, at the moment, the list of v4-only must-have apps is still greater than the list of v6-only must-have apps.


> The GP was talking about running a purely v6 network, and pointing out that it wasn't yet feasible.

Amusingly that's how mobile/smartphones are supposedly run: the devices get IPv6-only, and if they need to hit an IPv4-only address they are CGNATed.

* https://www.internetsociety.org/resources/deploy360/2014/cas...

* https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mob...


Ah, so that explains it. I just switched from Sprint (which always gave me an IPv4 address) to T-Mobile (which gives me an IPv6 address).


My Verizon iPhone has both a public IPv4 address and a public IPv6 address.

They certainly could be using CGNAT, but that seems like a weird way to do it.


> My Verizon iPhone has both a public IPv4 address and a public IPv6 address.

How are you able to tell with IPv4? You cannot run ifconfig on an iPhone, so how are you determining that?


There are apps like "Network Analyzer" that give you this info. (My MVNO puts me behind CGNAT, no IPv6)


Seriously? On Android it's just settings->about phone


Really? My Verizon Android gets RFC6598 space.


Holy cow, I don't know how I was never aware of RFC6598. When I saw the address starting with 100, I simply assumed it was an actual routable IP.


v6 with DS-Lite/464/MAP is going to be cheaper than v4-only because it allows the ISP to sell off (or not buy) most of their v4 addresses while also using less equipment. T-Mobile has already adopted this architecture.


Maybe you just don't get to know what problems it causes because they don't talk about it. Dual stack is currently under testing and afaik higher ups are not very happy about it.

Maybe we've done too early (it was about five years ago maybe, I don't really remember exactly) and now tooling is better, idk


Both BT & Sky have managed to deploy IPv6 in the UK, so the problems must be reasonably easy to solve.

Unfortunately Virgin Media (my ISP) are still dragging their heels but have decided to go with DS-Lite.


Very interesting, thanks for sharing. What kind of devices are they? IoT type stuff, smart TVs, etc?


Right now IoT devices use a communications model that overcome's NAT by tying the device to a service endpoint in the cloud. The device registers itself as an IoT device in aws and then your local hosts hit the device by going to the device endpoint in the cloud. I don't know if this model will hold up when IPv6 more widely supported though.


Maybe the smaller ISPs.

Many large cable ISPs in the USA have been running IPv6 internally for years now. They likely have some of the largest deployments if you account for all their IP managed gear.

Of course, these are the same ISPs that already provide a dual-stack gateway to their customers.


> Many large cable ISPs in the USA have been running IPv6 internally for years now.

CableOne/Sparklight says hi, because they have zero intention on deploying v6 for the foreseeable future.


Not sure I would classify CableOne/Sparklight as a large cable ISP. Their website says they service about 900k customers. Even if all of these customers had internet service this would put them fairly far down the list of ISPs. I would more classify them as a medium sized ISP.


There's one big issue with CGNAT for ISPs: compliance.

At least in Poland, you must provide law enforcement with information about your subscriber for any given 5-tuple at a given time (timestamp, {src,dest}{ip,port} and protocol). If you're CGNATing everyone, you have to either:

- log all outgoing connections (which is a GDPR hazard)

- design your CGNAT to use static outgoing ports for a given customer (but then you're running out of ports pretty fast, if you're doing anything close to >=500 subscribers)

With IPv6, you can just immediately tell who the subscriber is based on the IP address, and as such don't have to log anything.


If you need consistent ports, you could assign many internal IP’s to the NAT to support more ports for your NAT.


Does the GPDR override the data retention law? I was reading some stuff about VPNs which suggested it might.


No. The GDPR explicitly doesn't concern matters of lawful interception, intelligence, police and justice.


Crikey, the amount of storage required to keep that will be insane. What's the retention period?


One year but not a day more (data protection laws).


Look to the mobile networks as a sign for things to come. How much money do you think network operators are going to invest in a highly available and performant IPv4 CGNAT experience? I know of one large mobile network that said they're constrained on CGNAT capacity and their plans arent positive.


My fiber ISP gives you overloaded PPPoE for the legacy "dedicated dynamic IP" experience, IPv6 is carried over more modern and performant IPoE infrastructure, and if you want you can use DS-lite for IPv4 to trade CGNAT for performance

Most of the stuff regular people care about performance for is on CDNs that support IPv6 (or is YouTube, Netflix etc)



The correct answer is "both". IPv4 CGN is inevitable because there are more people than addresses. Native IPv6 lets people bypass the CGN.


Also, only 25% of top 1000 alexa websites has IPv6: https://www.worldipv6launch.org/measurements/

The adoption rate has been really slow.


Why are you, as a consumer, interested in switching to IPv6?


Because adoption of ipv6 allows everyone to be an equal on the internet again. Right now half of the computers hooked up to the 'net aren't even given a routable IP address. They're behind carrier NAT unable to participate like a real computer. They can't use protocols, they can only consume third party services over HTTP/S for the most part.

If everyone is routable it cuts the gordian knot in the "What kind of content should be allowed on our platform?" question by allowing everyone to simply be their own platform. If ipv6 gets adopted fast enough it might just save the 'net from being just a more privacy invasive form of television.


> net from being just a more privacy invasive form of television.

This is such a great analogy.

The Internet has become a dopamine fix. Platforms are generic and inflexible. (Remember when you could change the HTML?) Content is watered down or demonetized for the sake of ad money (Youtube, Tumblr). You can't read the news without getting a video ad shoved down your throat. Commercial video is DRM'd. Browsers (read: Chrome) enables websites to prevent you from copying text or viewing source images. Your every move is tracked to better target ads and sell your profile.


re: being prevented from copying the text -- one can just use Stylus + the following stylesheet

    * {
      -webkit-user-select: text !important;
      user-select: text !important;
    }
+ others for saving Instagram pictures, removing hangouts.google.com background, etc

It is incredible how much more palatable the web becomes with uBlock Origin + uMatrix + Stylus. Not optimistic for the web in the long term, though.


There are websites which can and will manipulate the text you are copying. I am aware of at least one news site which will replace the copied article text with a short summary and a link to the article.

Example: https://www.ghacks.net/2016/05/24/chrome-copy-text-manipulat...


> They can't use protocols, they can only consume third party services over HTTP/S for the most part.

Your comment brings a whole new angle to IPv6 I hadn't before considered. Having each packet routable straight to a TCP/UDP port number eliminates the complexities of NAT. Since the {hard,soft}ware that handles NAT wouldn't be needed, perhaps a shift to IPv6 could also give throughput gains.


Since the {hard,soft}ware that handles NAT wouldn't be needed, perhaps a shift to IPv6 could also give throughput gains.

It does, although barely noticeable. More noticeable is the cost to ISPs for carrier-grade NAT equipment.


IPv6 is already faster on it's own, because the packet header was modified to be more easily routed in hardware.


We also took advantage of the stupid huge address space to make routing tables smaller, it's not necessary to have every /24 (or /64 in IPv6 equivalents) in your tables because we can assign big blocks and stop dealing with fragmented networks all over the place.


Yes, provided your ISP allocates you a P2P link as well as your prefix. Once you get used to breaking up your prefix into subnets it all starts to work quite nicely.

I have even found that real world IPv6 addresses are not quite as bad as they look. We have all seen the auto-generated ones and they look awful but you don't actually use those as such. For example you are allocated a /48 prefix: 2001:db8:1234:: in general you might think of the ISP as 2001:db8:: and your site as 2001:db8:1234::. Your first subnet might be say 000a or simply "a" for VLAN 10 because you decide not to allocate IPv6 to your default VLAN 1 and start with your current PC VLAN which is 10.123.10/24. In IPv4 you have 10.123.10.1 as the default gateway (VRRP) with .2 and .3 for the physical routers. Hence your PC VLAN routers get given 2001:db8:1234:a::2 and 3 and ::1 for the VRRP address. You can play games with 1337 addresses using 0-9a-f eg face:b00c sigh.


In practice we'll still be traffic shapred on ISP level so not so much P2P. It's far more likely that IPv6 will be used to give everyone one single unique trackable address* and we'll all be easily tracked down by IP again. The practical semi-privacy IPv4 let people have will be gone.

Ultimately, technologies are less important than public opinion, politics and commerce in dictating how the net goes.

* Or a single trackable address range, no matter. Yes, ISPs could do differently. Why would they? All the incentives are on the other side.


> Because adoption of ipv6 allows everyone to be an equal on the internet again

Sorry, but this is incorrect. No matter how you connect to the internet, someone has to agree to route your traffic. Just having an allocation of "public" address space doesn't mean you are free to do whatever you want. Other people have to actually pick up your traffic.

If you don't have an ASN and a core router on a backbone to announce and carry your traffic, and instead are just using what an ISP gave you, you really have almost no control over whether that address is routable, what protocols you can use with it, etc. They can impose the same limits on IPv6 as IPv4 - and in order to reduce overt abuses of their network resources, they almost certainly will.

Remember: passing packets requires real money. The larger the number of packets, the larger the bandwidth used, the larger the concurrent connections, the more money it costs. Any segment in the network that takes up significantly more traffic than another, will end up costing a disproportionate amount of dollars and maintenance to support. So unless you're paying for all of it, you will have limits. And just like every other resource on the planet, some people will have more resources than others.

IPv6 is identical to IPv4 in terms of what "freedom" you have on the internet.


> IPv6 is identical to IPv4 in terms of what "freedom" you have on the internet.

It is easier to offer services on IPv6 IMHO. If you want to have some boxes at home to SSH into, you need to provide port forwarding after the first.

So for the first system in IPv4 you would have pubip:22 -> inta:22, but then you have to do pubip:23 -> intb:22, pubip:24 -> intc:22, etc.

With IPv6 you can just use the hosts' IPv6 addresses and punch holes for :22 for each individual system as desired: no port tomfoolery needed.


Sure, but you're talking about using NAT vs not using NAT. You can still get a dozen IPv4 addresses from an ISP and do the same thing as IPv6. But you have to pay for 'em.

The ISP can decide to impose exactly the same limit on allocated IPv6 as IPv4, and charge you for more hosts. Your freedom hasn't changed, only your billing has.


I can get a static IPv4 address for a nominal fee with my residential account. My ISP also gives me a /56, so I have quite a few addresses to play with without a 'business account'.

So from where I'm standing IPv6 is not identical to IPv4.


That is the ideal. But i dont see the home router nat going away. Infact in many ways it is a good thing every home has a nat/firewall going, removing that for ipv6 would be a step backwards. Better and more reliable upnp would be nice.


You'd want the firewall configured with default deny, but there's no need to keep the NAT.


> If everyone is routable it cuts the gordian knot in the "What kind of content should be allowed on our platform?" question by allowing everyone to simply be their own platform.

Do you think the adoption of IPv6 would lead ISPs to drop their ban on running servers from non-business accounts?


Not allowing inbound connections is arguably a feature for most users, not a bug.

I don't think that even given widespread IPv6 adoption, we'll ever go back to a model where residential or mobile internet connections will allow for public reachability by default.

Of course, NATs and firewalls are not the same thing (you just effectively happen to get the latter when deploying the former). But I firmly believe that the bulk of technologies that give us dynamic endpoint lookup and coordinated firewall traversal will outlive IPv4 and NAT.

As an anecdotal example, I used to have a mobile data plan that assigned a public IPv4 address to my phone, including inbound TCP/UDP reachability! That's neither good for battery life, nor for data consumption (on a metered plan). By contrast, my current one puts me behind a carrier grade NAT, but I have no problems whatsoever making peer to peer VoIP calls to friends behind the same type of NAT.


>ipv6 allows everyone to be an equal on the internet again. Right now half of the computers hooked up to the 'net aren't even given a routable IP address.

Given how sht the security on IoTs is I'm not convinced giving everything a routable IP is a good idea frankly. At least not until the IoT players up their game significantly


Unfortunately NAT has made us lazy. If even a small number of a particular type of IOT device is being deployed on native IPv6 networks, you’ve got to face the security consequences anyway.

Also NAT is not a firewall, but that’s a story for another day.


NAT is a poor person's firewall, and even if everybody were to switch to IPV6 I believe that NAT'ing would be here to stay. There are lots of disadvantages to sitting behind a NAT but the positive part of it is that it actually does have some security benefits. I used to absolutely hate NAT but over the years I've come around a bit, and UPnP made it bearable from a tech point of view.


This is completly incorrect. While NAT is almost always combined with a stateful firewall, the NAT itself does not provide any security.

Home devices are always going to be deployed with an allow outgoing, deny incoming firewall, regardless if they have IPv6 or not. They are identical in terms of security.


> This is completly incorrect. While NAT is almost always combined with a stateful firewall, the NAT itself does not provide any security.

It most certainly does. If you have an insecure device behind a nat, say something with telnet sitting open, a port scanner from the outside won't be able to find it (unless you've gone to great efforts to allow inbound connections without an established outbound connection). This is objectively better than if that device were directly addressable.

> Home devices are always going to be deployed with an allow outgoing, deny incoming firewall, regardless if they have IPv6 or not.

Not always. My last router came with the firewall off and that was just a few years ago. A lot of consumer ISPs don't bother with the firewall because they don't want to field customer service calls about things not working.


> A lot of consumer ISPs don't bother with the firewall because they don't want to field customer service calls about things not working.

This is amazing. How does it work? What stops me going to the devices behind the router?


Nothing, apart from IPv6' ginormous address space.

However, I have yet to see proof of any provider that actually deployed home routers this way.


If you looked, I'm sure you could find somebody somewhere. It's not even close to common though.


> It most certainly does.

No, it doesn't. It's a commonly believed myth among people who don't have a clue how IP works, though.

> If you have an insecure device behind a nat, say something with telnet sitting open, a port scanner from the outside won't be able to find it

Why not?


When most people say "NAT", they really mean "PAT". Port address translation: multiple private IP addresses behind a single public IP address. When a non-pedantic person sees "NAT", they understand it is actually "PAT." And in the typical consumer configuration, it actually does provide some level of security.


And when people talk about "PAT", they're actually talking about a form of NAT that doesn't block connections.

Here's how you do "PAT" on Linux: `iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE`. Notice how it's limited to outbound connections ("-o wan0")? That means it doesn't apply to inbound connections, and thus doesn't have any effect on the behavior of inbound connections.

If it doesn't have any effect on the behavior of inbound connections, then how could it possibly block inbound connections?

(The typical consumer configuration pairs "PAT" with a firewall, and the firewall does block inbound connections. It's also typical to pair it with RFC1918 addresses, which doesn't block connections but does make it much harder for most people to make the relevant connections in the first place. None of that changes the fact that "PAT" doesn't block connections.)


So in other words, even without a firewall, it still provides some level of security. If your attacker can't route to your target's addresses because they are private RFC1918, they're "blocked" for all practical purposes. Yes, I know they're not technically blocked... but the typical attacker 10 hops away isn't going to know...


On the other hand, this might also give other people a false sense of security. Most people who tell you that "NAT provides security" think that NAT somehow drops packets, and if your network is actually targeted, this myth might well be the reason why someone ends up downloading all your files by connecting to your file server through your NAT gateway.


No... it doesn't drop connections, so it doesn't provide any security.


In practical terms, it still provides some (low) level of security. If an attacker can't get IP packets to your machine because it's on an un-routable address, they can't attack it. If your attacker is getting "cooperation" from your ISP to route to it, you have bigger things to worry about it.

Obviously you should really use a firewall...


It won't prevent an attacker from getting IP packets to your machine. How could it do that, when it only acts on outbound connections and its only act is to change the apparent source address of those connections?


Did you miss "because it's on an un-routable address" part? If there's no route to your machine from an attacker, they can't attack you.


The discussion was about the behavior of PAT, and PAT has no influence on whether or not an attacker has a route to you.


The discussion is about NAT and PAT in general. 99% of the time it is used with unrouteable private addresses. This means even in the absence of a firewall there is still some level of security. End of story.


It's common to use it with RFC1918 addresses, but that still doesn't change the behavior of PAT. PAT will not drop connections, and thus won't provide you with security.


Security is not black or white, it is shades of gray. We'll just have to disagree.


The behavior of PAT is, though. You can sniff packets and confirm that it behaves the way I'm describing.


I already know this.


In standard consumer networking, say I have a /24 (say 192.168.1.0/24) and one dual-homed host performing Network Address Translation to a Internet routable address, how would an attacker easily initiate a connection to one of the hosts on that internal subnet from somewhere on the Internet?

They obviously can't address traffic directly to 192.168.1.0/24 over the Internet as that's a bogon address and the Internet routers will either reject it out of hand, or not know where to send it.


> They obviously can't address traffic directly to 192.168.1.0/24 over the Internet as that's a bogon address and the Internet routers will either reject it out of hand, or not know where to send it.

That's not obvious at all. Now, you obviously can't just inject a packet addressed to 192.168.1.1 anywhere on the internet and expect it to turn up on any particular LAN, but that just excludes a subset of the possible attack vectors for unwanted inbound connections.

Your ISP can still send you packets addressed to 192.168.1.1. Thus, obviously anyone compomising your ISP, or some subset of their routers can as well (hello Cisco hardcoded passwords!). Also, it has happened that ISPs failed to isolate customers from one another (think multiple customers on the same VLAN), so your neighbour could send packets addressed to 192.168.1.1 to your router's WAN interface as well. Or potentially malware on their network, if someone were to systematically exploit such a setup.

It isn't even unheard of that ISPs forgot to disable routing protocols on customer-facing interfaces and some CPE managed to advertise their RFC1918 space via RIP to their ISP's access network.

Or, for that matter, an attacker could just hook into your uplink between you and your ISP, if you are a valuable enough target, to gain access to your CPE's WAN interface.

All of those are actually solved security-wise by having a stateful firewall, which will also prevent inbound connections from anywhere else on the internet.


So it does provide practical protection to use NAT in that you've reduced the set of valid attackers from "anyone on the Internet" to "people with the ability to affect the upstream router in my ISP"

That (for most average consumers) is a vastly reduced attacker set.

Security is not binary, it's a scale.


> So it does provide practical protection to use NAT in that you've reduced the set of valid attackers from "anyone on the Internet" to "people with the ability to affect the upstream router in my ISP"

Except it really doesn't because you haven't?

There are two practically relevant circumstances where the statement "NAT provides security" is made:

1. With regards to real-world home routers (which also come with a stateful firewall), in which case the statement is simply false: Adding or removing NAT makes no difference whatsoever for security. This is also the scenario that then is used to argue against IPv6, because IPv6 supposedly lacks this security, when it just doesn't, because the IPv6 router also comes with a stateful firewall, and adding NAT (or disabling IPv6 because of a "lack of NAT") achieves absolutely nothing security-wise, because there is no problem in the first place.

2. By people who falsely believe that NAT does in fact prevent all inbound connections and for that reason fail to configure the necessary firewall rules on more business-oriented routers, so the belief that "NAT provides security" keeps them from actually securing their network, and that in particular in scenarios where it is much more relevant than for your typical home user.

So, it is technically true that NAT could have security-enhancing effects under artificial circumstances. But under all real circumstances, it either just doesn't, or the belief that it has is what causes the configuration to be less secure than it easily could be, if only people didn't have the completely not-understood belief that "NAT provides security".


You're technically correct but in practice ever since NAT has been a thing routers have stopped passing on incoming connections to the machines behind it unless specifically - and usually laboriously - configured to do so. This is also why NAT is considered hostile to a peer-to-peer internet, which prompted this very good article:

https://www.fourmilab.ch/documents/digital-imprimatur/

by John Walker, of Autodesk fame.

The router has a public IP and everything behind it has a local one. That you can do NAT in different contexts and that technically you could have NAT without the firewall functionality doesn't change that this is 99.9% of all NAT applications.

A bit more text about this concept:

https://security.stackexchange.com/questions/176744/why-is-n...


I think this distinction is very important, for the following reason: Once you've acknowledged that firewalls are technically optional, but used in 99% of cases, there's no reason to say why home routers wouldn't come out of the box with IPv6 firewalls in 99% of cases too.

And this is in fact what we see in the real world with IPv6 deployments. Roughly 50% of my country has IPv6, and every single provider provisions it with sensible default firewall rules.


By that same logic, NAT provides internet connectivity. 99.9% of all NAT applications come with an internet uplink. Therefore, you need NAT for internet access. Not.


> NAT itself does not provide any security

This is just arguing semantics. It's not "NAT itself", but a side effect of using it is that it requires deliberate effort to allow inbound connections to get to devices behind the router. This has many of the same effective security benefits as a firewall blocking inbound connections does.

Another way of saying this: the companies that make cheap, crappy routers can do the absolute bare minimum and not end up exposing internal devices to inbound internet traffic. So NAT provides security against the cheap, crappy router manufacturers.

With IPv6, the opposite is true: The router manufacturer has to do deliberate extra effort to block inbound connections, beyond just making the router "work". Will most router manufacturers do this extra effort and include a properly-configured firewall? Probably yes, especially if they don't want to get a terrible reputation for being insecure, which would (hopefully) eventually drive them out of business.

Will absolutely 100% of them always do this properly and never make a mistake? I wouldn't bet on it.


> It's not "NAT itself", but a side effect of using it is that it requires deliberate effort to allow inbound connections to get to devices behind the router.

Unless your router has UPnP port forwarding enabled—as most home routers do by default, since popular apps require it—in which case any device can open a hole in the firewall for whatever incoming traffic it wants. In this scenario NAT provides no additional protection beyond what the client device could provide for itself by simply not accepting incoming connections. To get security from a NAT setup you need to disable UPnP and manually configure any required port forwarding, which is at least as much effort as properly configuring an IPv6 firewall.

The right solution IMHO is to have a separate LAN/WLAN/VLAN for the untrusted IoT devices which rejects all inbound connections from the WAN (no UPnP support) as well as all outbound connections to the main LAN. Outbound connections to the WAN for updates or cloud-base control are permitted but logged; inbound connections from the main LAN are also permitted, to control the IoT devices locally. For the main LAN the router should only perform basic filtering for malformed or misrouted packets—ones with an external or multicast destination address or an internal source address, for example. Apart from that, devices on the main LAN are expected to handle their own security. Laptops, smartphones, tablets, and other mobile devices are already required to handle this since they are routinely connected directly to untrusted networks.


In my experience upnp is no longer enabled by default (because: not secure). UDP hole punching usually works though.


My guess is the firewall functionality will stay as long as IPv4 and thus NAT remain relevant. Once IPv4 has faded into obscurity, we'll see the advent of IPv6-only routers that are really only dumb routers ... and wireless access points.


But that just isn't true. There is nothing in NAT that requires dropping inbound connections, so crappy router manufacturers might be failing to do so right now. If there is no firewall on the device, it won't prevent inbound connections, no matter how much NAT it does.


NAT66 is something real.


In theory NAT provides no security. In practice it does.

The way common household NAT works is you have hosts on a private IP space behind a NAT device with an ephemeral internal IP/port table. When an internal device initiates a connection outward the NAT device takes a note of the IP address and port it is connecting to and writes them to the table, along with its own port mapping.

When a packet arrives addressed to the NAT device it checks the table and if it finds a matching entry it rewrites the packet and forwards it back to the original host.

So someone attempting to make a new connection to an internal host is effectively firewalled off by the lack of a mapping table.

Now most people who say "NAT isn't a firewall" are referring to the case where you have for some reason turned off the default firewall rules on the NAT device and have somehow routed a packet with a destination address that is on your internal network. In this case, the NAT will just forward the packet onto your internal host and provide no protection as they say. However, it ignores the difficulty of getting your ISP to route an RFC 1918 address to your NAT device in the first place. The very fact that your internal hosts are on non-routeable addresses is a form of protection provided by NAT.


> So someone attempting to make a new connection to an internal host is effectively firewalled off by the lack of a mapping table.

The lack of a mapping table entry just means that your packet doesn't get translated. It doesn't mean that inside hosts are unreachable.

> Now most people who say "NAT isn't a firewall" are referring to the case where you have for some reason turned off the default firewall rules on the NAT device

Yeah, so: NAT isn't a firewall. The firewall is a firewall. NAT is typically deployed together with a firewall precisely because NAT isn't a firewall.

This is an important distinction, because it means that the security you think you're getting from NAT is actually coming from the firewall, meaning you don't need NAT to get that security.

Note that I'm not ignoring the issue of reaching non-routeable addresses either. Your ISP can route to your LAN range easily, and there are plenty of people who could trick or force your ISP into cooperating. If you want to be secure, you can't rely on "probably I won't receive any evil connections, it'll be fine", you need to actually block them. If you're in a situation where non-routeability is relevant then you were already insecure.

You've also forgotten that NAT doesn't provide you with non-routeable addresses, even if it's typically deployed with them. It works on any address range and it has no impact on the routeability of the range you use. NAT is also not required to use non-routeable addresses (which as mentioned aren't even secure in the first place). So, again, it provides no security.


> They are identical in terms of security.

A bit incorrect. There are IPv6 protocol changes (ex. ICMP vs ICMPv6) where the newer protocols are more secure. But actually having a private IP behind a NAT gateway is more secure in general, because nobody can directly route to a host behind your NAT, without exploiting reverse NAT traversal. IPv6 will allow easier exploitation of default host configurations due to being able to route to them easier.


Will it? You'd still have to get around the router firewall, the host would have to have no firewall of its own and be exploitable and also you'd have to _find_ the host first.

This also needs to be balanced against the difficulty of exploiting servers that have been deliberately exposed to the internet, for example cameras or NASs. People often expose those deliberately (via port forwards on v4) so they can access them remotely.

v6 will make it harder to exploit those devices, because it makes it harder to find them in the first place. Most botnets that run on cameras etc spread via random network scanning, so making those devices harder to find makes it harder for botnets to spread. You can consider this akin to vaccination's effect on the R value for a contagious disease: vaccination can eliminate a disease even when it doesn't eliminate 100% of infections. If a botnet can't find enough vulnerable hosts to exploit, it'll die out.

NAT with port forwards makes it far easier to find devices like that, because it reduces the search space. v4 reduces the search space further still, to the point where it's quite feasible to do an exhaustive search.

On balance, I think this makes the larger address space (without NAT) less exploitable.


A stateful firewall that rejects incoming connections is conceptually simple even without NAT.

NAT itself does have the security benefit of masking more bits of client identity though. If I had a bunch of machines on an ip6 prefix, I would still want their outgoing connections to be NATted, to avoid address-based tracking.


That isn't really necessary any longer. Modern IPv6 stacks devices use and periodically rotate through temporary IPv6 auto-allocated addresses for privacy reasons.


AFAIK "privacy extensions" are just designed to avoid putting the (customarily) fixed MAC address onto the wider Internet. If each device still has a specific /128 at any given time, then the number of devices and the connections from the same device can be inferred - the statistical distribution is still drastically different than per-connection NAT.

We can envision a better version where each device pulls multiple addresses at a time and rotates through them basically per-topic, but I don't think stacks are really set up to do that. But sure we could get there eventually, at least modulo outdated firmware stuck with said vulnerabilities. On the other hand, if we already need maintained premise routers to manage incoming connections, they can simply NAT outgoing connections and get a perfect probability distribution across IP6+port that fully masks the internal network.

Ultimately I think the distinction between "outgoing" and "incoming" connections is only going to continue increasing, regardless of IP6.


Most IPv6 routers allow you to keep the same behavior as NAT, e.g. simply do not allow new incoming connections to your prefix.

Not saying that you’re incorrect, but the problem might not be as big as you think.


NAT is really firewalling at all. It just accidentally implies a "default block new inward" policy, which any good actual firewall setup for IPv4/IPv6/other would have as a default anyway.

Were it not for home routers supporting NAT because they need to with IPv4, the same routers would have a basic firewall with that default block rule in place.


I think you meant 'isn't', and we're in agreement. It is just that it has some of the same effects.


Yep, small accident between the brain and the typing fingers there.


> If everyone is routable it cuts the gordian knot in the "What kind of content should be allowed on our platform?" question by allowing everyone to simply be their own platform

No, it really doesn't. It makes easier one aspect of developing peer to peer software. Which sure is a good thing, but it's not some panacea. Our regressive software landscape didn't come about because end users simply didn't have easy access to routeable IP addresses. But rather because tinkering with software can be tedious, developing easy to use software takes resources, and the most straightforward way of recouping that investment through surveillance and control.

Right now, you can get a VPS with perfectly routable addresses for $5/mo. And if you're not interested in or able to afford that, you're certainly not going to leave your own machine up 24/7 as a server. In reality, IP/DNS is a namespace that's terrible for user-facing systems - it itself causes centralization by necessitating that singular authoritative servers answer requests for a named object. What we actually need for a non-corporate net is higher level addressing such as content concentric networking (IPFS et al).

(I've gotten some downvotes, and I would be really interested in hearing the actual disagreement. I know we're all biased to think this paradigm of IP4/6 could do everything we want, if only it were used "correctly". But after a few decades of watching things evolve I just don't see how it's sufficient for de-centralization).


> be their own platform

The public commercial platforms offer far more than just a routable IP. You get reach, reliability, resilience, and security (the kind you don't get to build yourself).

Being your own YouTube/FB/Twitter/someChan/etc. platform means almost nobody will ever hear about you, the ones that do can easily wipe you off the internet, coming back is a real hassle, and that your data will leak is basically a forgone conclusion. Being your own Dropbox/GDrive may not need the reach but still relies the other three to provide value. And the list can go on for almost anything you can think of for "being your own platform".

The overwhelmingly vast majority of people have little to no interest in building and maintaining any such platform. It's why so few people actually do it today even when having a routable address. It's inconvenient even for skilled people, let alone regular ones.

I'll wait for a counterargument.


Huh. So, nobody's heard of PeerTube (https://www.joinpeertube.org/), Friendica (https://friendi.ca), Mastodon (https://joinmastodon.org/) or Diaspora (https://joindiaspora.com/). The overwhelming majority have little to no interest in building and maintaining such things. Interesting…

(It's fine to assert things, but make sure you're right first. Asserting things you don't know to be true is disingenuous, and a bad habit.)


Yes, by comparison, approximately no one in the world has heard of PeerTube, Friendica, Mastodon or Disapora. And even of those that have heard of them, few actually use them. Centralized platforms for these things are simply so much more convenient and discoverable that there really is no competition.

Look at the speed with which WhatsApp was adopted (talking about before the FB acquisition), and compare to Mastodon or Diaspora - there is no contest.


Mastodon is big news in India at the moment, to the point that some newspapers are trying to pretend it's centralised and "hates right-wing people" (because one instance refused an account to a police organisation).

If it's getting newspaper coverage, it's probably not all that niche.


None of those are your own platform. You have a share in them. Their value isn't in being "your own", it's explicitly in being "nobody's own" or "everyone's", depending on how you read it.

If you somehow use them only for yourself so they run effectively as "your own" (assuming you can and want to isolate them) you run into the same issues I mentioned above.

Your comment in brackets applies very much now ;).


Back in my day bittorrent was pretty popular.

We'd have doused Zuck's dorm room sever in gasoline if we'd known what was to happen.


But that wasn't your own platform was it? It was explicitly distributed. The crux of my comment was the "own" part. You don't just have a share in it, it's yours.


The desire to own and control is what led us to where we are.

Let's go back to distributed. Let content proliferate according to novelty and interest gradients. Don't tax it. Don't rent seek.

There are ways to profit without ruining it for everybody else.


The comment I was replying to clearly states "be their own platform" which is why I replied to it. What you're saying is a completely different conversation and the arguments don't dismiss what I said: the number of people who can successfully "be their own platform" is statistically insignificant so IPv6 is irrelevant for this purpose in particular.

I still don't understand how bittorrent (or any decentralized platform) is "your own platform". Most people will always just be part of someone else's platform. Whether it's YouTube, PeerTube, or friendica, it's never their own and IPv6 won't change that. And they explicitly sell themselves as distributed which by definition makes them shared, everybody's, or nobody's. They can never really be your own and that's exactly what their appeal is.

Most people are unable (due to skill, money, or effort constraints) to manage their own platform. And the ones who can don't need to wait for IPv6.


While people seem to be unhappy with this argument and are downvoting it, it gets at a fundamental truth about "big silos" vs. "own your own content": the vast majority of the world isn't on Facebook and Twitter rather than individual Jekyll and Mastodon instances because they're waiting for widespread IPv6 adoption. There are substantial usability hurdles for the Average User in doing this sort of thing, and if we're really serious about letting more than tech nerds "be their own platform," that needs to be addressed.

Having said that, it's still possible to hear about independent websites, nobody can "easily wipe me off the internet," and I'm pretty sure my data is far more likely to leak from actual YouTube/FB/Twitter/someChan/etc. than it is from a non-monetized, advertising-free Mastodon instance, let alone my static website. But it's also absolutely true that the best way for me to drive traffic to my web site is getting linked from Twitter or Reddit; discovery is one of the big problems for federated, decentralized networks.


Not OP, but I can tell you why I as a consumer am very much not interested in IPv6. My ISP supports it, but I have intentionally disabled it.

It only causes problems for me with absolutely no gain. There isn't a single website I can't reach, and no website that I've found runs any quicker when using IPv6.

But at the same time, if I have v6 on, it causes delays in name resolution and sometimes I just can't connect to a site until I disable v6.

I still have an addressable v4 address, so I can still run a home server.

I don't know how to fix this. I know that v6 is good for the planet, and I know these problems won't get better until more people are using v6, but it's definitely a chicken/egg problem.


> But at the same time, if I have v6 on, it causes delays in name resolution and sometimes I just can't connect to a site until I disable v6.

That sounds like your ISP does not actually support IPv6, eg. doesn't have the full Internet routing table for v6. I've seen this happen.

DNS v4/v6 resolutions can also hang with glibc because of a well known bug with Happy Eyeballs when ISPs that fuck up outgoing DNS packets (eg. messed up stateful NAT/DPI). "options single-request-reopen" in /etc/resolv.conf is a workaround. See https://bugzilla.redhat.com/show_bug.cgi?id=505105.

I would contact your ISP, or at least publically shame them. This is not how IPv6 Internet should work (source: we provide IPv4/v6 as an ISP and take care to prevent issues like this).


Even if the ISP does everything right, there are a lot of small sites with broken IPv6 setups caused by incorrect server and DNS configurations. While my ISP appears to provide a solid IPv6 setup, I've ran into quite a few issues with sites either:

- Serving different content on IPv4 vs. IPv6, e.g. just showing Apache2's "It Works" page

- Serving some subresources behind a reverse proxy on IPv4 only (and 404ing on IPv6)

- Forgetting IPv6 AAAA Records after a server change

Trying to debug this as a user is annoying and even if I identified the issue before leaving the site, working with sites to get it fixed has been an issue. I quickly ran into the "Works for me" issue, when the administrators (and a majority of their users) ran on IPv4 only networks.

Ultimately I just disabled IPv6 on all my systems because it ends being more trouble than it's worth.


It's AT&T (UVerse). If they can't get it right, I don't have much hope for anyone else.

Also, I don't even use my ISPs name servers, I use Cloudflare or Google, so I don't think it's that unless the ISP is somehow munging the packet in transit, which I suppose is possible.

Honestly I think it is all due to issues with the v6 stack in MacOS.

But my point is, I shouldn't have to be a network engineer to make v6 work. I should be able to turn on my computer and just have it work.


> Also, I don't even use my ISPs name servers, I use Cloudflare or Google, so I don't think it's that unless the ISP is somehow munging the packet in transit, which I suppose is possible.

That's exactly the problem. You send out two v4 DNS UDP packets one after another (one for A, another for AAAA), both go via your ISPs CGNAT, the CGNAT gets confused, one of the packets gets dropped. I've seen this exact behavior when talking to 8.8.8.8 on Orange in Poland (and they do DS-Lite). It didn't occur with the ISP's DNS, because a) they were also on v6 b) they weren't getting CGNATed.

> But my point is, I shouldn't have to be a network engineer to make v6 work. I should be able to turn on my computer and just have it work.

By disabling IPv6 you're letting shit ISPs get away with this. Your ability to debug this and to figure out it's the ISP's issue should be used to voice your concerns, and not just let this slide.


You should know from your own background that AT&T doesn't quite have a history of excellence in the Internet realm.


Oh yes of course what I meant was they are a huge ISP and have lots of customers, and if it doesn't "just work" for them, then what chance does anyone have of v6 taking off?


Counterpoint: if they fix their shit, the chance of global v6 adoption increases dramatically.


I've never had any issues with IPv6 on Comcast, and I've been using it almost since day one. AT&T is not a company you should ever hold up as some kind of good example of network engineering.


I was never able to get ipv6 to work when I was on AT&T, couldn't even get addresses assigned. When I got on Cox at my new house it worked out of the box. So some ISPs get it right.


> I would contact your ISP, or at least publically shame them. This is not how IPv6 Internet should work

Maybe this is true. But as the other guy said. There is zero benefit in moving to v6 so there isn't any point in taking the time to investigate.


> It only causes problems for me with absolutely no gain. There isn't a single website I can't reach [..]

With RIRs running out of addresses, that's about to change (well, realistically, maybe in 1-2 years).

As techs, I think it's our responsibility to push this forward and keep the Internet free and decentralized.


> With RIRs running out of addresses, that's about to change

I doubt it. Websites that want to be reachable will find a way to be reachable.

> As techs, I think it's our responsibility to push this forward and keep the Internet free and decentralized

I agree, but there is only so much I'm willing to sacrifice for that effort. I've tried to use v6 for at least two weeks on three separate occasions. I do that about once a year. That's the level of sacrifice I'm willing to make for this effort.

My hope is that one year it goes so smoothly I forget to switch back.


For web servers it will be CGNAT in reverse. One overloaded IPv4 load balancer trying to keep up with too many servers behind it. But you'll be able to use its IPv6 address directly.


One benefit I've found of having IPv6 enabled is that it allows me to use certain sites (particularly gmail) while my PC is connected to my work network via a VPN.

Edit: I should point out that I had no idea my machine was using IPv6 until I wondered why I was able to use Gmail and not other sites (such as HN).


I disable v6 on any linux install unless I specifically plan on using it. The fact that it can easily be accessible over lan and over the internet due to how good the auto addressing and link local addresses work is a concern.


Please don't do this. Any firewall will work for security concerns, and RFC4941 support will work for privacy concerns.

I haven't seen a consumer CPE that both supports v6 and doesn't firewall off incoming v6 connections, and I haven't seen any operating system in years that doesn't enable RFC4941 by default.


I will continue to do this. Like I said,if it is planned use it will be enabled and specific firewall rules will be implemented to allow safe use. Not everyone has same requirements.minimizing attack surface ,reducing admin overhead and being explicit about configuration items are some of my needs. V4 is no different, i almost never enable dhcp and might even disable ARP. V4 happens to just be configured explicitly by default.


My ISP provides me with a CGN IPv4 address. I have no ability to access any self-hosted services, unless I pay them money for a static globally routable address, or pay some other company to provide this through some other means (e.g. VPN, VPS, etc)

If they supported IPv6, and gave me a globally routable address that was unfiltered except at my gateway, I'd be happier.


There's the Hurricane Electric IPv6 Tunnel Broker:

https://tunnelbroker.net/

>Our free tunnel broker service enables you to reach the IPv6 Internet by tunneling over existing IPv4 connections from your IPv6 enabled host or router to one of our IPv6 routers.

(It's still obviously less direct, and inferior to your ISP supplying native IPv6, but it may improve your situation.)


That solution requires a routable, Non-RFC1918, IPv4 address somewhere to work. If I understand CG-NAT correctly, you don't get a routable address on your equipment.


You're right. HE is 6in4 and won't work.

There's a list of brokers at https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers

https://6project.org/ looks viable (OpenVPN) and cheap.


Not OP, but with more and more IPv4 traffic behind CGNATs, IPv6 begins to be a much better experience. CGNATs tend to be massively overloaded, and as such accessing IPv4 Internet (especially CDNs for multimedia) will tend to result in low speed and dropped connections at peak hours.


This is the answer.

IPv6 was always about maintaining the status quo. It doesn't become "better" than IPv4 until CGNAT makes IPv4 worse. (Or if your internal network reaches the scaling limits of RFC1918.)


I’m not a regular consumer, because my views are based on being a system administrator for a company that have a ton of dual stacked and IPv6 only server, but I want IPv6 at home because I want IPv4 to go away completely. No IPv4 would remove a lot of confusion and silly work-arounds.


This is an incredibly niche concern, but I fought to get IPv6 working for myself because I have an EC2 instance that auto-sleeps when I'm not using it (to save money) and every time it wakes up the IPv4 address changes. Amazon will give me a static address but unless the machine is running the static address costs money. Again the whole point was to save money... and static IPv6 addresses are free on AWS.

So as long as I connect to the EC2 instance over IPv6, I get a free static IP address on my server.


That's a direct side affect of the difference in cost between IPv4 addresses and IPv6 addresses. If IPv4 addresses weren't economically rare, AWS would charge for them.


Does anything prevent you from using a free DynDNS provider?


There were a number of good choices. I chose ipv6 mostly because I wanted an excuse to try ipv6. I did consider dynamic dns but didn’t explore it much.


My interest is twofold:

a) for one as a response against CGN, thankfully my ISP isn't using one right now but I have a hunch they're going to start becoming a lot more common in the future. and b) as a hacker I'm interested to finally set it up and play around with it.

Also IMO even if it doesn't bring any improvements to the general consumer given all the pressure to start switching to IPv6 it is a good thing to be interested about it, pressuring more ISPs to start supporting it.


Having just spend two hours messing with a tricky NAT configuration (VPNs were involved) I'd very gladly move to full IPv6 everywhere, thank you.


the casual user at home, with no exposed services to the public, has no real need for a short ipv4 address. ipv6 would suffice just fine for the end user, and the isp can handle the v6-to-v4 translation in their own infrastructure. this would free up a substantial amount of ipv4 space.

the isp could also provide dynamic dns as part of their package for users who do want to access their devices at home. why remember a 4-octet ip when you can get your own subdomain from your internet provider?


That’s not entirely true. Everything p2p is complicated with nat2nat and requires things like STUN, which are not working reliably all the time. Casual users need IPv6 to get better video and voice chats, as well as interactive gaming experience.


Likewise, curious. Would be neat to have it but as someone who supported consumers,v6 is a pain(or rather v4 is still so easy people prefer it when making new software).


I would be if I could pick and choose different parts of the protocol. I don't want each interface to have multiple IPs, and I don't want to jump through hoops to assign static IPs to devices. I don't want to have each device reporting its domain to circumvent the IP problem, and I certainly never wanted 128 bit numbers.


The vague "jumping through hoops" aside, I am very, very glad about every one of these features.

Maybe you could elaborate on why you assume these things are bad?


Sounds like you're stuck in a very outdated mindset.


I think it'd be cool to access my home machine from anywhere without bothering with port forwarding stuff.


Well, you still need to bother with adding firewall rules. But that's a lot less annoying than port forwarding, I agree.


I hate dealing with NAT and split horizon DNS to access my NAS.


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

Search: