Hacker News new | past | comments | ask | show | jobs | submit login
Ripe NIC: 'In Five Weeks We'll Run Out of IPv4 Internet Addresses' (ispreview.co.uk)
136 points by dyslexit 22 days ago | hide | past | web | favorite | 231 comments



Stupid question: Everytime I'm given the option to work with v4 or v6 (which, granted, is not often) I do v4 for one silly, stupid reason: I can remember a v4 address for, like the 10 minutes while configuring that I might at any moment have to record/enter it somewhere. (So: Not just once, but being able to have it as needed in a small time window)

What do people do with v6? Have better memories than me? cut-and-paste repeatedly as needed?

While I do less-and-less sysadmin work over time, even on my home network, there are opportunities to get more comfortable with v6 that I've skipped because of this, yet I never see anyone talking about it.


Perhaps the impulse is cruel but for me, the fact that humans can't remember IPv6 addresses is a selling point. It forces people into what I believe are better practices (indirection through dns, using tagging in firewalls and load balancers, auto-assigning IPs, copy-pasting addresses in the cases where they're actually needed).


> It forces people into ... better practices

I've got no beef with IPv6; it seems pretty great there being enough addresses that everybody gets one.

That said, being unmemorable is not a feature. Doing nothing is an alternative to doing things 'the right way' and people will choose it. The situation will backslide a little bit - with IPv4 people would do things, with IPv6 some people won't. Unless the goal is to configure IPv6 systems for their own sake, this is an unfortunate and unwanted side effect.


Do you know the IP addresses of your servers? You shouldn't know them. That reveals a lack of automation at a pretty low level of your infrastructure.

IP addresses change all the time in cloud environments and container orchestration systems. Even if they didn't change, you get better systems if you pretend they might. It doesn't matter if you use containers or not -- if you assume IP addresses could change at any time, you end up with infrastructure that is tied to your service graph rather than your hardware.


What about when the host is your domains dns server, and you need to ssh to it to fix a broken dns configuration. But because dns is broken the hostname you would use isn’t resolving anymore.


If a public domain, there needs to be NS records pointing at it from the registry, and they need to either have glue records giving the IP and/or at least one ought to be on a domain your name server itself is not the authoritative dns for.

If a private domain and/or the server is only reachable from private IPs, then its IP should be in an asset management system somewhere (it should be if it is public too); be that a full blown orchestration system, if cloud servers or containers, or some form of asset register - even if only a spreadsheet - if it is physical servers in your own data centers.

If properly automated, that asset register should drive configuration deployment - you shouldn't ssh to it to fix a broken dns configuration, you should run your deployment with a fixed config.

I get that this is an idealized setup and that a lot of the time things intervenes and it's quicker and easier to do things manually then and there. Been there, done that, but in the long run it pays to invest the time in then cleaning that up (up to and including wiping clean setups that have been manually updated to verify that the automated setups are correct and complete).


dude I'm not setting a DNS to access my NAS or my raspberry pi


If a computer's host name is "giggidy", then when it requests a DHCP lease, it sends that name to the DHCP server. If your DHCP server is hooked up to a mini DNS server, then the DNS server will resolve "giggidy" or "giggidy.whatever" to the IP it was assigned. This is how dnsmasq works, and a lot of consumer internet routers, too.

The router's IP and a nameserver IP are the only ones you should have to remember in the event of problems, and both of those can be short and simple.


I don't see anything in my network that responds to ping $hostname or ping $hostname.whatever


Then pick a memorable address, something like <prefix>::3 rather than <prefix>:ec47:87af:c904:98d7:de0b.

If you refuse to pick a memorable address and refuse to use the tool which is designed to let you handle unmemorable addresses, then you don't get to complain about how hard your addresses are to remember.


This. If you look at my domain name (no nasty things, please):

    $ drill AAAA mayeul.net
    ;; ANSWER SECTION:
    mayeul.net. 900 IN AAAA 2a01:cb14:cce:1200::11
This isn't really hard to remember: I have the same prefix on the other computers on that network. Then 2a01:c000::/19 is my ISP's prefix [1]. The only part I picked was the :11, which is similar to the local IPv4 address I use on the same machine (10.12.186.11). I don't know the prefix by heart, but then I also get the v4 one wrong. I can get back the prefix from a DNS query most of the time, though. And I could create dummy subdomains to remember more address prefixes, if ever needed.

If you need an IP address in multiple places on the same host, it would be better to use /etc/hosts anyways, or use a DNS server, as it makes changing configuration way easier.

I've been playing around with the idea of giving each of my services a dedicated IPv6, so that I can seamlessly switch them from one machine to another.

The very nice part is that I get more IP addresses than I will ever need. Probably. Unless I am into nanobots. I could take an IP address and reroute it over a tunnel, or even assign an address block the size of the whole IPv4 internet and make my server tunnel that to the right target. Waste IP addresses ranges just to get a convenient prefix (::f00d:7ea ::f00d:cafe for the teapot & coffee machine, for instance, or ::1:???? for pro stuff and ::6666:??? for personal things. I don't know). There are so many possibilities, I'm barely scratching the surface.

Now, a couple minor complains I have:

- I don't have IPv6 at work

- My ISP doesn't have IPv6-enabled DNS

- My ISP-provided router sometimes reset IPv6 firewall rules, which is annoying.

[1]: https://www.ultratools.com/tools/ipv6InfoResult?ipAddress=2a...


> This isn't really hard to remember:

cmon, how many bits of information are there in your example vs remembering the last three digits of 192.168.1.xxx.


Like, ~4 bits? It's the last two digits in 2a01:cb14:cce:1200::xx.

Compare these two:

  2a01:cb14:cce:1200::xx
  203.0.113.42+192.168.1.xxx
Which is shorter? It's not the pair of v4 addresses.


where does this comparison come from ? currently I only have to know 192.168.1.xxx


If I were not to use a DNS, I would have to know by heart my IPv4 address (32 bits) to SSH on the router, then hop on the right host (32 bits local address). I guess you could shorten that to 32+8 if you were to use a super common prefix, but I tend not to do that to facilitate routing when bridging networks with a VPN, so it is more like +32 or +24 (10.x.x.x instead of 192.168.x.x).

The full address I wrote above is 72 to 80 bits, depending on how you count (if the ::11 counts as 8 or 16). So that's more, but not much. And The common part is always 32 bit more than the common ipv4 part.

An easier alternative to hoping on the router would be to assign a port to each computer behind the NAT. That makes 32bit for the IPv4, and 16 for the port. Contrast 64+16 in my IPv6 case (I actually have a /56, but that's no help for remembering it). 1 computer on the network means that you have to know 66% more bits with IPv6. Bump that to 10, and it's just 16%. This is because there is always a common part, and that common part is two times the length with IPv6, so that makes it a constant offset.

When configuring a network, I typically do not know the prefix by heart, so I make sure to have that written on a paper sheet that I take with me.

Plot twist: I do not know my IPv4 by heart. I actually know the IPv6 one better, as I have a dynamic IPv4 at home. And I intensively use DNS/mdns. IPv6 actually makes it easier to use DNS for local network machines, I think, as I feel it is more worth it to fill the DNS entries with it, in case I want to later open some ports in the firewall for the www to access.


It's the full addressing of the host... but you're right, I guess it was a bit of a non-sequitor. The only parts you have to actually know are the xx/xxx, which is roughly the same amount of bits. They could even both be, say, "42", so you're remembering the same thing for both.


Why not? I've been running internal DNS for almost 25 years. Setting up BIND, even in 1995, wasn't rocket science. If it's too complex, try dnsmasq.


but I don't want to run anything, just look on my modem's page (and have something simple enough that I won't need to look it up every time)


Almost every single web service in existence works or would work fine on a single server. We don't all need the cloud.


We are not going into the cloud for this reason.

We go into the cloud because the cloud provided you infrastructure as a service which is a huge benefit for small and big companies.


Yeah, but to set up an AAAA record, you still need the IP address. The usability still leaves something to be desired. At least we should never run out of IPv6 addresses.


> At least we should never run out of IPv6 addresses.

This is true in terms of the raw total number of IPv6 addresses.

Everything I've seen discussing them assumes they'll be assigned hierarchically, though, which is a great way to ensure most of them are never used. Block assignments through a hierarchy can chew through any number of addresses no matter how big the space is.


As said by others, you need hierarchy to avoid routing tables becoming excessively large-- that's the real limit.

Since an IPv6 subnet can hold effectively any number of hosts, and it's easier to give bigger chunks of networks, the chances that a given org needs multiple assignments is much lower. In turn we use that real limit (routing table size) more responsibly.

If routing tables can be much bigger in the future, we also have a whole lot more room to grow / allocate it differently. The chunk from which allocation is occurring (2000/3, plus the multicast and link local blocks, etc) is less than 1/4th the space; furthermore, more than half of the space within this is reserved.

https://www.iana.org/assignments/ipv6-unicast-address-assign...


Heirarchical assignment allows route summarisation. Imagine how much TCAM you'd need for unsummarized IPv6.


Yes, you're correct.

But at the same time hierarchical assignment allows organization, including route summarization, it undermines the argument that there are too many addresses to exhaust. Addresses can easily be (in fact, are guaranteed to be) exhausted by the organizational system without ever being in use. The goals are in conflict.


They are being used -- for the purpose of allowing the internet to scale.

But yes, we do need to be careful not to assign blocks that are too large. We're doing a good job of this (see any /8s being assigned?). We're also doing allocations only from 2000::/3, and there are five more completely untouched /3s available, so if we do somehow run out of space in 2000::/3 then we can start over with tighter allocation polices... five times over.


If you're setting up a AAAA once, you can deal with the copy paste. If you're updating them a lot, or a lot all at once, you should probably use a dynamic DNS updater.


> cut-and-paste repeatedly as needed

Pretty much this, though with IPv4 as I don't trust myself to remember that either.

I find myself increasingly frustrated with tools which force GUI flows or context switches that require me to do that, though. I prefer a 'edit a bunch of flat files in repos, push, magic config engine makes it happen' flow.

It's quicker for me to copy-paste than it is to type even an IPv4.


This, exactly.

I've spent way more time troubleshooting various obscure network problems that ended up being a typo in IP address/port number, than I'd be proud to admit.


Right. When I do "remember" an IPv4 it's usually that I've committed a /24 to long-term through repeated exposure, and then I really just have the 8 bits in short term memory.


You remember the prefixes (e.g. 1234:5:6:7::/48) you care most about and the hexadecimal nature of the address makes them fairly memorable and compact. You can prefix addresses with a-f to hint at usage and even spell words. Unused octets can be omitted thanks to the nature of the ::.


Yes, this is important to remember.

While automatically assigned IPv6 addresses will usually use the full 128 bits (last half is random), manually assigned addresses usually don't. So e.g. one of my servers is 2a00:1234:8::10, which is pretty easy to remember. There's going to be no way around memorizing the first two or three colon sections, which are assigned to you, but the last part is going to be as easy to remember as you make it.

2600::1, owned by sprint, which is the shortest pingable IP address I know, is exactly as long as 1.1.1.1, the shortest possible IPv4 address.


I raise you ...

$ ping 1.1 PING 1.1 (1.0.0.1) 56(84) bytes of data. 64 bytes from 1.0.0.1: icmp_seq=1 ttl=56 time=26.0 ms ...


I raise you ...

    $ ping 0
    PING 0 (127.0.0.1) 56(84) bytes of data.
Note that this may default to 0.0.0.0 instead depending on what you're running, which is technically the correct interpretation. I'm not sure who is doing the shenanigans here.


Touche!

All zeros is self, which is to say generally the same as 127.1.


Neat, I didn't know about this. If we relax the restrictions on being publicly routed, I can raise you

    $ ping ::
    PING ::(::) 56 data bytes
    64 bytes from ::1: icmp_seq=1 ttl=64 time=0.071 ms
though, shorter by one character.


People aren't having trouble remembering because they're not doing it right, they're having trouble because it wasn't designed right. And by "right", I mean designed for the average human to remember.


It's designed to go into DNS, so that computers can handle the remembering. This is the right design for the average human.

It's also designed so that the IPs themselves don't need to be particularly hard to remember. Compare 2001:db8:42:1::5 to 203.0.113.42+192.168.1.5 -- the v6 address is shorter than the pair of addresses you inevitably end up with in v4. If you're one of the tiny percentage of humans that actually do need to remember a v6 address, then pick an address like that rather than something long and hard to remember.


This is exactly how I do it. Not sure why you’re downvoted.


autoconfig, DHCP, DNS, cut & paste, and pen/paper all work fine, depending on the reason you need to move the address.

I doubt there is much discussion because there isn't really a way around it. The world is full of situations (MAC addresses, VIN numbers, software serial numbers, content hashes, UUIDs, etc, etc, etc) where a global address space doesn't fit in Human short term memory.

Computers are pretty good at remembering numbers for us, that would be my first choice.


Non-memorability is an annoying problem for IPv6.

The IP internet seems to depend on some degree of manual configuration, which requires identifying numerical IP addresses.

It's puzzling that the IETF hasn't recommended a human-memorable, word-based scheme for prefixes, something like what3words for IPv6.


Here is one project to represent them as haiku: https://gabrielbrady.com/projects/hipku/

We could also use syllabic encoding; for example, using 'bdfghjklmnprstvz' * 'aeio', we could encode 12 octet prefix

60:51:80:66:55:83:66:dc:56:fb:14:d1 as

ka-dediba-keneji-bokere-sejizi-sehohe

Which is somewhat easier to read and retype.


> Here is one project to represent them as haiku: https://gabrielbrady.com/projects/hipku/

Cute idea, although somehow in my opinion the IPv4 haikus tend to sound better than those representing IPv6 addresses.


Wow, like mnemonic encoder. Imma try something real quick...


It’s really not that bad. You remember your prefix and then manually assign in your /64. The address space is so sparse the first part is easy to remember - so really we are talking about 24-32 bits hexadecimal here.


The only hard thing to remember in ipv6 is the prefix that my ISP gives me, but it's mostly irrelevant. My DHCP6 gives out a range of ::0550:0000 to ::0550:ffff, I chose 0550 randomly, and I use a dynamic DNS updater to keep my hostnames up to date.

It's only marginally harder than ipv4.


The real problem is that they're just such big addresses.

We could totally just rerepresent v6 addresses as 4 sets of 4 octets, but that's basically remembering 4 ipv4 addresses.

The hex approach used today is a pretty good compromise, but people haven't really regularly operated with hexadecimal digits as a daily representation for a couple decades. Between hex and a direct binary representation there aren't really a lot of standard representations. Even say 16 ASCII characters won't work since there are quite a few whitespace and nondisplayable characters in the set.


I was curious if anyone had tried encoding them in e.g. base64 and found this: https://tools.ietf.org/html/rfc1924

base85. Still 20 digits...Not much easier to remember. They are truly huge.


As bad of an idea as memorizing addresses is, they're only so big if you use all of the bits. If you manually assign addresses, most of the bits will be zeroes or low numbers, which means you can just collapse them.

E.g. if you had a /32 and two dns servers, the second one might be reachable at 2400:123:d::2, which is exactly as long as say 143.239.132.2. And because you only get at most one octet to play with on v4, you can't easily make your addresses more memorable either.


When I work with v6 addresses, often only the last two bytes change from one address to the next, so I copy&paste the common prefix, and just work on the last two bytes.

If that's not the case, always copy&paste.


No one has yet mentioned but some people have built special keypads for inputting hexadecimal addresses. I remember seeing a patent a number of years ago for an "IPv6 keyboard". Not sure if he ever tried to mass produce it. A web search shows one website is selling something called an "IPv6 Buddy". Perhaps it is the same person, but I doubt it.


Absolutely agree! Also I think many of us have so many systems that either can't / won't support IPV6 that it is just way too much hassle vs private addreses & a NAT gateway!


In Xfce there is a clip-manager plugin. So, when dealing with dozens of IPv6, all are magically on this easy to get to panel. And I only focus on the last four chairs. I never type them.


We autoscale our stuff. I need a /28 for one kubernetes cluster of 1-300 nodes and 1-4 ils for ingress.

The ipv4 shortige definitely had a huge impact on those designs.


Get a utility for cut/paste that allows multiple choices? For windows, they are called "clipboard managers".


> What do people do with v6?

I write them down.


We use DNS... Its been around about as long as IPv4


This isn't a great solution. Every IT person knows "its always DNS," and you have to set up IP stuff to bring up DNS in general. DNS is brittle and doesn't deal well with multiple network domains or debugging if the network is down, and those are precisely the situations where one finds oneself typing IPs.

I really think the size of the IPs is a major cause of slow V6 uptake.


Size in which regard though? They're hexadecimals. If they were numbers or letters (0-9, a-z instead of 0-0, a-f) the number of bits would be still high, but with lower amount of characters. You might loose something beautiful as autoconfig but who needs a /64 for one device anyway? Plus, it does not work well for anonymity. You might as well randomize it.


DNS doesn’t help when you’re having to manually enter an IP into a config, which is what the OP implied.


My experience is contrary:

Put the “interesting” addresses in DNS immediately upon acquiring/configuring them.

When you need a literal - lookup DNS name, copy-paste from one terminal into the other. I do this for both Ipv4 and Ipv6 addresses.

Turns out the human brain sometimes does also have difficulty figuring the differences between 192.168.129.1 and 192.186.130.1 when one of them is mistyped....


You still need to put that ip address manually into a few places to have that setup (dns, static ip settings, possibly router settings, etc.)


If an application supports IPv6, it should support DNS. If it doesn’t support DNS, that feels like a bug.

The only configuration item that should require manual entry of an IPv6 address is a NIC. Even that has other mechanisms. Everything else should support DNS.

Edit: doh, the second place is the dns zone file


Again, to me the OP is talking explicitly about places where you have to enter it in. What are the other mechanisms? Let’s forget about situations where you can copy/paste or use DHCP.

My answer would be to use my phone to take a photo of the address (if not easily accessible via web browser), and then use that to manually enter it. Probably not a situation where you can rely on memory, unfortunately.


Outside of the NIC and DNS, where else do you need to enter in an IP literal?


Firewalls, for example. We have huge files containing risk levels for various IP addresses. Most of it is automated, but sometimes we have to tweak something manually. These aren't IP addresses that we control, so DNS isn't helpful. Often we're dealing with ranges as well, for which DNS is also unhelpful.


Technically, you could claim you're authoritative, just hope the assignments don't leak ;-)


Connecting to things on your local network


Dns resolver Internal IPs


So you gotta log into your registrar and copy paste your IPv6 address and wait god knows how long for it to propagate...


DNS doesn't actually "propagate", all you're waiting for is the caches to expire, and you can control that by keeping a low TTL on the record.


Or you can host your own dns. Or you can get a decent dns host. It doesn’t need to be your domain registrar, much like you don’t need your website or email hosted with your domain registrar.


Yeah, but what about ephemeral DNS for your LAN? Zeroconf and NetBIOS work but can be harder to set up than IPv4 (especially if your install media doesn't have it set up by default).


AFRINIC has a number of available IPv4 free, across multiple /8s: https://www.afrinic.net/stats/ipv4-pool

APNIC has "0.32" of a /8 left: https://www.apnic.net/community/ipv4-exhaustion/graphical-in...

ARIN reached zero on Sept 24, 2015: https://www.arin.net/resources/guide/ipv4/


Public service:

LACNIC has 0.09 of a /8 left: https://www.lacnic.net/1039/2/lacnic/ipv4-depletion-phases#t...


Can you easily get a free /24 from AFRINIC?

What kind of presence do you need? I will soon have to do a small CDN with a POP in ZA. I might as well get the IPv4 from AFRINIC if they have plenty.


You need to have a business presence in Africa, not just a network presence.

Cloudflare abused this long ago by creating a subsidiary on paper in Seychelles just to get as many IPs as possible, while doing no business there.


I have been hearing this end-of-the-IPv4 world chatter for 10+ years now. While I understand it is a real problem, I wonder if we’ll still be talking about it in the present tense 10 years from now.


The internet can continue operating and growing without IPv6; it just won't be pretty. More and more endpoints will have to share a single IPv4 address; that's possible, but it can cause a variety of problems. I'm not really qualified to assess their severity on such large scales, but similar scenarios are known for being problematic at small scales.

It might seem like it makes more sense to switch to IPv6 than to deal with the issues of IPv4, but the entities that have to deal with problems that result from IPv4 depletion usually aren't the same entities impeding the adoption of IPv6.


Two big reasons that Microsoft says have caused them to start pushing v6 adoption internally from around 2017 are:

a) struggling to implement proper IP based access control with their available address space.

b) as everyone uses the same 16 or so bits of Private IPv4 space, every acquisition likely causes new IPv4 address space collisions which must be worked around.


> b) as everyone uses the same 16 or so bits of Private IPv4 space, every acquisition likely causes new IPv4 address space collisions which must be worked around.

I mostly agree, but this overstates thing some. 10/8 offers 24 bits, 192.168 offers 16 bits, and 172.16-172.31 offers 20 bits.

The latter are particularly frequently unused; if you pick one of 172.20-172.28 to cram into you have a high chance of not crashing into someone else when you integrate networks. Particularly if you use the upper half of the resultant class b.

Of course RFC 4193 for IPv6 is very nice; pick your own random 40 bit prefix, and get to run 65536 subnets of arbitrary size. You need to integrate ~2^20-- a million-- networks before you have a 50% chance of having encountered a collision.


> 172.16-172.31 are particularly frequently unused

haha, I wish. We decided to use them two decades ago exactly because we thought they were less frequently used, but then a decade later docker comes along and uses exactly that as a default NAT subnet. So we get multiple tickets about that a week.


What kind of issues is this causing you / your users?


Well, the complaint usually goes like this:

"we recently set up service x, and it seems to be working fine. However, when we try to connect from the campus wifi, or a certain department, the service does not respond".

What happens is the server gets a request from a private IP within the range assigned to docker0, and then the container replies, but because the IP is believed to be local, linux correctly tries to find something attached to the docker0 interface with that IP and fails.


And this (continued) idea is called local - Or subnet in cloudspeak. You can have thousands of distinct hosts which are then routed to the internet through a balancer. Frankly, it may have been a more efficient network then everyone having their own 10 IPv6 addresses.


It's like "peak oil." They keep saying we'll run out, but if we keep drilling or fracking, we keep finding more.


IPv4 addresses are more like land than oil. We're never going to find any more, but they aren't consumed, and existing ones can be traded.

IPv6 lets us build in the sky, where space is no longer a constraint.


I'm patiently waiting for the day where someone tries to block usage of IPv4 addresses to increase the value of their own, much in the same way is done with actual land today.


There are no more, but there are a lot wasted. In the early days when it was assumed everything would be publicly accessible, large organizations were given class A's or more.


Not as much as you think. There are only about 20 /8s owned by companies (and those companies are using those /8s for their networks!).

Before IANA runout in 2011 we were going through one /8 every month; given that demand has only gone up since then, 20 /8s would be, what, a 12 month supply or so? v4 is just too small, and no amount of pushing allocations around is going to change that.


While the addresses are largely in use (though I'd wager ham radio operators aren't using much of 44/8), are they really necessary?

Does the UK Ministry of Defense actually have 16 million devices that need publicly routable addresses? Or could they be doing what almost everyone else is doing and using a handful of publicly routable addresses and private IP ranges behind them?


No, of course they're not necessary. They could turn off all their computers and then they wouldn't need any address space at all. But there are benefits to having networked computers, and there are benefits to doing that networking correctly and not paying the costs of NAT and overlapped address space.

It would take them years to renumber off of their /8, at great cost and with the result of an increased ongoing operational cost, and for what benefit? That /8 would last the public internet for less than a month. It's not like the people who are yet to deploy v6 are suffering a lack of time, so buying them an extra month which they would then squander isn't going to be very helpful.


Classless networking used to not exist and a lot of universities being early adopters and some companies ended up with with class B's at least. Anyone in the US(who isn't one of the said universities) likely already had the address range taken back due to noteworthy underutilization though. We lost two class C's a few years ago due to this reason but it was hard to complain about since we weren't really using them.


There's a lot of wasted land too (e.g. single-story buildings in the Bay Area.)

In any case, many of those "wasted" /8s have been resold for $100M+ in the last decade. Grep this page for "formerly" https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...


That's a great analogy. Like peak oil, we've passed the point of exhausting the cheap, plentiful reserves. Now we're scrounging for harder-to-get, scarcer deposits which means that the prices of both will go up, inevitably.

No, we're not out of oil or IPv4 addresses. It's just getting a lot harder to come by either one, and the writing's on the wall that the invisible hand is able to slap us silly if we don't seriously start migrating to the replacements ASAP.


I distinctly remembering hearing about it in the late 1990s during my university years (chatter among the computer lab staff). It’s amazing how long it’s dragged on.


One company is running out of addresses this time


It's not just a "company". Someone has to decide who's in charge of which IP addresses. IANA is the overarching authority; they then delegates large swaths of IP addresses to regional organizations. RIPE is in charge of Europe.

It would be more accurate to say one continent has run out of IPv4 addresses, but even that isn't entirely accurate. As IPv4 addresses have become scarcer and scarcer, it's become common for companies to obtain IP addresses from registries other than the one that handles their region.

In other words: RIPE is in charge of assigning IP addresses. They're running out of IPv4 addresses to assign to other organizations. That's different from a single company running out of IPv4 addresses, which just means they need to buy more addresses (or find an alternative solution).


One _continent_. (Or 1.5, really; RIPE also handles a decent chunk of Asia).


We need a Wiki that documents all the problems of migrating from IPv4 to IPv6. Currently it's a scary, unknown process of bumbling into corner cases, which I think is the reason the vast majority of people haven't adopted it into their products. Why do something slow and complicated when you don't need to (yet)? By documenting it fully, it will seem easier, and more people will at least try to adopt IPv6.

One of the many things that would speed up adoption is "IPv6 by default". Often it's just a matter of turning on the "IPv6 thing" at the same time as the "IPv4 thing". We need IPv6 name servers added to DHCP leases. We need load balancers to expose IPv6 addresses. We need to provide an AAAA record at the same time as an A record. We need firewall rules for IPv6 at the same time we add one for IPv4. We need SLAAC or DHCPv6 enabled. And we need applications to natively support an "ip address" field that accepts both IPv4 and IPv6 format addresses.


> One of the many things that would speed up adoption is "IPv6 by default".

This is precisely why I end up searching for the knob to turn off IPv6 in kernel after installing a new system. That is, if I remember to do so. And then I curse because the system's (or application's) name resolver still keeps performing AAAA queries and breaking because IPv6 doesn't actually work.

Recent example: https://bugzilla.mozilla.org/show_bug.cgi?id=1582686

Please don't enable anything by default unless it's actually working.


This just isn't how dual stacks that are only able to obtain an IPv4 address work.

For DNS, if your device decides to perform a AAAA lookup (despite not having an IPv6 address), it would succeed just fine, even over an IPv4 connection. (You can query any record type over the DNS connection/protocol, regardless.)

If your device attempted to connect to the resulting address (I don't think most would, but let's assume) it would instantly fail, as there wouldn't be a route to that destination, and fall back to the next record — the A/IPv4 record.

There are literally millions of dual stack laptops, phones, tablets, etc. all out there on backwater residential ISP networks that have no idea what IPv6 is. If dual stack didn't work — it'd be a real bug that would have long since been fixed. Similarly, if a dual-stack device had issues transitioning between dual-stack networks and IPv4 networks, we'd also know, as many phones and laptops do this all day. (E.g., my home network was dual-stack, but my work is not. Laptops — and using multiple OSes, too — moving between those networks can auto-configure themselves appropriately.)

Like other posters are telling you: if you have a device that has issues when IPv6 is enabled, you have some sort of localized issue with your network setup.


https://www.google.com/intl/en/ipv6/statistics.html

One third of traffic into Google comes from IPv6 sources. And they work fine.

When major ISPs around the world are enabling for both their fixed and mobile customers and not getting issues.

The problem is either in your ISP, your network or client configuration.


I'm actually very surprised that Germany seems to be one of the top countries for IPv6 adoption with 44% in these statistics. How did that happen, the internet infrastructure here always seems to be in a very bad shape.


it started more than 10 years ago. My hunch is on a mutual undestanding between major providers and some maturity of the equipment that supports IPv6.

googling "what is my IP" from Telekom or MNet results in a IPv6. Virtually all routers support this by default.

Unfortunatelly, mobile/4G is still on IPv4. Can't really explain it.


> The problem is either in your ISP, your network or client configuration.

Thank you for telling me that it's broken. That's kinda my point.

Again, I don't have IPv6 connectivity to the world, at all.

Random applications trying to enable and use it per default is bound to fail.


You linked to a bug in Firefox Nightly. That's hardly indicative of there being widespread issues.

Also that bug seems to occur when IPv6 is disabled in the kernel.

Random applications should be fine with trying the IPv6 address, and if it fails using the IPv4 address.

That should happen transparently. There are millions of Linux deployments that don't require manually disabling IPv6.

You not having an IPv6 address is a separate issue.


If you don't have v6 connectivity, then by default DNS lookups will be sorted so that v4 addresses are first. I don't know what went wrong in your case, but I don't think it had anything to do with IPv6.

`getent hosts` returns v6 addresses (only, no v4) if any exist on the hostname you give it, and thus its output is useless for debugging here. You need to check `getent ahosts <hostname>`, which uses the same getaddrinfo() call that most software (including Firefox) uses for DNS lookup. If you have no v6 connectivity then the v4 addresses should be sorted first in the output of that, and v4 will be tried first by your software. Another good test is `wget <url>` which prints the IPs in sorted order (limited to the first 3 though), tries to connect to them one by one and prints any errors it encounters.

If `getent ahosts` is showing v6 addresses sorted first, I'd be happy to take a look at your config -- if you pastebin the output of `ifconfig` and /etc/gai.conf then I should be able to tell you what's up. Either you'll have a v6 address you didn't notice or you've somehow configured your system to sort them first even when you only have v4.

For some reason, there's a "I saw a colon somewhere, therefore it's IPv6's fault" trap that people keep falling into. Your posts look like an example of that.


Can you explain what exactly is the behavior when you forget to disable IPv6 on a new install?

My ISP offers IPv4 only. I've used Windows, various flavors of Linux, macOS, iOS, FreeBSD, Playstation 4, Apple TV, and Android, and they have all "just worked" flawlessly without me ever having to manually tune anything. I'm curious what issues you are running into.


> Please don't enable anything by default unless it's actually working

Then again, we know news of v4 running out and v6 being the only usable replacement has been running for .. 20 years?

If people start _now_ and test what v6 means, then we get what we deserve. Not pointing only to you, but equally the server ends mentioned in this thread also.

IANA released its last allocations 8 years ago, how much more forewarning do people need in order to actually move their butts?

If you get v6 issues today, it is only because people put their heads in the sand and decided "hey, I have this one machine with a v4 on which I can serve data, I don't need to worry about this issue ever".

Having to fiddle with do-or-do-not-resolve-v6 to make stuff work is something we should have spent time on in 2003 or so.


> IANA released its last allocations 8 years ago, how much more forewarning do people need in order to actually move their butts?

IPv6 feels like the tech version of climate change. Requires too many to do too much with no or negative short-term payout.


The payout is not negative. ISPs, especially mobile ones, are rewarded for turning on IPv6 because IPv4 addresses are expensive and CGNAT causes a host of issues for customers.


> Having to fiddle with do-or-do-not-resolve-v6 to make stuff work is something we should have spent time on in 2003 or so.

Agree. The difficulty is that the internet is big and has too many actors, so it's impossible to get everyone on board to plan the roll out.

So the next option of just chaotically enabling things here and there without carefully designed fallbacks or coordination in the larger ecosystem is causing precisely the issues that make people scream and look for the switch to turn it all off.

It's pretty crazy if you think. I don't think anyone's deploying large production systems with so little coordination and so much random switch flipping by different unrelated (but nevertheless interconnected and interdependent) parties. I can't imagine why the largest big system on planet earth would just work if people do that.


There's no way to know for sure if it works unless we start enabling it and look for these weird edge cases. We should be fixing the bugs we find during this process. That's why IPv6 adoption is painful, and why I think documentation would help a lot.

Check if you have options inet6 set in your /etc/resolv.conf, and remove the option if you do. You can also try setting options single-request and options single-request-reopen. Note that the latter two violate the "don't enable it if it's not working" principle; broken middleboxes are screwing with your client, so if these middleboxes were never fixed, we could never use IPv6. Instead we have shitty workarounds. Sometimes that's just the best option available.


I recently decided on a whim to try an IPv6-only VPS which was something like 70% off at my provider. It being for internal stuff only, I thought it shouldn't be too much of a problem.

As it turns out, not even the Ubuntu repositories are reachable over IPv6.

I believe this was the PPA server, which held some package I needed for some workaround for all the other connectivity problems.

So let's hope a few important people/companies/institutions start to be slightly inconvenienced. I bet as soon as this rises to the concern of, say, some peoples' Netflix stream stuttering it's a matter of weeks to solve it.


Looks like PPA.launchpad.net got IPv6 support 3 days ago haha:

https://bugs.launchpad.net/launchpad/+bug/776040


Ubuntu's ppa domain - ppa.launchpad.net - and the domain their normal repos are hosted on - archive.ubuntu.com and security.ubuntu.com support IPv6. You can test it with this tool: https://ipv6-test.com/validate.php

It's common for hosting providers to modify system images to point at a nearer mirror or even a local one they own. Perhaps it wasn't working on your system because of some change you or the host made.


This should not usually really be a problem. IPv6-only hosting should usually come with a NAT64 gateway, which allows you to seamlessly connect outwards to any ipv4-only hosts. If not, you can choose to use the ones provided by he.net or google.

I don't see any reason why, with incoming shared v4 http load balancers and outgoing NAT64, most standard http applications shouldn't be able to move to ipv6-only. We've been slowly turning off ipv4 for our load-balanced web apps with little issues so far.


I've already experienced some of this.. World of Warcraft had an issue a month or so ago whereby their servers got hit by an IPv4 only DDoS attack that prevented people from playing. My ISP had native IPv6 and I was unaffected as a result.


Forgive my naiveté - how does running out of IPV4 addresses result in Netflix stuttering? I'm viewing it a binary problem (you either have an IP and have internet, or you're fighting to get an IP and have no internet) but that seems incorrect.


Peering policies between networks are protocol dependent. You have ipv4 peering and you have ipv6 peering.

When your ipv4 peering sessions have problems, as that accounts for >90% of your traffic, you notice and you notice fast. If you don’t, your customers will notice for you.

When your ipv6 peering sessions have problems, you may not notice for days, weeks or even months.

Source: it took 3 months before the first customer complaint came in about the entire v6 network being down on a network otherwise passing over 1Tbps at peak daily.


I could imagine if your ISP has some big NAT plant that’s overloaded, it would cause connection problems with traffic getting congested at the NAT devices.


Not just raw bandwidth, but also NAT relies on session tracking, and the NAT device has a limited amount of memory and therefore sessions available. It's often a lot easier to augment bandwidth than to augment available sessions.


Makes sense, thanks :)


Finally. I can't wait for the outcome of this. We'll probably waste another couple of years with more NAT and other hacky short-term solutions, but in the long run adopting IPv6 is inevitable.


NAT destroys the end-to-end principle and encourages things like CGNAT, which make side-stepping centralized services impossible. I really hope IPv6 starts becoming commonplace and that the outcome isn't that CGNAT becomes the norm for residential Internet connections.


The best part about IPv6 is that it's now possible to SSH directly into your laptop if you're using a hotspot from T-Mobile US, for example — it gives you at least a whole /64, so, your laptop gets a fully-routable IPv6 address.

Which is kind of ironic, because you don't get that with most wireline connections, as they're all done through IPv4 NAT.


This is my favorite bit about native IPv6 at home [0]. No more port forwarding to expose particular services -- I can just `ssh desktop.home.net` or `ssh other.home.net`, and they both get to run on default ports! (Of course, one probably wants a firewall -- I block inbound IPv6 by default except ssh.)

[0] Comcast is surprisingly good here -- they'll give you a /60 (16 /64 networks) if you ask for it with the right DHCP option!


Yes, you probably should have a firewall but the sheer size of IPv6 means that whereas I'll have several idiots banging their heads on my SSH services at any one time on IPv4 I'm not sure I've ever had one trying on IPv6 in the years that I've had service available on both public IPv4 and IPv6.

If you set a machine to try just one IP address per second in IPv4 you'll explore a significant fraction of the whole public address space per year. In IPv6 doing that is extremely unlikely to find even a single valid address to connect to in a human lifetime.


That was one of my motivations to try IPv6 at home, only to quickly get disappointed because my ISP gives me a new prefix change very often (in stark contrast to my IPv4 address for some reason).


I have this issue too, so I use Ddclient-curl to do dynamic dns via cloudflare.

DDNS is something that I once thought would be an artifact of a less civilized time, but ISPs gotta upsell, I guess.


Main problem for me is that my router doesn't update firewall rules when prefix changes, and I can't get it to not advertise its public ip for the DNS resolver running on the router which of course breaks when the prefix changes.


Hmm. I run pfsense, it advertises its own v6 address as a DNS resolver, and I've never had any issues with it breaking. Admittedly, I don't know it isn't just falling back to v4 for a period when the prefix changes. But I did just check and my PC is getting the correct v6 addr of my router as DNS resolver.


> Admittedly, I don't know it isn't just falling back to v4 for a period when the prefix changes.

At the very least, IPv4 fallback takes a few seconds for each DNS query, and I've experienced it failing completely in some cases (can't recall if I ever figured out why). So regardless it's a PITA when it happens.

I tried disabling the option for it to advertise itself as a DNS and instead insert the local IPv4 address in the DHCP options but to no avail, clients still ended up with public IPv6 as main DNS.

After a few hours of trying to fix it I just turned off IPv6 again.


> [0] Comcast is surprisingly good here -- they'll give you a /60 (16 /64 networks) if you ask for it with the right DHCP option!

Can you go into more detail or point me to instructions? I'm on Comcast and would be interested in getting v6 at home.


Sure! The keyword to look for is "DHCP-PD" (DHCP prefix delegation).

I run a little OpenBSD router and my dhcpcd.conf is here [1], but I've done this before on a Linux router box too -- here are some instructions from Arch's wiki [2]. IIRC, the stock firmware on my old consumer router was also able to request a prefix and advertise it on the network.

[1] https://gist.github.com/cfallin/e5865a6a93c75ace8d26d6a85287... [2] https://wiki.archlinux.org/index.php/IPv6#Prefix_delegation_...


I want to study about the technologies around this part of networking, prefix delegation, radvd, etc. Any materials you can recommend?


Hagen's _IPv6 Essentials_ covers the basics, Coffeen's _IPv6 Address Planning_ shows the amazing things you can do with IPv6.


I think Comcast is native dual stack across their entire footprint so long as you have new enough hardware


This may be a dumb question, but why does one need with a /60 ? Isn't a /64 already ridiculously huge to the point that I could never possibly use it all?


IETF recommend a /64 as the smallest subnet size to use, as stateless auto address configuration (SLAAC) only works with that subnet size.

Any user that wants more than a single subnet at home is supposed to receive a /48 by the same recommendation base. A lot of ISPs settled on /56s. Comcast is a bit more stingy than some.

That introduces a whole other set of problems.


The RIPE guidelines at [0] line up with what I've heard as justification before: basically, /64 is the smallest you can go without lots of manual configuration (the way that SLAAC auto-assigns addresses from Ethernet MACs or random bytes only works when the host part of the address is 64 bits). There may be valid technical reasons to want > 1 subnet at a customer site.

And finally, the space is huge -- an ISP would typically get a /32 at least (Whois says that Comcast is using a /26 just for the Bay area), so if every customer gets a /60, that's 2^28, or 256M, delegations. (With the /26, Comcast could hand out 16 billion /60 delegations to their SFBA subscribers.)

[0] https://www.ripe.net/publications/docs/ripe-690#4--size-of-e...


Not a dumb question at all! The smallest IPv6 subnet is /64, so a /60 lets you split your network into multiple subnets without all the software that assumes a subnet is /64 (like address autoconfig) breaking. Why might you need multiple subnets? Lots of reasons, common ones are for security. It lets you do things like split up a home office network from home from guest wifi from IoT/home automation. Also allows new services to be created that use that capability.


I only need a /100. More internet addresses than Europe has in IPv4. I can statically assign devices their own individual addresses.


Not with that attitude.


Do you also have an IPv4 address that you can use for NAT for those things that cant use IPv6? (Also do you have devices that aren't capable of using IPv6?)


Yes, I have native IPv4 too, with the usual NAT. I think the default router that Comcast will rent to you actually is dualstack in this way too -- IPv4 NAT, and IPv6 prefix advertised for devices that want it.

I actually played with NAT64 for a bit (IPv6-only internally, all IPv4 space is mapped to a special /96 in IPv6-space and NAT'd at the router, and local DNS server on the router returns translated AAAA records for IPv4-only hosts), but dropped that when I simplified my router config. It works, it just takes a bit of config :-)


Theoretically, yes.

Practically, my laptop is in some Wifi network and has an IPv6 address, but that isn't accessible from the outside because the Wifi/router box blocks incoming connection. That is a wise decision overall, but unforunately replaces the "can't connect because NAT" by "glorious IPv6, bit still can't connect".

And I'm not the owner of those boxes.


It depends.™

I've had a static IPv4 subnet allocation from AT&T on AT&T U-verse, and tried using it on a couple of consumer routers for the local network. Well, guess what — all these devices from major brands that are called "routers" don't actually route between the interfaces, after all — all they did was NAT between my public IPv4 allocation and the main IPv4 address assigned by DHCP. And disabling the NAT simply disconnected the networks — instead of rounting one interface to the other. I actually opened up a support ticket with ZyXEL, which got escalated to their engineering managers, and they did confirm my finding that their routers had a bug in sysctl settings that stops them from routing the interfaces (e.g., sysctl net.ipv4.ip_forward not set to 1).

Anyhow, back to T-Mobile US IPv6 on a hotspot — when I originally tried ssh'ing back to my own box via the public IPv6, things didn't work, either; but I then found out that it was some sort of a local policy on the local machine, because another laptop without a firewall was able to receive connections on IPv6 from the internet without any issues.


Were they all just selling NAT-ing bridges instead of routers? This is a serious fraud.


Was the former more secure? Most people don’t want their laptop exposed with a fully routable address.


NAT is not a security measure. You want a firewall regardless of whether you’re running IPv4 or IPv6


That's why you have firewalls. You're already often exposed to all the other users in your coffee shop anyways.

SSH is normally not enabled, either.


What do you do for something like printers? I highly doubt Epson's "firewall" is totally secure.


Your home has a gateway router.

You can configure firewall rules on that.

In fact, the default is almost always to disallow all inbound and allow all outbound.


IMO, the "right" answer is that printers go on their own subnet. Access control is managed on their default gateway.


If you are on Ubuntu, you can run

sudo ufw default deny incoming

and your laptop is now secure.


> NAT destroys the end-to-end principle

Yes, and that precisely why I use it in my home network, and will continue to use is with IPv6. I explicitly don't want any IP addresses in my green zone to be directly accessibly from my red zone.


Then you're doing something very wrong. You can't rely on NAT to stop connections, because that's not a thing NAT does.

You need to be using a firewall. NAT is just an extra, useless, complicated and unnecessary thing to be adding to the top of that; one that makes it hard to understand how your network is even working, and which makes it harder rather than easier to secure.


> You need to be using a firewall.

Indeed, I never said otherwise.

What I'm saying is that I want to disallow all incoming connections to any machine that isn't in my yellow zone, and selectively forward some traffic to servers in my green zone. I can absolutely use router and firewall rules to accomplish that. But when I do, I've essentially implemented a NAT.


Can you explain how an outside person (other than my ISP) can make an outside connection to my laptop despite being behind a NAT? Assuming for concreteness that my laptop's internal (NATted) address is 192.168.1.123 and my router's public address is 123.45.67.89. What sequence of commands would you type to open a TCP connection to my laptop?


NAT is implemented on a firewall, the blocking of incoming connections is a side effect and isn't even intentional (that's why UPnP exists).

Since you already have a firewall you can just add a single rule that block incoming connections and that's all you actually need.


You are right that it would be hard to open a TCP connection with you on a specific target port on a 1:N NAT without UPnP. If you could, IPv4 exhaustion would not be an issue.

However, NAT is just a mapping from an internal IP to an external Port number. With pure NAT, once you have created a connection to the outside, anyone can send packets to that external port, and have them delivered to your device.

Of course, this mapping is inherently lossy. You are mapping the port space of one device onto N devices. This does mean external IPs can only send your devices packets on ports they have previously used as source ports, but you are still not safe. You might own devices that, for example, have vulnerabilities in their networking stack. Not that rare. You also might not want to disclose the number of devices active in a network, allow them to be fingerprinted by their response, or similar. Some UDP client applications might also not check the IP addresses of incoming packets. UDP server applications also commonly use the same socket for connections to other hosts as it listens on.

So, to elaborate on that last example, you might run, say, a video surveillance server. It might listen for RTP on UDP port 12345. It then uses that same socket to send a UDP packet to licensecheck.example.com. That packet will have a source port of 12345. NAT will then map internal_ip:12345 to external_ip:xyz. Anyone can now view your cameras on external_ip:xyz.

So either way, you'll want a stateful firewall. Deny incoming, allow outgoing. That's what firewalls are there for, and that's what gives you your security, NAT or no NAT.


If you have routing to the IP, then it's just a matter of:

  $ telnet <ip> <port>
If you don't have routing, then you'll need to arrange it somehow. With the example addresses you gave, you could do it by being on your immediate upstream network and then running:

  $ ip route add 192.168.1.123/24 via 123.45.67.89
  $ telnet 192.168.1.123 <port>


Then you want a firewall whether or not you’re NATing. NAT is not a security measure. It offers you no blocking of incoming traffic. It has no inherent security value.


How does NAT not block incoming traffic? I'm genuinely confused. Let's assume my laptop is behind a typical home network NAT with public address 123.45.67.89 and internal address 192.168.1.123 . What sequence of commands do you type to send traffic to my laptop?


FWIW. Most video games that create peer meshes (and bittorrent) will “punch” the NAT. Even with the stateful firewall that is built in to most routers to prevent unestablished connections inbound.

Think of it like this. You need to go to the internet for something. Your NAT will just kludge the packet to make it look like it came from the NAT machine, altering the port and IP.

That port and IP combo needs to get back to your PC so the router keeps the mapping it used in a table and looks up all inbound packets to match on that table.

So if you have sent a packet, you’ve opened a random port.

NAT tries (lazily) to use the source port that matches the destination port. So if you ssh outbound; most NAT implementations will open port 22 to your machine.

But the stateful firewall that usually comes with your router will block random inbound connection attempts or packets from your destination that are not acknowledged.

Tbh, NAT+firewall doesn’t give you anything extra (security-wise) than a plain stateful firewall gives you.


First of all there are multiple kinds of NATs, such as SNAT, DNAT, PAT etc. You can for example have one IP being mapped to another IP statically without changing anything. That's the simplest kind of NAT (it is called SNAT) and doesn't do any blocking.

Most people when they say NAT they mean PAT, that solution translates basically takes an outbound connection, it allocates a port and maps that port to that local computer.

That creates an illusion, of security, but that's all as a side effect, NAT inherently doesn't care about security. There are multiple ways to bypass it, most known is UPnP where hosts can actually request to open an inbound port.

The correct way to block inbound traffic is actually to use firewall. If you have a statefull firewall (currently pretty much all of them are statefull) you basically block inbound traffic to your network and that's it.

UCLA has /16 address space and it doesn't use NAT it just gives static IP addresses to computers. By default all incoming communication is blocked, but you can submit request to have certain ports opened.

Also from my own experience, if you have network with multiple devices, and you want to do something more advanced like traffic shaping, NAT actually makes things much more complicated. You need to keep in mind if you're doing filtering before or after NAT is applied.

For example I had a person on my network catch a virus and started sending mail, which got my mail server blacklisted. So I decided to block outbound connections to port 25, forcing everyone to use local SMTP server. In PF the filtering rules apply after NAT, so at that point the user has the same IP as the server. To correctly filter I need to tag the connection when NAT happens and then perform filtering on tags. Without NAT I could simply just use source IP address to do the filtering. Things become even more complex when you also want to do QoS and label traffic.

To do NAT you do need firewall, and if you have a stateful firewall you can just do the filtering by firewall. NAT was never designed as a security feature and shouldn't be treated as one.


Most consumer NATs are completely permissive. Put a single device behind it, through some traffic at the NAT, and it will cheerfully forward it to the host despite the data not being correlated with any outbound packets.

With multiple hosts it’s going to depend on the implementation, but it will likely forward it to something it thinks can handle it, because most NATs try to be as transparent as they can, to not trip up unknowledgeable consumers.

NAT is not, and has never been a security measure. Just run a damn firewall if you want to drop incoming traffic. The firewall gives you everything you want; you aren’t gaining a damn thing from the NAT.


> How does NAT not block incoming traffic?

https://samy.pl/pwnat/

NAT != firewall


This seems to require both ends to be running the pwnat software.

Again, assuming I am not running any special software, what sequence of commands would you type to send a packet to 192.168.1.123 natted behind 123.45.67.89 ?


It's indeed true, if in your contrived case, you have a VM doing nothing inside a NAT behind a public IP, you couldn't access it.

https://tools.ietf.org/html/rfc2663 might bee a good start to see where flaws are and how it works. And it's also a great way to see how a destination machine that you're talking with can puncture through your NAT, cause you did already.

And Pwnat didn't strike you as "interesting" in that it could join 2 internal networks as if they were the same collision domain, but not really?


> I explicitly don't want any IP addresses in my green zone to be directly accessibly from my red zone.

This is exactly what the job of a firewall is.

NAT is a hack due to IP address exhaustion. Any security is a side effect. Nothing that says "NAT" on the tin is obligated to protect you.

NAT on your own network if you really drink that kool-aid is fine. I'm more concerned about CGNAT. If ISPs implement NAT (called CGNAT), it means you can't accept incoming connections without your ISP approving/supporting it. I don't want to have to beg my ISP to open ports for me and question/approve why I'm doing it.


> This is exactly what the job of a firewall is.

Well, I agree (if you include the router in that). I never asserted otherwise. In fact, this is how I've implemented my NAT.


I recommend a firewall in that case.

NAT itself would only be security-through-obscurity.


Is that actually true? How would outside traffic get through a NAT?


It doesn't have to get "through NAT", that's not how NAT works. NAT is an address remapping function that can be configured to happen for some particular packets and has nothing to do with the forwarding function/routing that is completely orthogonal to it. Typically, NAT on home routers would be configured to remap the source address of packets coming from the LAN interface destined to the WAN interface as well as any packets in the opposite direction that match flows that were remapped in the outbound direction.

If someone (your ISP, someone who compromised your ISP's router, someone who happens to be your neighbour on an ISP with misconfigured routers ...) sends a packets directly addressed to your internal address range to your WAN interface, that is of no interest to the NAT function and will simply be routed to the LAN interface unchanged.

That is: Unless the device happens to also have a stateful firewall that would prevent that. But then, the firewall would work just as well without NAT.


NAT is not a barrier for traffic, so question 'how traffic get through a NAT' does not make sense. Router by default forwards packets. NAT just means that in some cases it also translates src/dst addresses of packets.

If you have a router with NAT and without (stateful) firewall or RPF, and such router receives a packet on wan port with dst address from your private LAN range, then such packet is just passed to your LAN (as NAT does not apply here). Obviously, such packet is unroutable on general Internet, but could be send by our ISP or by other customers of your ISP if they are on the same network (e.g. wifi AP) as your wan port. There are also more sophisticated ways, like abusing automatic decapsulation of packets (if enabled). Fortunately, in most cases a router with NAT also has enabled stateful firewall, so this is moot.


> Obviously, such packet is unroutable on general Internet

You buried the lede here. This makes a huge difference. I am much more willing to trust my ISP (a major company who would be quickly found out if they were trying to hack random people) than the entire set of people on the global internet.


Outside traffic gets through a NAT all the time.

Including HN, moments before reading this page.

It's true that outside networks usually cannot send a TCP SYN to your local network without IP spoofing or other hackery.

But a firewall is sufficient; there is no need for network address translation.


From my vantage point, it is already. The only parties that don't have IPv6 are my employer (which I maybe need to nag about since we're an ISP and have our own AS), and the customer I'm dealing with.


So does RIPE automatically hand out a v6 block for every v4 one, and do the LIRs also, and is there a policy to also hand out zero added cost v6 blocks?

No? Oh, okay then.


If every engineer took the extra 10 minutes to enable IPv6 for their AWS services we would have a much better availability.

I believe it's less than 50 lines of Terraform code to enable it for the standard Application Load Balancer use case.


I have the opposite experience when it comes to availability.

I sell some software that runs on servers, and we used to get so many tickets that came down to the server's IPv6 transit being busted in sometimes obvious, sometimes subtle ways. And then we have to fight with their NOC to convince them something is broken.

IPv6 is an afterthought in many networks. There is less peering, less monitoring, less users overall to uncover issues.

It got so tedious to deal with that support burn that I just changed our software to not dual-stack any of its outgoing connections. Not heard a peep since.


Does the software runs well under heavy CGNAT? Because that is where we are going if everyone follows you.


The whole problem with ipv6 is that earlier adaptors have not much advantages (while still having to support ipv4 anyway) whereas late adaptors will have it much easier (better ecosystems, much less bugs anywhere else, problems are documented and well understood, infrastructure is tested, etc.). The incentives from the business side are just plain wrong. They can change when CGNAT causes problems. But they don't as long as other stuff is more important.


What is the concrete problem you envision from "heavy CGNAT"?


Lots of networks and software is broken on ipv6.

The more you use ipv4, the more reliable things are.

Someday that will hopefully change.


I believe even Hacker News is inaccessible via ipv6.

https://news.ycombinator.com/item?id=19833362

I noticed this at my parents' house, where their new wifi setup was toggled to "ipv6 only" mode, and HN didn't work.


$ ping -6 news.ycombinator.com

ping: news.ycombinator.com: Name or service not known

There is no AAAA record :/


Accessing an IPv4-only website from IPv6 is not a major problem. A NAT64 gateway to access such legacy services works fine. IPv4-only clients is another issue.


Running an IPv4-only website becomes a problem as ISPs migrate their IPv4 traffic to NAT44/NAT64, and you can no longer tell users apart for abuse detection purposes.


> you can no longer tell users apart for abuse detection purposes

s/abuse detection/tracking

As a user, this sounds like a feature -- but really, there are a ton of other metrics to track most users by (assuming we're talking about abuse done via the actual website interface rather than just flooding ports with packets from a specific IP).


I doubt this website would even be up if they had no abuse detection.


If you run a dual-stack site, the attackers can just use your IPv4 (if their ISP gives them a private one) or the equivalent NATed IPv6 (forcing the use of NAT64) instead of your real IPv6.


Sure, but you can block the attacking IPv4 addresses without affecting normal IPv6 users. This is why it's a good idea for ISPs to deploy IPv6 alongside NAT, and for browsers to prefer IPv6 by default.


If you want to use HN over IPv6 then add the following to your hosts file:

    news.ycombinator.com 2606:4700::6810:686e


When a dns request is sent the dns software most of the worlds ISPs uses pulls both the A and the AAAA record, but the AAAA (ipv6) record takes on average 4x longer than the A record to pull. The dns software short circuits this so what you get back is almost always an ipv4 address.

If you're accessing a website, you're almost always going to end up getting its ipv4 address. This is significant, because still the entire internet doesn't support ipv6. (I'm looking at you Sonic.) If website providers can't get a dedicated ipv4 address, they could use some sort of 6to4 like tunnel to support ipv4. But because of the way the current dns software works, by default all of their traffic will run through that ipv4 tunnel.

This leaves ipv6 almost exclusively used for p2p or other types of home connections. The future of the internet is shaping up in such a way where websites run over ip4v and end users to have a sort of firewalled ipv4 access, then use ipv6 for everything else.

A law that requires ISPs fully support ipv6 may be beneficial.


Is there a reason why certain companies get to retain their originally allocated Class-A netblocks with their 16 million addresses?

http://www.aturtschi.com/whois/neta1.html

Even companies that were given Class-B netblocks with about 65,000 addresses seems a bit wasteful. I remember when I started an ISP in 1996 it was like pulling teeth to get a Class-C with 255 addresses but there Ford sits with 16 million of their own.


Yes: those netblocks belong to them and you can't take their stuff just because you like the look of it.

There aren't enough addresses in v4. Reclaiming one or two /8s here or there won't fix that. Before IANA runout in 2011, we were going through over one /8 per month, and demand has only gone up since then. Those class Bs you're so worried about would last the internet maybe 2 hours each.

You can push as many allocations around as you like, but there just plain and simply isn't enough v4.


My experience doesn't match that. ISP DNS servers just return the A or AAAA record that they're asked for, and the return time is more or less identical for the two, not 4x longer.

All of the client resolvers I've ever used wait for both records to come back, and your DNS resolution returns both sets of addresses. I think OSX does some sort of racing here, but it still gives v6 some amount of head start (~150ms?).

Also, Google's published v6 stats say that 29% of their users reach them over v6. That doesn't seem to match with "you're almost always going to end up getting its ipv4 address".


AAAA record takes 4x as long because v6 addresses are 4x size of v4 addresses.


I kinda wondered if that was the thought process, but the extra length of the v6 address only adds 12 bytes to the DNS packet. There's still a bunch of other stuff in the packet; dig says the size for my test query goes from 361 bytes to 373 bytes, which is only a 3.3% increase. Even at a rather slow 1 Mbit/s that would only add 100µs to transmit a packet that takes in total ~3ms to transmit.

And that 3ms is likely smaller than the latency in the lookup, which is generally going to be the dominating factor.



Man, that would suck to be behind one of those.


Tell me about it. Rented a place in Amsterdam that came with a Ziggo connection. Wanted to play a game online with someone and I couldn't. No way to host a game. Called support, they said I had a shared ipv4 address. They'd be happy to switch it to a real one but then I'd lose my v6 connection. I didn't know what to tell them. These connections need to come with warning symbols, this isn't what I expect of an Internet connection (I think they deployed "dual-stack lite" but it isn't mentioned in the contract, and even if it is, it should be called "Internet lite").

Still happy with my XS4ALL connection on fiber. Proper /48 subnet and static legacy IPv4 address since ~2011.


Why can't you host a game behind CGNAT? You should be able to use PCP or STUN to establish an incoming port, no?


But wouldn't the game itself would have to support something like STUN?

AFAIK, it's a handshake between the two ends, made trough a third party server. Both parties need to contact the third party server, then they get an IP:port combination.

So you would have to do that, then quickly enter that information in the game client and server, while making sure that the TTL doesn't expire. You might also have to fight your OS a bit.

Moreover, STUN doesn't work on symmetrical NAT, where the router uses the incoming address of a packet to route it trough the host.

I don't know PCP; I'll look into that. IMO, the solution to the GP's issue is a VPN. Hamachi used to be a popular solution among gamers, I think.


My point was not about the user being able to work around game limitations but to assert that this is, first, a game limitation, wherein it failed to account for the existence of NATs. NATs aren't some new problem: my computer has not had a public routable IP address essentially ever, as even when I was using dial-up in 1995 I had set up a Linux server in our basement to use NAT (as I wanted to have multiple machines in my house always connected). I just don't see why CGNAT is somehow bad or worse or even different than NAT, if the game supports NATs (which it sounds like in your case it doesn't).

Yes: "symmetric NAT" is useless, but I have not yet seen a CGNAT deployment use symmetric NAT. I would just go so far as to say "symmetric NAT is an example of a technology that is not and never will be good enough to be called carrier grade" ;P. So like, that NAT can and has sucked shouldn't be a demonstration that all NAT everywhere is entirely useless.

It could very well be that CGNAT deployments don't have support for PCP, (or the related NAT-PMP and UPnP mechanisms that it is a successor to), which would suck. I haven't checked this yet. However, if they do, you should be able to do just about anything you could on any private NAT setup: these protocols let you ask your NAT to open a reverse port mapping to your system on a routable IP address, and you can use them with external tooling (they don't require you to be inside the app listening on the port or anything).


I use 2degrees. They gave me a static public IP for free when I asked and justified it.

Most people who just browse Facebook and Instagram, watch YouTube and Netflix won't notice a thing.


In the meantime, we still can't have a web server running on a GCP instance that uses an IPv6 address and does TLS termination with your own certificate at the same time.


I'm currently running a pfSense router at home, which has limited IPv6 support. Does anyone have any suggestions for something with more extensive IPv6 support?

Specifically what I need is something which can handle my ISP only handing me a /64, and can smoothly handle prefix changes (update firewall rules etc).

Ideally also being able to register/update LAN clients on dyndns service so I don't need to install an update client locally on every device.


I think OPNSense has proper IPV6 support


At the same time, GitHub Pages do not work[1] with IPv6 yet...

[1] https://github.community/t5/GitHub-Pages/Cannot-reach-any-gi...


They used to support IPv6. When they added HTTPS support they removed it because of it [1]. Which is a complete nonsense reason. Using the old IPv6 range works for *.github.io domains even now.

But IIRC, you can fetch GitHub Pages custom domains over IPv6 with HTTPS too, but you don't get the correct certificates, because they simply don't have an IPv6 range pointing to the newer HTTPS-supporting infra.

[1]: https://github.com/isaacs/github/issues/354#issuecomment-385...


Not if you don’t use Cloudflare ;-)


Now if only my ISP would get onboard. I applaud the 1gbps fibre, but IPV6 has been "in progress" for like 3 years now...


Verizon FiOS?


IIRC, they plan to deploy IPv6 in 2020 spring. Unfortunately I can't remember the source.

And they've had it in few select residential areas as a trial since 2018 autumn [1].

[1]: https://www.dslreports.com/forum/r32136440-Networking-IPv6-w...


Small local player. But they posted on twitter in 2016 that their network is technically ready. Apparently finding the ON switch takes years


Well, to me, the issue of IPv6 adoption is that it is not a natural extension to IPv4, but two different protocols. It requires two settings efforts and additional efforts for interoperability with third parties still limited to IPv4.

I am sure there must be some tools to smooth the efforts, but it is not native in the protocols.


Would it be ethical/useful to overwhelm NATs with addr:port combinations to overflow the NAT's translation table? If NATs start breaking down, it might force upstream to start adopting IPv6. I could see a system of doing this as setting a different port for each outgoing connection. Thoughts?


I doubt it would be either ethical or useful to deliberately overload translation tables. That said, I would imagine that the migration to QUIC and HTTP/3 would increase pressure on NATs. QUIC's use of UDP means that it's harder to safely reuse source ports for connections to different destinations compared to TCP, so the density of connections per external IP address should be lower.


Is there a graph of the average price of a /24 block of ipv4 addresses?

Is the price going to keep appreciating as supply falls until there is no more supply? I.E. is there potential to treat ipv4 addresses like a commodity?

I don't see ipv6 being widly adopted (major cloud providers only offering ipv6 for new servers) in the near future.



IPv4's inability to label all the things may be a feature. NAT's are like borders in some ways, and prevent fine grained censorship without larger consequences.


Meanwhile ipv6 which had literally one job* remains fairly useless.

* that is to avert impending address exhaustion, but it happened, and ipv6 sat idle and did nothing.


If that were its only job, the only change would have been 128 bits instead of 32 for the address. There's like a bazillion other changes, unfortunately :(


Not as many as you think. It's mostly very similar to v4, and the majority of the changes are to handle the extra address width.


Again?


Nope, not again.

This is the first time that RIPE has ever had more applications for v4 space than v4 ranges to satisfy those applications with (even with the strict limits on how much people can request).




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

Search: