IPv4 has four billion addresses, and the world has many times more devices than that. That arithmetic should have brought the Internet to a halt around the year 2000. It did not, and this lecture explains why: address translation extended the life of IPv4 by more than two decades, at the price of a deliberate violation of one of the fundamental rules of networking. The second half of the lecture is about tunnelling - the art of making a protocol travel through an infrastructure that does not understand it, IPv6 through an Internet that still speaks IPv4 included.
1Recap4 min
- The source and destination IP addresses stay constant from one end to the other. Only the MAC addresses are rewritten.
- The private addresses of RFC 1918 are not routable on the Internet.
- In iptables, the chain says where along the route, and the table what kind of decision.
- PREROUTING is before the routing decision, POSTROUTING after it.
- A socket is the pair address + port; a connection is identified by four numbers.
The first point is the one we demolish today. The whole of lecture 6 insisted that IP addresses do not change along the way - and now we shall see a device that changes them on purpose, in every packet, in both directions. It is not a contradiction: it is a carefully built exception, with unpleasant consequences of its own.
Learning outcomes
- Explain why the IPv4 addresses ran out and what postponed the crisis
- Follow a packet through translation, out and back
- Choose between static NAT, dynamic NAT and PAT
- Use the terms inside local, inside global, outside local and outside global correctly
- Configure NAT on Cisco and on Linux
- List what NAT breaks, and why
- Explain the difference between layering and tunnelling
- Write and read an IPv6 address and explain how 6to4 works
2The problem: why the addresses ran out8 min
IPv4 uses 32-bit addresses, hence roughly 4.3 billion values - of which a considerable part is reserved and unusable. The last free blocks were handed out by IANA in February 2011.
The original allocation was made by class, and the classes came in three sizes: 256, 65,536 or 16 million addresses. Nothing in between.
An organisation needing 300 addresses did not fit into a class C, so it received a class B - and left 65,000 addresses unused. Entire universities received class A blocks, with 16 million addresses each, in the 1980s.
So: four billion addresses, of which perhaps a quarter ever reached a device. The rest were lost to rounding.
Three mechanisms postponed the crisis, and all three are still in use:
| Mechanism | What it does | Where we met it |
|---|---|---|
| CIDR | abolishes the classes; allows allocations of a suitable size (/22, /28…) | lecture 5 |
| Private addresses (RFC 1918) | three blocks reusable by any number of organisations, in parallel | lecture 5 |
| NAT | makes private addresses usable on the Internet | today |
| Private block | Prefix | Addresses | Where it typically appears |
|---|---|---|---|
10.0.0.0 – 10.255.255.255 | /8 | 16.7 million | large enterprise networks |
172.16.0.0 – 172.31.255.255 | /12 | 1 million | medium networks, laboratories |
192.168.0.0 – 192.168.255.255 | /16 | 65,536 | small networks, the home router |
192.168.1.1 exists, right now, in millions of homes at once. It is no
problem, because no router on the Internet has a route to it: the private blocks are explicitly
filtered at the edge of any serious network.The price: to reach the Internet, these addresses must be replaced with a public one. That is exactly what NAT does.
3What translation actually does8 min
The router keeps a record of the translations in a NAT table, built either statically by the administrator or dynamically by inspecting the traffic that passes.
4The three kinds of translation10 min
Static NAT - one to one
The problem: a server has a private address but must be reachable from outside through a
fixed public address.
The solution: a permanent association between the internal address and a reserved public
one. The translation works in both directions, so connections may be initiated from the Internet as
well - it is the only kind where that works without further configuration.
Dynamic NAT - n to m
The problem: 40 internal hosts but only 20 public addresses available.
The solution: a pool of public addresses, from which hosts temporarily receive one for
as long as they are communicating. When the pool empties, the next hosts cannot get out - behaviour
that is hard to troubleshoot, because it depends on the time of day. Connections from outside cannot
be initiated, because nobody knows in advance which address belongs to whom.
PAT - n to one
The problem: 40 internal hosts and a single public address.
The solution: PAT (Port Address Translation), called NAT overload by Cisco and
MASQUERADE in Linux. As well as the address, the router translates the source
port, using it as the identifier of the conversation. When the reply comes back, the destination
port tells the router which host it belongs to.
Open several connections from different hosts and watch the middle column: the public address is always the same, but the port differs. That is the entire idea.
With 16 bits of port, a single public address theoretically supports over 64,000 conversations - in practice a few hundred hosts, because a modern browser opens dozens of connections for a single page. This is, in figures, the explanation for why the planet stayed on IPv4 far longer than anybody estimated in 1995.
| Static NAT | Dynamic NAT | PAT | |
|---|---|---|---|
| Address ratio | 1 : 1 | n : m | n : 1 |
| The association | permanent | temporary, for the duration of the session | temporary, per connection |
| Translates the port | no | no | yes |
| Initiation from outside | yes | no | no, without port forwarding |
| Typical use | published servers | rare; superseded by PAT | practically every access network |
5The four terms that confuse everybody6 min
The Cisco documentation uses four names for the addresses involved. They are logical once understood, but until then they cause remarkable confusion.
Inside or outside answers: whose host is it? Ours, or the Internet's? It refers to the owner, not to the position of the address.
Local or global answers: from where are we looking? From inside the network, or from the Internet?
So "inside local" means our host, seen from within, and "inside global" means the same host, seen from the Internet. They are two names for the same computer.
| Term | Whose host | Seen from where | Example |
|---|---|---|---|
| Inside local | ours | from within | 192.168.1.10 - the real private address |
| Inside global | ours | from the Internet | 86.120.5.7 - the translated public address |
| Outside global | theirs | from the Internet | 93.184.216.34 - the real address of the server |
| Outside local | theirs | from within | usually the same; it differs only with double NAT |
show ip nat translations displays them in
exactly that order. When you read the table, the "inside local" column is the real host, and "inside
global" is its public mask.6NAT on Cisco equipment9 min
The configuration always has three components, and the absence of any one of them produces a NAT that does not work and gives no error.
- What gets translated - an ACL or a static mapping.
- What it is translated into - a pool of addresses, or an interface.
- Which interface is "inside" and which "outside" - the step most often forgotten.
! 1. what gets translated - an ordinary ACL, but here permit means ! "this is the traffic I am talking about", not "let it through" R1(config)# access-list 1 permit 192.168.1.0 0.0.0.255 ! 2. what it is translated into - the outgoing interface address, whatever it is R1(config)# ip nat inside source list 1 interface gigabitEthernet 0/1 overload ! 3. who is inside and who is outside R1(config)# interface gigabitEthernet 0/0 R1(config-if)# ip nat inside R1(config)# interface gigabitEthernet 0/1 R1(config-if)# ip nat outside
! the server 192.168.1.100 is visible from the Internet as 86.120.5.8 R1(config)# ip nat inside source static 192.168.1.100 86.120.5.8 ! port 80 only, if we do not want to expose the whole server R1(config)# ip nat inside source static tcp 192.168.1.100 80 86.120.5.8 80
Look at the last line of the first command: it has only two columns filled in and no protocol. It is the static mapping - permanent, present even if nobody is communicating. The other four are dynamic and disappear when the timer expires.
show ip nat translations is empty although traffic is flowing, step 3 is almost
certainly missing: the interfaces were not marked ip nat inside /
ip nat outside.If the table has entries but the ping still fails, the problem is no longer NAT - check the default route and whether the provider really does route the public address you are using.
7NAT in Linux10 min
Translation is configured with the same tools as filtering, but in the nat table. The
golden rule is to know which chain you are in - and the reason is purely logical:
| What we rewrite | Chain | Target | Why there |
|---|---|---|---|
| the source address | POSTROUTING | SNAT | after the routing decision - the route is chosen on the real address |
| the destination address | PREROUTING | DNAT | before the routing decision - otherwise the router would route to the wrong address |
| the source, with the interface IP | POSTROUTING | MASQUERADE | when the public address comes from DHCP and may change |
The packet arrives addressed to 86.120.5.7 - the router's address. If the router
made the routing decision first, it would conclude "this is for me" and hand it to the local
process. Too late.
By rewriting the destination beforehand, the packet reaches the routing decision already
addressed to 192.168.1.100, and the router routes it normally towards the LAN.
Symmetrically, SNAT must come after: rewriting the source earlier would change nothing
about the routing (the route depends on the destination), but we would lose the information about
which interface the packet will leave by - exactly the information MASQUERADE
needs.
# outbound: rewrite the private source with the reserved public address iptables -t nat -A POSTROUTING -s 192.168.1.100 -j SNAT --to-source 141.85.200.1 # inbound: rewrite the public destination with the private address of the server iptables -t nat -A PREROUTING -d 141.85.200.1 -j DNAT --to-destination 192.168.1.100 # and, essential, enabling routing in the kernel sysctl -w net.ipv4.ip_forward=1
# a pool of public addresses
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT \
--to-source 141.85.200.2-141.85.200.6
# PAT with the outgoing interface address, whatever it is
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
SNAT requires the public address to be written out explicitly - it is faster, because the
kernel does not have to look it up for every packet. It is used when the address is fixed.MASQUERADE reads the current address of the outgoing interface. It is slightly slower but
survives an address change - and is therefore the standard on home connections, where the provider
hands out the address by DHCP.Is there anything wrong with the following pair of rules?
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source 141.85.200.2-141.85.200.6 iptables -t nat -A POSTROUTING -s 192.168.1.100 -j SNAT --to-source 141.85.200.1
See the solution
Yes. The second rule will never apply: the address 192.168.1.100 is part of
192.168.1.0/24, so it matches the first rule, whose target is SNAT - a
terminal target - which ends processing of the chain.
The solution is to swap the order: the more specific rule on top.
It is exactly the same lesson as with the access lists of lecture 7, in an entirely different context: the order of the rules is part of their meaning. You will meet it a third time in routing, under the name longest prefix match.
Port forwarding
When an internal server must be exposed for one particular application only, the destination is rewritten on the basis of the port. It is exactly what you do in your home router's interface when you "open a port".
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 \
-j DNAT --to-destination 192.168.1.100
# the filtering rule must permit the traffic too!
iptables -A FORWARD -i eth0 -o eth1 -d 192.168.1.100 -p tcp --dport 80 -j ACCEPT
# needed only if the network has several gateways:
iptables -t nat -A POSTROUTING -o eth1 -p tcp --dport 80 -d 192.168.1.100 \
-j SNAT --to-source 192.168.1.1
nat table and the filter table are independent. A correct DNAT carries
the packet to the internal server - but if the FORWARD chain policy is DROP and there is
no explicit rule, the packet is discarded immediately after translation.The symptom:
conntrack -L shows the connection, but the server sees nothing.8What NAT costs us6 min
- With PAT, a host on the Internet cannot initiate communication - which broke the peer-to-peer model of the original Internet
- It uses layer 4 information (the port) to control layer 3 - a direct violation of layering
- It hampers protocols that carry IP addresses inside the data: active FTP, SIP, some games.
The router must inspect and rewrite the payload as well, with dedicated modules
(
nf_conntrack_ftp) - It copes badly with UDP traffic, which has no notion of a connection, and hence none of its end - the entries expire on a timer, sometimes too soon
- It breaks traceability: in a server's logs, hundreds of users appear with the same address
- It delayed the adoption of IPv6, offering a "good enough" solution at precisely the moment when the pressure to migrate ought to have been rising
100.64.0.0/10 - neither public nor classically private.The consequence for you: port forwarding at home no longer works, however correctly you configure it. Your router does not own the public address it is supposed to expose.
The good side is worth stating too, because it is often invoked as an argument: NAT offers, as a side effect, a form of protection - nothing reaches the internal hosts without having been asked for. It is not a firewall, however, and does not replace one: it filters nothing on the way out, inspects no content, and does not protect you from a compromised internal host.
9The concept of tunnelling7 min
The fact that IP encapsulates TCP, and Ethernet encapsulates IP, is not tunnelling - it is ordinary layering, in which each layer carries the one above it.
Tunnelling appears when a protocol is encapsulated in one of the same or a higher layer: IPv6 in IPv4 (3 in 3), Ethernet in IP (2 in 3), TCP in SSH (4 in 7).
The quick test: if the packet contains two headers of the same kind - two IP headers, say - it is tunnelling.
The intermediate postal service never knew what it was carrying. The friend is the end of the tunnel.
| Tunnel | Carries | Through | Layer | Purpose |
|---|---|---|---|---|
| GRE | layer 2 and 3 protocols | IPv4 or IPv6 | 3 | logical links between routers |
| SSH | layer 4 protocols | SSH | 7 | secure transport |
| IPsec | IP | IP | 3 | a VPN with confidentiality and integrity |
| L2TP | PPP, ATM, Frame Relay | UDP | 2 | PPP links over IP infrastructure |
| 6to4, Teredo | IPv6 | IPv4, and UDP respectively | 3 | the transition to IPv6 |
When both are needed, they are combined: GRE over IPsec is the classic site-to-site VPN configuration.
10The GRE tunnel8 min
GRE (Generic Routing Encapsulation) creates a logical link between two routers that are not physically adjacent. The intermediate routers know nothing about the content of the tunnel: to them it is an ordinary IP packet addressed to the other end.
! on R2 R2(config)# interface tunnel 0 R2(config-if)# ip address 172.16.0.1 255.255.255.252 R2(config-if)# tunnel source 203.0.113.2 R2(config-if)# tunnel destination 198.51.100.4 R2(config-if)# tunnel mode gre ip ! on R4 - an exact mirror R4(config)# interface tunnel 0 R4(config-if)# ip address 172.16.0.2 255.255.255.252 R4(config-if)# tunnel source 198.51.100.4 R4(config-if)# tunnel destination 203.0.113.2
From here on, tunnel 0 behaves like any interface: it has an IP address, it appears in
the routing table, it can take part in OSPF. Routers R2 and R4 are, as far as routing is concerned,
direct neighbours - although there are kilometres of Internet between them.
The symptom is characteristic and misleading: ping works, SSH sessions work, but large transfers and large web pages hang. Small packets get through, large ones do not.
The usual remedy:
ip mtu 1400 and ip tcp adjust-mss 1360 on the tunnel
interface.
11The SSH tunnel6 min
An SSH tunnel redirects a local port through an already encrypted SSH session. The typical scenario: Alice has an account on a Linux router reachable from the Internet and wants to administer, over Telnet, an old server behind it, without sending her password in the clear across the Internet.
ssh -N -L 0.0.0.0:5000:141.85.200.1:23 alice@141.85.200.19 # -N do not open a shell on the intermediate machine # -L local tunnel: the entry port is on the local machine # 0.0.0.0:5000 the address and port listened on locally # 141.85.200.1:23 the final destination, as seen from the intermediate machine
After this command, any connection to 127.0.0.1:5000 on Alice's machine leaves
encrypted towards the SSH server and, from there, towards 141.85.200.1:23. Alice's
application believes it is talking to a local service.
| Form | Who listens | Scenario |
|---|---|---|
-L port:host:port | the local machine | I reach a service on the remote network |
-R port:host:port | the remote machine | I expose a service of mine to that network |
-D port | locally, as a SOCKS proxy | all of an application's traffic, through the tunnel |
A tunnel secures exactly the stretch it crosses, and not a metre more. The observation holds for any VPN - commercial ones included, which protect you as far as their server and no further.
12IPv6, in brief10 min
IPv6 is not an improved version of IPv4 but a new protocol, designed to solve precisely its shortcomings.
- Not enough addresses
- A complicated header, of variable length
- A checksum recomputed at every router
- Fragmentation done by routers, which is expensive
- NAT introduces more problems than it solves
- 128 address bits - 3.4 × 10³⁸ values
- A fixed 40-byte header, fast to process
- No checksum in the header - layer 4 does it
- Address autoconfiguration (SLAAC), without DHCP
- Simplified multicast; broadcast no longer exists
3.4 × 10³⁸ addresses means roughly 6 × 10²³ addresses for every square metre of the Earth's surface. It is not a figure that can be exhausted through waste.
That is why IPv6 can afford something unthinkable in IPv4: every network segment receives a /64 - that is, 18 billion billion addresses - whether it has two hosts or two thousand. Subnetting is no longer an exercise in economy.
Writing addresses
An IPv6 address is written as eight groups of four hexadecimal digits. There are two abbreviation
rules: leading zeros in each group may be omitted, and one single continuous run of zero
groups may be replaced by ::.
Try fe80::1, ::1 and 2002:8d55:c813::1 - the last is a 6to4
address, which you will recognise at once after the explanation in the next section.
::
If two were allowed, the address would become ambiguous: 2001::25::1 would not say how
many zero groups go on the left and how many on the right. With a single ::, the rest is
deduced by subtraction from eight.| Prefix | Type | Role |
|---|---|---|
::1/128 | loopback | testing one's own stack - the equivalent of 127.0.0.1 |
2000::/3 | global unicast | addresses routable on the Internet |
FE80::/10 | link-local | communication within the same segment; generated automatically on every interface |
FC00::/7 | unique local | the equivalent of the private addresses of RFC 1918 |
FF00::/8 | multicast | transmission to a group |
| - | broadcast | does not exist; replaced by multicast to well-defined groups |
The practical convention is that the first 64 bits are the network part and the last 64 the interface part. Subnetting works exactly as in IPv4 at the bit level, except that the space is so large that fixed prefixes are used: /48 for a site, /64 for a segment.
The irony: it is NAT itself, which rescued IPv4, that is the main reason IPv6 was adopted so slowly.
13The 6to4 tunnel6 min
The migration to IPv6 happens gradually: IPv6 islands appear in a backbone that remains IPv4. Static GRE tunnels work, but they must be configured by hand, end by end. The 6to4 tunnel builds itself automatically, through an elegant trick of addressing.
- The addresses of the IPv6 island must be part of
2002::/16. - The next 32 bits of the address are exactly the public IPv4 address of the router at the
edge of the island, written in hexadecimal. For
141.85.200.19that means8D:55:C8:13, hence the prefix2002:8D55:C813::/48. - When an edge router receives an IPv6 packet for such an address, it extracts from it the destination's IPv4 address and encapsulates the packet in an IPv4 packet to that address.
- The intermediate routers route an ordinary IPv4 packet; the Protocol field has the value 41, meaning "encapsulated IPv6".
- The router at the far end recognises the value 41, decapsulates, and delivers the IPv6 packet into its island.
What is the 6to4 prefix of a site with the public address 192.0.2.129?
See the solution
We convert each byte to hexadecimal:
We group them two bytes at a time and append after 2002::
Check: the prefix has 16 bits of 2002 plus 32 bits of IPv4 address = 48. That leaves
16 bits for the site's subnets, that is, 65,536 /64 segments. Plenty.
In practice 6to4 has largely been abandoned (RFC 7526) in favour of dual stack - but the idea remains instructive.
14Common mistakes4 min
- "NAT is configured, but the table is empty"
The
ip nat inside/ip nat outsidemarkings are missing from the interfaces. Without them the router does not know which direction to translate in. They are the third step, the forgotten one. - "I put the specific rule after the general one" SNAT and DNAT are terminal targets: the first match wins and the chain stops. The specific above the general. The same rule as with ACLs.
- "Port forwarding does not work, although the DNAT is correct"
The
nattable moved the packet, but thefiltertable discarded it immediately afterwards. Add the rule on FORWARD. The two tables know nothing of each other. - "The GRE tunnel is up, ping works, but web sites do not load"
An MTU problem: small packets get through, large ones do not fit after encapsulation.
ip mtu 1400andip tcp adjust-mss 1360on the tunnel interface. - "I thought the tunnel encrypted my traffic" GRE encrypts nothing. Nor does 6to4, nor plain L2TP. For confidentiality: IPsec, SSH or WireGuard. A tunnel solves connectivity, not secrecy.
- "I wrote two
::in an IPv6 address" The address becomes ambiguous and is rejected by every implementation. One::only, for the longest run of zero groups. - "Port forwarding at home does not work at all"
The provider uses CGNAT: your "public" address is from
100.64.0.0/10. Check what address the router's WAN interface has. If it is from that block, the answer is a public address from the provider, or a tunnel to an external server.
15Summary and glossary4 min
- The IPv4 crisis came from the waste of class-based allocation, not merely from the number of addresses.
- NAT rewrites addresses in both directions and keeps a record in a table.
- PAT translates the port as well, so n hosts can share one public address.
- Inside/outside = whose host it is. Local/global = from where we are looking.
- DNAT in PREROUTING, SNAT in POSTROUTING - for reasons of order relative to routing.
- NAT breaks peer-to-peer, hampers protocols with addresses in the data, and is not a firewall.
- Tunnelling = encapsulation in a protocol of the same or a higher layer.
- A tunnel does not encrypt automatically; and it secures only the stretch it crosses.
- IPv6 has 128 bits, a fixed header, no broadcast and no need for NAT.
- 6to4 encodes the IPv4 address in the IPv6 address itself, so the tunnel builds itself.
16Self-check questions6 min
17Further reading2 min
The next lecture returns to routing, but to the variety that maintains itself: the link-state protocols and OSPF. You will see why, in a network with twenty routers, static routes become impossible to administer - and how routers manage to build a complete map of the topology by themselves.
Laboratory 6 configures ACLs, NAT and PAT on the company's edge router - exactly the combination from the last two lectures.
- RFC 3022 - traditional NAT
- RFC 2784 - Generic Routing Encapsulation
- RFC 3056 - connection of IPv6 domains via IPv4 clouds (6to4)
- RFC 7526 - the deprecation of 6to4 from recommended practice
- RFC 8200 - Internet Protocol, Version 6
- RFC 6598 - the address space for CGNAT