Problems with IPv6 source address
selection and IPv4 NATs
Nokia Corporation
P.O. Box 407
NOKIA GROUP
00045
FI
+358 50 487 6315
remi.denis-courmont@nokia.com
Internet
Network Working Group
NAT
address
selection
This memo details a problem and potential solution,
when using the IPv6 source address selection algorithm
with private IPv4 address space.
When a host initiates an IP communication flow with a remote host,
a pair of local and remote IP addresses to use must be chosen.
If either or both hosts is assigned multiple IP addresses,
an address selection mechanism is required.
That can happen, for instance,
if either or both hosts are dual-stacked.
The default address selection scheme
was specified to address this problem.
One fundamental design assumption of this scheme is the ability
to determine a scope for any address (IPv4 or IPv6).
To that end, static scoping rules were defined.
This memo explains why and how the current rules are inadequate
when Network Address Translation (NAT) is involved,
which is a common occurence in modern-day IPv4 deployments.
As defined in , a unicast IPv4 address
has one of three scopes:
Loopback addresses (127.0.0.0/8)
and autoconfigured addresses (169.254.0.0/16).
Private addresses as defined in .
All other unicast addresses.
The address scopes are supposed to be universal;
and hence they are statically defined.
Furthermore, per ,
scope matching rules (Rule 2) are normally applied
before any other rule,
except for the identical address rule (Rule 1).
In other words, apart from the corner case whereby
the local and remote hosts are one and the same,
the scope matching rule always "wins".
When it crosses a NAT, either the source or destination address
of a packet will change.
As a consequence, the scope of that address might change as well.
In any case, the result of the source address selection scheme
could be different when the original address is substitued
with the translated address.
In fact, many real-world NAT deployments use private addresses
on one side of the NAT, and public addresses on the other side.
This is probably the most common scenario with IPv4 network in
SOHO environment: a single public IPv4 address is provisioned
to a customer, and all hosts on the customer network
"share" that address using a NAT function
within the Customer Premises Equipment (CPE).
assumes that a source address
with a small scope cannot reach a destination address
with a larger scope.
However, if private IPv4 addresses and a NAT are used
to reach public IPv4 addresses,
then this assumption does not hold.
In other words, the private IPv4 addresses behind NATs
effectively have a global scope,
provided that the protocols above the IP network layer
can cope with network address translation.
states that
"the use of transitional addresses
when native addresses are available [should be avoided]".
Indeed, transitional addresses and transition mechanisms in general
tend to be less reliable than native connectivity,
including native IPv4 connectivity.
However, in a typical IPv4 NAT'ed private address deployments,
if IPv6 transition mechanisms are available,
a dual-stack host will typically have the following addresses.
They are the candidate source addresses:
a link-local IPv6 address (autoconfigured),
a site-local scope private IPv4 address
(e.g. assigned by DHCPv4),
a global scope transitional IPv6 address,
such as Teredo,
or 6to4
(e.g. if the CPE is a 6to4 gateway).
If the destination host is also dual-stacked, then it will typically
have two public addresses (though the number is not relevant).
They are the candidate destination addresses:
a global native IPv6 address (e.g. from DNS AAAA record),
a global IPv4 address (e.g. from DNS A record).
Because the candidate source IPv4 address have a smaller scope
(site-local) than the candidate destination IPv4 address (global),
it will be eliminated.
The address selection algorithm will always select
the IPv6 address pair:
the transitional IPv6 address as source,
the global native IPv6 address as destination.
Thus, the transitional (IPv6) address will be used
instead of the native (IPv4) address,
even though that should have been avoided.
There is no way to override this result with a compliant
implementation of source address selection.
In particular, the policy table does not affect this result,
because the scope rules preempt the policy table rules.
Several operating system vendors appear to work around this issue
by assigning a global scope to IPv4 address.
Thus, rule 2 is no longer discriminating
against the IPv4 address pair.
In that case, provided the policy table has separate labels
for transitional addresses,
the IPv4 addresses pair will be selected.
IPv4 addresses normally all have the same label.
Note that the default policy table has a separate label
for 6to4 addresses.
However, as it predates Teredo,
it lacks a distinct label for the Teredo prefix, 2001:0:/32.
An adequate extra label would be as follow:
Prefix: 2001:0:/32, Precedence: 5, Label: 5
With the previous solution,
IPv4 is always selected.
This is a potential drawback
if the upper-layer protocol combination is not NAT-friendly.
As an alternative, a "translation-friendly"
source address selection parameter could be specified,
as in .
However, a default value will be needed
for the many existing applications
that would fail to set this parameter.
The implications of IPv6 Address Translation
and protocol translation are left beyond the scope of this document.
However, it can only be recommended that RFC3484 be taken into account
when designing such translation systems.
This document raises no IANA considerations.