[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NAT-PT: To deprecate or not to deprecate: the question for next week's v6ops discussion
SUMMARY
Some simple variant of NAT-PT, say NAT6, has to be available for IPv4 to
IPv4 transition.
To avoid unnecessary difficulties, its scope should be limited to:
- Client hosts at IPv6-only addresses which call IPv4-only hosts
- Client hosts which get their destination addresses by themselves (no
need for DNS record translations in NAT6).
- IPv4 applications which are accessible via simple IPv4 NATs (no need for
application level gateways in NAT6).
- Network paths which support at least 1280 octets packets (no need for
fragmentation support in NAT6)
ANALYSIS
KEY QUESTION 1 is:
- Will IPv6 hosts having no global IPv4 address be able to reach all IPv4
servers and applications which IPv4 clients behind private NATs can reach?
- A "yes" answer will clearly facilitate deployment of IPv6 addresses.
- Then some stateful address translation (some kind of NAT-PT) is
unavoidable somewhere.
KEY QUESTION 2 is then:
- Can IETF specify a workable solution? (Issues raised in
"draft-aoun-v6ops-natpt-deprecate-00" have to be dealt with.)
ANSWER TO QUESTION 2
The following list of issues is that of
"draft-aoun-v6ops-natpt-deprecate-00" , with approaches to resolve them
between brackets :
1. Issues which are independent of the use of a DNS-ALG:
1.1 Disruption of all protocols which embed IP addresses (and/or ports)
in packet payloads or which apply integrity mechanisms using IP addresses
(and ports).
[*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
1.2 Inability to re-direct traffic for protocols not built on top of
specific transport layer protocols in situations where one NAPT-PT is
translating for multiple IPv6 hosts.
[*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
1.3 Requirement for applications to use keep alive mechanisms to
workaround connectivity issues caused by premature NAT-PT state timeout.
[*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
1.4 Loss of information due to incompatible semantics between IPv4 and
IPv6 versions of headers and protocols.
[*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
1.5 Inability to redirect packet fragments after the first with NAPT-PT.
[*The scope of NAT-PT should be restricted to network paths and
applications which don't require fragmentation. This includes in particular
all network paths where PMTUs are large enough to support IPv6 packets (
1280 octets plus encapsulation headers not beyond 1500 octets), for all
applications over TCP and all applications UDP over UDP which don't impose
multi-fragment datagrams.*]
1.6 Interaction with SCTP and multihoming.
[*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
1.7 Need for NAT-PT to act as proxy for correspondent node when IPv6 node
is mobile, with consequent restrictions on mobility.
[*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
1.8 NAT-PT not being able to handle multicast traffic.
[*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
2. Issues which are exacerbated by the use of a DNS-ALG:
2.1 Constraints on network topology.
[*The constraint of a stable route through a single point can (and
should) be limited to connections which need NAT-PT, for which it is a must.
For this, parallel 6to4 relays which recognize destination addresses needing
NAT-PT could redirect packets to the unique NAT_PT device. A scheme where
6to4 relays don't even need to be concerned
is presented in http://perso.wanadoo.fr/remi.despres/4to6.htm .*]
2.2 Scalability concerns together with introduction of single point of
failure and security attack nexus.
[*NAT-PT servers can be implemented in server farms, with various ad
hoc load balancing (e.g. based on IPv6 source and IPv4 destination
addresses, or if ever needed even based on source and destination port
numbers).*]
2.3.1 Lack of address mapping persistence: Some applications require
address retention between sessions. The user traffic will be disrupted if a
different mapping is used.
[*The scope of NAT-PT should be restricted to IPv4-NAT compatible
applications.*]
2.3.2 The use of the DNS-ALG to create address mappings with limited
lifetimes means that applications must start using the address shortly after
mapping is created, as well as keeping it alive once they start using it.
[*The scope of NAT-PT should be restricted to configurations which
don't need DNS ALG. Dual stack client hosts should be in charge of
converting IPv4 addresses they obtained in DNS A records into IPv6
addresses. IPv4 mapped addreses can be converted this way, as well as the
larger scope 4to6 addresses proposed in
http://perso.wanadoo.fr/remi.despres/4to6.htm ).*]
2.4 Creation of a DOS threat relating to exhaustion of memory and
address/port pool resources on the translator.
[*Such a threat exists but is a counterpart of reaching the
objective. It can be limited if server farms with load balancing are used,
and various other existing DOS protection techniques may be used. Escaping
this threat will remain a motivation to upgrade IPv4 servers to IPv6
capability. *]
3. Issues which result from the use of a DNS-ALG (list not detailed here).
[* The scope of NAT-PT should be restricted to configurations which don't
need DNS ALG. *]
Regards,
Rémi Després
----- Original Message -----
From: "Elwyn Davies" <elwynd@nortelnetworks.com>
To: <v6ops@ops.ietf.org>
Sent: Friday, November 05, 2004 7:55 PM
Subject: NAT-PT: To deprecate or not to deprecate: the question for next
week's v6ops discussion
...
> o Part of the point is that if we can live with these points in
> respect of NAT,
> these are not necessarily reasons to deprecate NAT-PT. NAT solves
> an ongoing
> problem in IPv4 whereas NAT-PT is intended to be a transition aid.
> On
> the one hand we may feel it is easier to live with some issues if
> the mechanism
> is not with us for ever, but on the other should we use a
mechanism
> that has
> all these issues at all?
...
> Way forwards:
> - Tune the details
> - Show real examples, if any, where translators will really give better
> performance than proxies and are really vital. Make sure that backwards
> compatibility is fully considered, taking into account availability and
> migration of terminals from v4 to dual-stack/v6 plus the availability of
> tunnel support.
> - Either:
> o Deprecate NAT-PT altogther and write other drafts with 'offspring of
> NAT-PT' to
> cover the specialised use cases where a translator is useful, or
> o Turn this into a new applicability draft recommending only a very
> limited set
> of uses, and produce modifications to cater for some of the
specialised
> use cases.
...
> Elwyn