talking about nat

SpaceNet AG • Joseph-Dollinger-Bogen 14 • 80807 München – http://www.space.net/

Talking about

NAT

NAT and IPv6 – curse or must-have?

Gert Döring, SpaceNet AG, München

IPv6 Business Conference, 18.06.2016, Zurich


Bored? Just say „NAT!“

• „I‘m not going to use IPv6 because it does not have NAT!“

• „the best thing about IPv6 is that there is no more NAT!“

• ... now what? http://www.youtube.com/watch?v=v26BAlfWBm8

• perfect starter for a controversial talk and a good discussion!

http://www.youtube.com/watch?v=v26BAlfWBm8


Agenda

• defining terminology: what is NAT?

• explain different variants of NAT

• SNAT, DNAT, NPT, NAT64, ...

• benefits and collateral damage

• applicability and relevance for IPv6


N:1 Source NAT (aka Masquerading)

Internet

.10

NAT-Router

User hinter NAT-Router

.20

195.30.4.1

NAT-

Table

WWW-Server

192.168.1.x

193.99.144.85

192.168.1.20

192.168.1.20 195.30.4.1

??

Source IP sent by clients is replaced by router‘s external IP address. NAT table keeps session state to enable return translation. No (easy) reachability from outside Internet.

193.99.144.85

2. User

193.99.144.85

195.30.4.1

195.30.4.1

193.99.144.85

192.168.1.20

193.99.144.85

195.30.4.1

62.10.20.30


N:1 Source NAT

• advantages

• single IP address is sufficient to provide Internet

„connectivity“ to a whole network

• „the inside network is protected“ (security!!!)

• inside IP addresses and network topology are hidden

from outside world

• IP addresses used internally are independent from

ISP connection, so no renumbering on ISP change

• see also: RFC 4864


N:1 Source NAT

• disadvantages

• „security“ aspect really isn‘t… (mail, browser, ...)

• limited size of NAT session table can interfere with

applications („missing tiles“ in google maps)

• if reachability of inside hosts is desired (e.g. for

peer2peer applications, telephony, …) extra effort and

knowledge is required

• Internet divided into „providers“ and „consumers“

• application developers have to spend extra

development effort to make applications work despite

NAT (external relay servers, etc.)


Destination NAT: Loadbalancing

Internet

Loadbalancer

WWW-Server

193.99.

144.85

10

.20

.30

.x

Session-

Table

62.10.20.30

193.99.144.85

62.10.20.30

10.20.30.1

10.20.30.1

62.10.20.30

62.10.20.30

193.99.144.85

193.149.48.161

193.99.144.85

193.149.48.161

10.20.30.3

Load balancer rewrites destination IP address, to distribute clients to all available servers

193.99.144.85 10.20.30.1 62.10.20.30

193.99.144.85 10.20.30.3 193.149.48.161


Destination NAT: load balancing

• advantages

• loadsharing between multiple servers

• automatic failover in case of server unavailability

• applikation specific „NAT“ supplements protocol

(HTTP), instead of interfering with it

• disadvantages

• DNAT has to be on packet path between source and

server, forces specific network design

• redundant setup with DNAT balancers not easy

• alternatives: e.g.. reverse proxy (Netscaler, ha-proxy)


Destination NAT: Enterprise DMZ

53.10.20.x

10.20.30.x

Dienstleister

Unternehmens-

Kunde

Session-

Table

192.168.1.1

53.10.20.1 53.10.20.1 10.20.30.1

192.168.1.1

10.20.30.1

10.20.30.1

192.168.1.1 192.168.1.1

53.10.20.1

customer sends requests to well known „Service IP“, DNAT rewrites destination address towards real server. mappings in session table are predefined, not dynamic


Destination NAT: Enterprise DMZ

• advantages • Service provider can re-route incoming sessions to

different servers / networks internally, without having to inform customers of new topology

• customer only has to route „meet me“ network into VPN (or private link), not all internal networks

• like load balancing DNAT, just static mapping table

• disadvantages • mapping „Host“ <-> IP-Adresse no longer well-defined

(inside, outside, …?) – documentation problem

• debugging in the face of (multi-stage!) SNAT/DNAT is complicated (and traceroute/ping usually „forbidden!“)

• management overhead increases OPEX


ISP grün

ISP blau

InternetRouter blau

Router grün

2001:608:4::/48

2001:db8:9::/48

www.heise.deUser mit

ULAs

fd00:12:34::/48

stateless N:N Source Nat / Prefix Translation

fd00:12:34::2:cafe

2a02:2e0:3fe:100::7 2001:db8:9::2:cafe

2a02:2e0:3fe:100::7

2a02:2e0:3fe:100::7

2001:db8:9::2:cafe

2a02:2e0:3fe:100::7

fd00:12:34::2:cafe

routers translate IPv6 network prefix only (/48) host part (::2:cafe) kept unchanged

2. User2a00:20::de:caf:bad

2001:608:4::b3:babe

2a00:20::de:caf:bad

fd00:12:34::b3:babe

incoming connections work automatically, no configuration on router needed


N:N Prefix Translation – how does it work?

• since IPv6 has enough addresses, overloading N:1 to

conserve addresses is no longer needed – N:N NPT

is much simpler:

• internal address: ULA (RFC 4193) /48 + host part

• fd00:12:34::c001:c0:ffee

• router translates prefix (leftmost /48 bits) towards

ISP Prefix, keeps host part as is:

• 2001:db8::c001:c0:ffee

• automatic mapping for incoming connections:

• 2001:608:4:7::babe fd00:12:34:7::babe

• „security“ aspect of IPv4 SNAT? Use stateful firewall!


N:N Source Nat / Prefix Translation

• advantages

• „stateless“ transation, no overflowing or too short-lived session table, no state loss on router reboot

• internal network numbering is stable, independent of ISP uplinks or ISP changes

• reachability from external sources still works

• ULA space is „highly likely globally unique“*

• advantages if used in a multihoming scenario:

• routing decision is made on the router, not the host

• network admin defines network policy on network edge, and not on every single machine


N:N Source Nat / Prefix Translation

• disadvantages

• addresses no longer constant end-to-end

• protocols using IP addresses on application layer (FTP, SIP, ...) still need special treatment

• referrals problematic („my address is ‚xyz‘“)

• router selection for reply packets needs state

• missing parts?

• „how do I determine my (current) external address?“

• alternatives?

• multiple global IPv6-addresses per host ( homenet)

• „automatic renumbering“ when changing ISP


NAT64: v6 only clients to v4 only servers

Internet

IPv4 + IPv6

Core-Router

IPv6-only

www.heise.de

IPv4 + IPv6

www.bild.de

IPv4-only

NAT 64

Mobile Endgeräte

IPv6-only

NAT-

Table

v6

v6

v4

v4 v6

NAT64 router connects client without IPv4 (v6-only) to servers without IPv6

servers having IPv6 can be accessed directly


NAT64: how does it work?

• scope: IPv6-only clients • z.B. mobile carriers – well understood ecosystem

• connections to IPv6 capable servers? • direct! no NAT, no state table bottleneck

• connections to legacy services without IPv6? • DNS64 server converts IPv4 address to synthetic

IPv6 address <nat64-prefix>:<ipv4>

• connections to <nat64-prefix> are routed to dedicated NAT64 router which does Source NAT to IPv4 pool address and D-NAT to <ipv4> address

• easy scalability by using multiple NAT64 devices, each having its own <nat64-prefix>

• see RFC 6144, RFC 6146, RFC 6147


NAT64: v6-only to v4-only

• advantages

• single stack towards client, no IPv4 necessary

• NAT64 scales much better than IPv4 with private addresses and N:1-NAT in ISP network (CGN)

• disadvantages

• client has no IPv4, i.e. applikations without IPv6-support (Skype!) stop working

• combination with other approaches (DS-Lite, 464xlat) needed

• one-way, no reachability from IPv4 network towards IPv6 host (just like N:1 IPv4 SNAT)

• needs special handling for DNSSEC


Implementations

• IPv6 source NAT / NPT

• BSD pf – both N:1 (nat) and N:N (binat)

• Implementation in pfsense 2.0

• Linux: in ip6tables/netfilter since 3.9.0

• Juniper/Netscreen, Cisco ASA

• IPv6 Destination NAT

• BSD pf (rdr)

• Linux: IPVS since 2.6.28, netfilter since 3.9.0

• various load balancers, e.g. Brocade, F5

• Juniper/Netscreen, Cisco ASA

• NAT64 / DNS64

• various open projects: tayga, jool (w/ 464xlat), ecdysis, WrapSix

• commercially: IOS XE, JunOS 10.4, A10 AX, Brocade, ...


Conclusion (with personal bias)

• N:1 source NAT • highly problematic

• IPv6 removes the necessity to do this

• all typical SoHo routers with IPv6 (AVM, Cisco,...) do not even implement it

• so there is hope that it will go away…

• 1:1 source NAT / NPT • can be quite useful

• highly controversial, much religion, little facts

• much less impact on applications than N:1 SNAT

• possible approach to multihoming in „small companies“

• but multihoming without NAT also possible (homenet)



• destination NAT / load balancing:

• useful, but has its own set of issues

• good alternative approaches without NAT exist

• no real difference between IPv4 and IPv6 here

• destination NAT / enterprise DMZ:

• can be useful

• no real difference between IPv4 and IPv6 here

• Enterprise network administrators require this

functionality, want to keep their established approaches

• so, both variants will be with us for IPv6



• NAT64 + DNS64:

• only alternative would be NAT444 – i.e. ISP provides

private IPv4 adresses to his customers, and adds

another layer of N:1 SNAT – doubly broken

• thus nearly unavoidable for fast growing ISPs with lots

of low-margin customers running out of IPv4 space

• useful

• only applicable in specific (client-only) environments

• will disappear again

• transition technology (5-10 years)


Finis

• questions? just mail me at

[email protected]

• die SpaceNet AG…

• Internet Service Provider seit 1994

• Ihr Partner für komplexe Hosting-Lösungen

• IPv6-Erfahrung seit 1997

• http://www.space.net (natürlich mit IPv6!)

talking about nat

Documents