[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node
Hi,
This is my second issue in the 3GPP analysis document.
----
Section 3.4 (see the text below), "IPv6 UE Connecting to an IPv4 Node",
describes the common case of IPv6-only UE connecting to an IPv4 node.
The technique specified is NAT-PT, and the text includes some words of
NAT-PT applicability as well as a reference to NAT64.
I believe this approach is not a good one, as here NAT-PT (or something
like that) is used as a general purpose translation device for all kinds
of traffic.
I think we need to figure out whether this is really necessary or
acceptable.
My personal belief is that we consider the model:
- Use IPv4 where appropriate,
- Not deploy IPv6-only UE's if they have a need to reach IPv4 services, and
- Use application proxies (such as HTTP gateways, maybe even TCP/UDP
relays specific to an application) where appropriate to make it easier to
go for IPv6-only UE's at some point if it's the way to go.
Other thoughts?
---- cut -----
3.4 IPv6 UE Connecting to an IPv4 Node
IPv6 nodes can communicate with IPv4 hosts by making use of a
translator (SIIT [RFC2765], NAT-PT [RFC2766]) within the local
network. For some applications, application proxies can be
appropriate (e.g. HTTP, email relays, etc.). Such applications will
not be transparent to the UE. Hence, a flexible mechanism with
minimal manual intervention should be used to configure these
proxies on IPv6 UEs. Within the 3GPP architecture, application
proxies can be placed on the GGSN external interface (Gi), or
inside the service network.
However, since it is difficult to anticipate all possible
applications, there is a need for translators that can translate
headers independent of the type of application being used.
Due to the significant lack of IPv4 addresses in some domains, port
multiplexing is likely to be a necessary feature for translators
(i.e. NAPT-PT).
When NA(P)T-PT is used, it needs to be placed on the GGSN external
(Gi) interface, typically separate from the GGSN. NA(P)T-PT can be
installed, for example, on the edge of the operator's network and
the public Internet. NA(P)T-PT will intercept DNS requests and
other applications that include IP addresses in their payloads,
translate the IP header (and payload for some applications if
necessary) and forward packets through its IPv4 interface.
NA(P)T-PT introduces limitations that are expected to be magnified
within the 3GPP architecture. Some of these limitations are listed
below (notice that some of them are also relevant for IPv4 NAT). We
note here that [v4v6trans] analyzes the issues when translating
between IPv4 and IPv6. However, the NAT-PT issues should be clearly
documented in an RFC in the v6ops Working Group and a decision
should be made, whether revisiting the NAT-PT RFC is necessary /
what kind of update is needed.
1. NA(P)T-PT is a single point of failure for all ongoing
connections.
2. Additional forwarding delays due to further processing, when
compared to normal IP forwarding.
3. Problems with source address selection due to the inclusion of
a DNS ALG on the same node [NATPT-DNS].
4. NA(P)T-PT does not work (without application level gateways)
for applications that embed IP addresses in their payload.
5. NA(P)T-PT breaks DNSSEC.
6. NA(P)T-PT does not scale very well in large networks.
3GPP networks are expected to handle a very large number of
subscribers on a single GGSN (default router). Each GGSN is
expected to handle hundreds of thousands of connections.
Furthermore, high reliability is expected for 3GPP networks.
Consequently, a single point of failure on the GGSN external
interface, would raise concerns on the overall network reliability.
In addition, IPv6 users are expected to use delay-sensitive
applications provided by IMS. Hence, there is a need to minimize
forwarding delays within the IP backbone. Furthermore, due to the
unprecedented number of connections handled by the default routers
(GGSN) in 3GPP networks, a network design that forces traffic to go
through a single node at the edge of the network (typical NA(P)T-PT
configuration) is not likely to scale. Translation mechanisms
should allow for multiple translators, for load sharing and
redundancy purposes.
To minimize the problems associated with NA(P)T-PT, the following
actions can be recommended:
1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6
to IPv4" case).
2. Ensure (if possible) that NA(P)T-PT does not become a
single point of failure.
3. Allow for load sharing between different translators. That
is, it should be possible for different connections to go
through different translators. Note that load sharing alone
does not prevent NA(P)T-PT from becoming a single point of
failure.
There are some ways to fix the problems with NA(P)T-PT, one
suggestion is [NAT64].
When thinking the DNS issues, the IPv6 UE needs to find the IPv4
address in the DNS [DNStrans]. Note that DNSSEC is broken if
NA(P)T-PT is used.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings