NAT64 marcelo bagnulo, Philip Matthews, Iljitsch van Beijnum IETF 72 - Dublin.

NAT64

marcelo bagnulo, Philip Matthews, Iljitsch van Beijnum

IETF 72 - Dublin

Application scenario

IPv6Only host

IPv6Only host

IPv4OnlyHost

IPv4OnlyHost

NAT64

-Communications initiated by the v6-only host-Compatible with ICE-No support for communications initiated by the v4 only side without previous action from the v6 side (i.e. No support for v6 only servers, beyond the creation of static mappings)-No changes required in any host for basic functionality-Supports communications initiated using the FQDN (of the v4 node) using DNS64

Overview

NAT64

v6

v4

DNS64 DNS

H6IP6

H4IP4

IPT

AAAA RR for FQDN(H4) ?

Overview

NAT64

v6

v4

DNS64 DNS

H6IP6

H4IP4

IPT

AAAA RR for FQDN(H4) ?

AAAA RR for FQDN(H4) ?

Overview

NAT64

v6

v4

DNS64 DNS

H6IP6

H4IP4

IPT

AAAA RR for FQDN(H4) ?

AAAA RR for FQDN(H4) ?

enpty

Overview

NAT64

v6

v4

DNS64 DNS

H6IP6

H4IP4

IPT

AAAA RR for FQDN(H4) ?

A RR for FQDN(H4) ?

Overview

NAT64

v6

v4

DNS64 DNS

H6IP6

H4IP4

IPT

AAAA RR for FQDN(H4) ?

A RR for FQDN(H4) ?

IP4

Overview

NAT64

v6

v4

DNS64 DNS

H6IP6

H4IP4

IPT

Synthetizes AAAA RR as

Pref::/96+IPv4

Synthetizes AAAA RR as

Pref::/96+IPv4

Overview

NAT64

v6

v4

DNS64 DNS

H6IP6

H4IP4

IPT

AAAA RR Pref:IP4

Overview

NAT64

v6

v4

DNS64 DNS

H6IP6

H4IP4

IPT

Src: IP6,sDest: Pref:IP4,d

Src: IP6,sDest: Pref:IP4,d

Overview

NAT64

v6

v4

DNS64 DNS

H6IP6

H4IP4

IPT

IP6,s<->T,t

IP6,s<->T,t

Overview

NAT64

v6

v4

DNS64 DNS

H6IP6

H4IP4

IPT

Src: T,tDest: IP4,d

Src: T,tDest: IP4,d

Comparison with NATPT (RFC2766)• NAT64 only supports v6 initiated communications

– NATPT supports both v4 and v6 initiated, requiring a set of cumbersome techniques

• NAT64 and DNS64 are completelly decoupled– No relation between the NAT64 state and the synthetic RR– DNS64 preserves DNS semantics, DNS responses are valid

irrespectivly of the path used by data packets • NAT64 allows to preffer native connectivity over translated

connectivity• NAT64 is compatible with DNSSec• NAT64 supports some modes of IPSec• NAT64 is fully specified, compatible with behave

requirements

A couple of design questions

What prefix to use to map v4 addresses in v6 land?

• Option 1: Local prefix– We use a prefix /96 obtained from the site’s block– Differnet prefixes for different nat64 boxes in the

same site

• Option 2: global prefix– Candidates:• V4mapped prefix• V4compatible prefix• A new global prefix assigned by IANA

Implication 1: global translated addresses

• If we use a global prefix, we have a globally unique RR that represent translated addresses

• Less problems with DNS, DNSSec• No need to configure the local prefix in DNS64

Implication 2: communication with dual stack

• Local Prefix: Translated addresses are represented as one of the site’s address– Need other means to distinguish them: EDNS0

optionOnly upgraded dual stack can use it: apps that break

with nats may break

NAT64

v6

v4

DNS64

DNS

H6IP6

H4IP4

IPT

AAAA RR Pref:IP4EDNS0

Implication 2: Communications with dual stack

• Global prefix:– V4mapped prefix:

• Automatically less preferred due to rfc3484 policy• Windows vista, Macos, Linux, don’t use it on the wire

– V4 compatible prefix• Automatcially less preferred compared to native v6, but more

preferred than v4 (represented as v4 mapped)• Windows vista, macos, linux send packets to this prefix

– Other global prefix from IANA• More rpeferred than v4• Longest prefix match rule in rfc3484 could help (if not deprecated)

Implication 3: routing fluctuations

• Failure in intra site routing fluctuations

NAT64_1

v6

v4

DNS64DNS

H6IP6

H4IP4

NAT64_2

Implication 3: routing fluctuations

• Failure in intra site routing fluctuations

NAT64_1

v6

v4

DNS64DNS

H6IP6

H4IP4

NAT64_2

Implication 3: routing fluctuations

• Failure in intra site routing fluctuations

NAT64_1

v6

v4

DNS64DNS

H6IP6

H4IP4

NAT64_2

Endpoint independence vs. Higher utilization of v4 addresses

• Endpoint independence requires mappings are: (srcIP6,srcp)<->(T,t)

• Address and port dependent mapping are: (srcIP6,srcp,dstIP6,dstp)<->(T,t,dstIP4,dstp’)

• Can we afford endpoint independence in v6?