Ripe NIC: 'In Five Weeks We'll Run Out of IPv4 Internet Addresses'

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.

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.

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

Touche!

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

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.

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

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.

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.

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.

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.

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?

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

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

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

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

Not with that attitude.

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.

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.

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

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

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.

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.

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

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>

> How does NAT not block incoming traffic?

https://samy.pl/pwnat/

NAT != firewall

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.

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.

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.

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.

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.

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.

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