Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
"Fae" Grace Meadows
Which IPv4 blocks are public, which are private, and what loopback, APIPA and CGNAT addresses tell you on a ticket. Covers NAT, finding both addresses on any OS, IPv6 ULA, and choosing a subnet for a new office.
A technician reads IP addresses all day, and the first three numbers settle half the ticket before anyone touches a cable. A 192.168 address and a 100.64 address look alike on a screen and mean opposite things on the wire. This guide sorts the public IP address range from the private and reserved blocks, explains how NAT bridges them, and walks through the tickets each block explains.
An IPv4 address is public when it is reachable from anywhere on the internet. That takes two things: it has to be routable, meaning routers across the world carry a path to it, and it has to be allocated. The Internet Assigned Numbers Authority hands blocks to five Regional Internet Registries, the registries hand them to ISPs and large organizations, and the ISP hands one to your office. The address on the WAN side of the firewall is the one the rest of the world sees.
Everything that is not allocated that way is either private or reserved for a special purpose. The two lists are short, and they are the whole trick of reading an address at a glance.
RFC 1918, published in February 1996, set aside three blocks for networks that never need to be reached from outside. Routers on the public internet drop packets addressed to them, so any organization can use the same block without clashing with anyone else.
| Block | CIDR | Address count | Where you meet it |
|---|---|---|---|
| 10.0.0.0 to 10.255.255.255 | 10.0.0.0/8 | 16,777,216 | Corporate LANs, VPN pools, anything that needs room |
| 172.16.0.0 to 172.31.255.255 | 172.16.0.0/12 | 1,048,576 | Docker's default bridge, some ISP gateways, mid-size offices |
| 192.168.0.0 to 192.168.255.255 | 192.168.0.0/16 | 65,536 | Home routers, small offices, nearly every default config |
The second block trips people up because it is not the whole of 172. Only 172.16 through 172.31 is private. An address at 172.32.5.1 is public and belongs to somebody, and a firewall rule that allows "172.x" as if it were internal has opened the door to a chunk of the internet.
The same mistake runs the other way. A subnet mask of /16 on a 192.168.1.0 network does not make the office bigger in any useful sense, it makes the office claim all 65,536 addresses in the block, which matters the day a VPN user's home router sits on 192.168.50.0 and the office now says that is local.
Private addresses only work because the router at the edge rewrites them. Network address translation swaps the private source address on every outgoing packet for the router's public one, records which inside device asked, and reverses the swap when the reply arrives. The office of 80 machines shows up to the internet as one address, and nothing on the internet can start a conversation with 192.168.10.23, because that address means nothing out there.
That is also why inbound services need a hole. A port forwarding rule tells the router that traffic arriving on a given port of the public address belongs to one specific private address inside. Without the rule, unsolicited packets hit the router and stop. The same mechanism explains why "the server has a public IP" is a claim worth checking: on an office network, the server has a private address and the firewall has the public one, and the two are only joined where someone wrote a rule.
PowerCert's seven-minute explainer is the one to send a junior technician before the NAT conversation:
Beyond RFC 1918, a handful of blocks are reserved by the IANA special-purpose registry, and each one carries a message when it shows up on a ticket.
127.0.0.0/8 is loopback. Any address in it points at the machine itself. A service bound to 127.0.0.1 answers local requests only, which is why a database that "listens on 127.0.0.1" cannot be reached from the next desk no matter what the firewall says.
169.254.0.0/16 is link-local, defined in RFC 3927. Windows calls it APIPA, Automatic Private IP Addressing. A client that asks for a DHCP lease and hears nothing picks an address in this block for itself so it can at least talk to neighbors on the same cable. On a ticket it means one thing: the DHCP request never got an answer. The server is down, the pool is empty, the port is on the wrong VLAN, or the relay between the client and the server is missing. The client is fine. The path to DHCP is not.
100.64.0.0/10 is shared address space, defined in RFC 6598 in April 2012. It exists for carrier-grade NAT. When an ISP runs out of public addresses, it gives each customer an address from this block and runs a second NAT at its own edge, so thousands of customers share one real public address. The customer's router reports a "public" IP that starts with 100.64 through 100.127, and no port forward on that router will ever work, because the inbound packet dies at the ISP's NAT first. Starlink's residential service and a growing number of mobile and fiber ISPs work this way.
The block is also tempting as extra private space, and that is the argument in the r/sysadmin thread below: an architect wanted to put internal servers on 100.64 addresses because the company had used up its RFC 1918 space. The replies land on the catch. A remote user whose ISP assigned them a 100.64 address would find the VPN route and their own WAN address overlapping.
224.0.0.0/4 is multicast. Addresses here are group destinations, not hosts. mDNS on 224.0.0.251 is how printers and Apple devices find each other, and a 224 address in a capture is discovery traffic, not a device with a strange IP.
0.0.0.0 and 255.255.255.255 are the two ends of the scale. A service that binds to 0.0.0.0 listens on every interface the machine has, which is the opposite of 127.0.0.1. The all-ones address is the local broadcast, which is where a DHCP Discover goes before the client has any address at all.
A machine knows its own private address and has no idea what its public one is, because the public address belongs to the router. So there are always two lookups, one on the device and one from outside.
On Windows, ipconfig prints the private address and the default gateway, and ipconfig /all adds the DHCP server and lease times, which is where a 169.254 address shows up as "Autoconfiguration IPv4 Address". On macOS, ipconfig getifaddr en0 returns the address of the primary interface, or the Wi-Fi details in System Settings show it. On Linux, ip -4 addr lists every interface with its address and prefix length.
The public address comes from a lookup service that reports the source address it saw. From any of the three systems, curl ifconfig.me or curl -4 icanhazip.com prints it in one line, and a browser search for "what is my IP" does the same in a tab. The router's own status page shows its WAN address, and comparing the two is the fastest CGNAT test there is: if the router's WAN address and the lookup service's answer differ, there is another NAT between the router and the internet. If the WAN address starts with 100.64 through 100.127, that NAT is the ISP's.
Across a fleet, collect ipconfig /all and one public lookup from every device in a single run. On OpenFrame that is a script run across a client's devices with the output collected in one place, which turns "which sites are behind CGNAT" into a column rather than a phone call per office.
IPv6 keeps the same three ideas with different prefixes, and a technician who learns the first few characters can read it as fast as IPv4.
Global unicast addresses, which start with 2 or 3 in the first character, are the public ones, allocated the same way through the registries. Unique local addresses, defined in RFC 4193 in October 2005, are the private equivalent: the fc00::/7 block, in practice fd00::/8, with a random 40-bit chunk after the prefix so that two organizations that merge almost never collide, which is the whole lesson RFC 1918 taught. Link-local addresses start with fe80 and every IPv6 interface has one whether or not anything else is configured, so fe80 on an interface is normal and not the IPv6 version of APIPA.
The practical difference is NAT. An IPv6 network usually gives every device a global address and relies on the firewall, not translation, to block inbound traffic. The addresses are public and the devices are still unreachable, because the firewall's default is to drop what nobody asked for. A fleet that has IPv6 switched on at the ISP without a firewall policy for it has a second front door, which the stateful firewall guide covers.
Read the address first and the cause is usually on the screen.
Double NAT. The ISP's modem is also a router, the client's own firewall sits behind it, and both translate. The firewall's WAN address is 192.168.0.2 or similar, port forwards configured on the firewall never see traffic, and VoIP phones register and then drop. The fix is to put the ISP device in bridge mode, or in its DMZ pointing at the firewall if bridge mode is locked, so only one device translates. The tell is a private address on the WAN interface of a device that should have a public one.
Overlapping subnets. Two networks that both use 192.168.1.0/24 cannot be joined by a VPN, because a packet for 192.168.1.20 has two valid answers and the router picks the local one every time. It happens on site-to-site tunnels after an acquisition and on remote-access VPNs every day, since the user's home router ships on the same subnet as the office. The r/sysadmin thread below is the remote-access version: a new client on 192.168.1.x, dozens of home users on the same range, and a technician trying to fix it without a renumbering outage.
The replies cover the two real options. Translate one side across the tunnel with source and destination NAT so each end sees the other as a range it does not already use, which works and leaves a trap for the next technician. Or renumber the office once, properly, which is the answer everyone in the thread agrees on and nobody wants to schedule.
"The server has a public IP" behind CGNAT. The client's router shows 100.71.4.18 on its WAN page, the client reads it as public, and the port forward for the camera system never connects from outside. There is nothing to configure. Ask the ISP for a public IPv4 address, not a static one, since front-line support hears those as the same request; or move the service to a tunnel that connects outbound, which the destination host unreachable guide covers from the traceroute side.
An APIPA address on a working switch. A desktop on 169.254.37.102 with a link light has lost DHCP, and the question is why this port. If the whole office lost it, the DHCP server or its service is down. If one port did, the port is on a VLAN with no DHCP scope or no relay, which the VLAN guide explains, or a rogue device on the segment is answering first with addresses of its own.
One traceroute separates the four tickets above. Run tracert 8.8.8.8 on Windows or traceroute 8.8.8.8 elsewhere and read the first two hops.
Hop one is the office gateway, a private address. Hop two is where the answer lives. A public address at hop two means the office firewall has a real public address and translation happens once. A second private address, in 192.168 or 10 space, means the firewall sits behind another router that also translates, which is double NAT. An address in 100.64 through 100.127 at hop two means the ISP is translating, and everything inbound ends there.
Every help desk has the ticket where the port forward was configured three times and the address was the problem all along:
The cheapest fix for half the tickets above is the subnet you choose on day one. Four gates settle it.
First, stay off 192.168.0.0/24 and 192.168.1.0/24. Every consumer router ships on one of them, so every remote user's home network will collide with the office the first time they open a VPN. Second, pick a block with an unusual second octet, such as 10.73.0.0/16 carved into /24s per VLAN, or 172.2x.y.0/24, so an acquisition or a client merge has a fair chance of not overlapping. Third, reserve a separate range for the VPN pool and for the site-to-site tunnel interfaces before anyone needs them, so they never borrow from a user VLAN. Fourth, write it down with the gateway, the DHCP scope and every static address, in the same document as the rest of the network design checklist, so the next technician does not discover the printer's static address by unplugging it.
A public address is one the registries handed out and the internet can route to. A private address is one of three RFC 1918 blocks that never leave the building, and NAT at the edge is what lets them reach out. The reserved blocks in between are diagnoses: 169.254 means DHCP failed, 100.64 means the ISP owns the NAT, and 192.168 on a WAN port means two devices are translating. Read the first octets, then the second traceroute hop, and the ticket usually names its own cause.
For the next step on the same network, the network mapping guide covers finding every address in use before you change any of them.
Lead AI Fairy
Some things defy easy explanation: magic dust, the northern lights… and Flamingo’s AI Angels. Think Charlie’s Angels, reimagined with automation brains and serious RMM (Remote Monitoring & Management) chops. Weird? A little. Effective? Absolutely. That’s the job.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.