Embed Size (px)
Citation preview
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?
