Network Working Group R. Denis-Courmont
Internet-Draft Nokia
Intended status: Informational February 17, 2009
Expires: August 21, 2009
Problems with IPv6 source address selection and IPv4 NATs
draft-denis-v6ops-nat-addrsel-00
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
This memo details a problem and potential solution, when using the
IPv6 source address selection algorithm with private IPv4 address
Denis-Courmont Expires August 21, 2009 [Page 1]
Internet-Draft NAT & RFC3484 February 2009
space.
1. Introduction
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[RFC3484] 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.
2. IPv4 address scopes
As defined in [RFC3484], a unicast IPv4 address has one of three
scopes:
Link-local scope: Loopback addresses (127.0.0.0/8) and
autoconfigured addresses (169.254.0.0/16).
Site-local scope: Private addresses as defined in [RFC1918].
Global scope: All other unicast addresses.
The address scopes are supposed to be universal; and hence they are
statically defined. Furthermore, per [RFC3484], 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".
3. NAT and address scope
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
Denis-Courmont Expires August 21, 2009 [Page 2]
Internet-Draft NAT & RFC3484 February 2009
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).
[RFC3484] 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.
4. Applicability to IPv6 transition mechanisms
[RFC3484] 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:
o a link-local IPv6 address (autoconfigured),
o a site-local scope private IPv4 address (e.g. assigned by DHCPv4),
o a global scope transitional IPv6 address, such as Teredo[RFC4380],
or 6to4[RFC3056] (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:
o a global native IPv6 address (e.g. from DNS AAAA record),
o 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:
o the transitional IPv6 address as source,
Denis-Courmont Expires August 21, 2009 [Page 3]
Internet-Draft NAT & RFC3484 February 2009
o 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.
5. Solutions
5.1. Changing the private IPv4 address scope
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
5.2. Address selection parameter for NAT
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 [RFC5014]. However, a default
value will be needed for the many existing applications that would
fail to set this parameter.
6. IPv6 Address Translation
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.
Denis-Courmont Expires August 21, 2009 [Page 4]
Internet-Draft NAT & RFC3484 February 2009
7. Security Considerations
TBD.
8. IANA Considerations
This document raises no IANA considerations.
9. References
9.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014,
September 2007.
9.2. Informative References
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
Author's Address
Remi Denis-Courmont
Nokia Corporation
P.O. Box 407
NOKIA GROUP 00045
FI
Phone: +358 50 487 6315
EMail: remi.denis-courmont@nokia.com
Denis-Courmont Expires August 21, 2009 [Page 5]