[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
3gpp-analysis-05: Use of NAT-PT in IPv6 UE -> IPv4 node
Hi,
This is the still-open issue "Use of NAT-PT in IPv6 UE -> IPv4 node"
discussion.
<chair hat=on>
We hope to be able to WG LC and finish the document very soon. Hopefully
the WG LC could be initiated after the next revision, before Minneapolis.
But we'll see how it turns out.
<chair hat=off>
First, a couple of points of discussion:
- If UE is IPv6-only, and you hook up an IPv4 (or dual-stack) laptop to
the UE, would you be able to use IPv4 through the UE (using separate PDP
context)?
- Is there something why this would be undesirable (double billing with
two PDP contexts?)
What I'm trying to grasp at is this: if someone deploys IPv6-only UE's,
for specific purposes only (e.g. making calls, browsing the web), can we
expect that the user of the device does not require geneirc purpose
Internet connectivity (e.g. being able to connect to IPv4 address X,
protocol Y, port Z)?
substantial
-----------
The issues I'm still not very confortable with:
1) NAT-PT use and the recommendations. I don't think it's good practice to
deploy IPv6-only UE's before there are no longer services which cannot be
proxied or otherwise translated one by one. There are significant amount of
dangers associated with general-purpose translation, and NAT-PT is not
likely to diminish those.
What I'd would like to see in the document:
- rather strong recommendation to avoid deploying IPv6-only UE's until the
usage (and IPv6) environments have evolved so that generic translation is no
longer needed, and
- subsequently, greatly reducing the amount of text wrt NAT-PT.
The former should/could include like:
* reasoning why IPv6-only deployments are/are not valid (this really
seems to depend a lot on how specific purpose devices those can be assumed
to be)
* recommendation to avoid IPv6-only deployments until such time that
generic translation is no longer needed
* some description why "specific translation" (or proxying) is more
desirable than overall translation
The latter should/could be reduced become the NAT-PT applicability team is
already struggling with this effort (there will be a draft soon).
Below is the text I wrote which would seem to be better for now
(presupposes that NAT-PT applicability would shun NAT-PT, obviously..).
=====
-- in short, I've edited the 3.4 section extensively from scratch, moved
the bulk of previous 3.4 section to appendix A with some rewording here
and there (until it's known how to deal with it) --
3.4 IPv6 UE Connecting to an IPv4 Node
The deployment of generic-purpose IPv6(-only) UEs is not recommended until
the IPv6 deployment has become so prevalent that direct communication with
IPv4(-only) nodes will no longer be necessary.
Specific-purpose UEs, capable of doing only specific kinds of tasks, are a
slightly different thing: it may be possible to make assumptions on the
nodes and communication protocols they need to use. Then it may be
possible to deploy specialized IPv6(-only) equipment because it's known
that they do not need to reach an IPv4(-only) nodes except using very
specific applications and methods -- and in that case, it is possible to
use specific translation and proxying techniques, not generic
translation.
Thus there are three main ways for IPv6(-only) nodes to communicate with
IPv4(-only) nodes (excluding avoiding such communication in the first
place):
1) the use of generic-purpose translator (e.g. NAT-PT [2766]) in the
local network (not recommended),
2) the use of specific-purpose protocol relays (e.g., IPv6<->IPv4
TCP relay configured for a couple of ports only [TRT]) or application
proxies (e.g., HTTP proxy, SMTP relay) in the local network, or
3) the use of specific-purpose mechanisms (as described above in 2) in
the foreign network; these are indistinguishable from the IPv6-enabled
services from the IPv6 UE's perspective, and is not discussed further
here.
The use of generic-purpose translators (such as NAT-PT) is not recommended
[NATPTappl]; appendix A lists some 3GPP-specific issues related to the use
of translators.
For many applications, application proxies can be appropriate (e.g. HTTP
proxies, SMTP relays, etc.). Such application proxies 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; see section 5 for
more about UE configuration mechanisms.
Section 4.1 [reword the last sentence to:]
The problems related to NAT-PT are documented in appendix A.
Normative References
[Add TRT (the TCP/UDP relay RFC)]
Appendix A - On the Use of Generic Translators in the 3GPP Networks
This appendix lists mainly 3GPP-specific arguments about generic
translators, even though the use of generic translators is
discouraged. The section may be removed in future versions of the
memo.
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). If 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.
1. NA(P)T-PT is a single point of failure for all ongoing
connections.
2. There are additional forwarding delays due to further
processing, when compared to normal IP forwarding.
3. There are 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 may be needed:
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.