Isn't NAT a MUST when a LAN uses rfc 1918 private IPs? Can an organization assign its hosts with private IPs and still communicate with the external world without NAT?

how can an internal host with a private IP (say communicate with external world without NAT? I mean, how can the reply/response packet from the external world reach the original source as the packet with Dest IP = will get lost as it can not be routed as many organizations can use the same IP.

Why doesn't rfc 1918 (Address Allocation for Private Internets) make any mention of NAT?


depends on the definition of 'communication'. i saw couple of networks where only access to the web was via proxies. no direct packet exchange was possible between lan and 'wild internet'. ping was not possible, yet web-based apps worked thanks to proxy.

| improve this answer | |

Nope. Tools such as proxies can be used to "reinterpret" the packets without requiring NAT to be in place. NAT is simply a convenient tool to allow connections without an explicit proxy.

| improve this answer | |

Routing works in the following way:

  1. The packet arrives on the ingress interface
  2. The routing table is inspected for longest prefix match on the packet destination address
  3. If a route is found, the TTL is decremented, checksum recalculated and the packet forwarded on the egress interface, specified on the routing table

Most routers (and all hosts that wish to comminicate with the external word) have a default route,, which is the shortest prefix match (0 bits of netmask), and will forward packets not matching any other entry on the associated intereface. They will forward packets towards RFC1918 addresses too. So why can't we use them withot NAT?

Because core Internet routers (and I'm simplifying) don't have a default route in their routing tables, they participate in the so called default-free zone. Because of this, they MUST have a route to every existing network in the Internet (which means carrying around 316K routes these days). Since they know which addresses RFC1918 specifies as private addresses, they will not allow these networks to exist in their routing tables. That's why you can't reach them without NAT, and that's why RFC1918 doesn't mention them.

To answer your question, NAT is NOT a must, as long as you don't want to cross the DFZ, AND people don't actively filter your RFC1918 traffic (which your ISP usually does).

| improve this answer | |

Whether you use a proxy or some other mechanism, at some point the internal ip addresses need to be "mapped" to an external ip address, which in my interpretation is NAT. So my answer is yes, some form of NAT is required.

| improve this answer | |

The operative language in RFC 1918 is in section 3:

An enterprise that decides to use IP addresses out of the address space defined in this document can do so without any coordination with IANA or an Internet registry.

The implication here is that addresses in the RFC 1918 pool should not appear in the global default-free zone, which is a property they share with the IPv6 unique local addresses, i.e. fc00::/7, defined in RFC 4193. Where they differ, of course, is that the IPv6 unique local addresses are explicitly marked as global scope and not site-local scope, whereas IPv4 addresses don't have any official notion of addressing scope. In practice, RFC 1918 addresses are often used as if they possess site-local or organization-local scope, but it isn't strictly necessary to do so.

It's also not necessary to use NAT to give privately address hosts access to the public Internet. In theory, the alternative is to assign such hosts additional public interface addresses alongside the private addresses. Source address selection is supposed to work.

Alas, when presented with an existing practice that works, people often don't give a flip about how it holds up in theory.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy