draft-ietf-v6ops-natpt-to-historic-00.txt   rfc4966.txt 
v6ops Working Group C. Aoun Network Working Group C. Aoun
Internet-Draft Energize Urnet Request for Comments: 4966 Energize Urnet
Updates: 2766 (if approved) E. Davies Obsoletes: 2766 E. Davies
Intended status: Informational Folly Consulting Category: Informational Folly Consulting
Expires: August 24, 2007 February 20, 2007 Reasons to Move the Network Address Translator - Protocol Translator
(NAT-PT) to Historic Status
Reasons to Move NAT-PT to Historic Status
draft-ietf-v6ops-natpt-to-historic-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2007. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document discusses issues with the specific form of IPv6-IPv4 This document discusses issues with the specific form of IPv6-IPv4
protocol translation mechanism implemented by the Network Address protocol translation mechanism implemented by the Network Address
Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These
issues are sufficiently serious that recommending RFC 2766 as a issues are sufficiently serious that recommending RFC 2766 as a
general purpose transition mechanism is no longer desirable, and this general purpose transition mechanism is no longer desirable, and this
document recommends that the IETF should reclassify RFC 2766 from document recommends that the IETF should reclassify RFC 2766 from
Proposed Standard to Historic status. Proposed Standard to Historic status.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Issues Unrelated to DNS-ALG . . . . . . . . . . . . . . . . . 6 2. Issues Unrelated to an DNS-ALG . . . . . . . . . . . . . . . . 7
2.1. Issues with Protocols Embedding IP Addresses . . . . . . . 6 2.1. Issues with Protocols Embedding IP Addresses . . . . . . . 7
2.2. NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 7 2.2. NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 8
2.3. NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 8 2.3. NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 8
2.4. Loss of Information through Incompatible Semantics . . . . 8 2.4. Loss of Information through Incompatible Semantics . . . . 9
2.5. NAT-PT and Fragmentation . . . . . . . . . . . . . . . . . 9 2.5. NAT-PT and Fragmentation . . . . . . . . . . . . . . . . . 10
2.6. NAT-PT Interaction with SCTP and Multihoming . . . . . . . 10 2.6. NAT-PT Interaction with SCTP and Multihoming . . . . . . . 11
2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 11 2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 12
2.8. NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 12 2.8. NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 12
3. Issues exacerbated by the Use of DNS-ALG . . . . . . . . . . . 12 3. Issues Exacerbated by the Use of DNS-ALG . . . . . . . . . . . 13
3.1. Network Topology Constraints Implied by NAT-PT . . . . . . 12 3.1. Network Topology Constraints Implied by NAT-PT . . . . . . 13
3.2. Scalability and Single Point of Failure Concerns . . . . . 14 3.2. Scalability and Single Point of Failure Concerns . . . . . 14
3.3. Issues with Lack of Address Persistence . . . . . . . . . 14 3.3. Issues with Lack of Address Persistence . . . . . . . . . 15
3.4. DoS Attacks on Memory and Address/Port Pools . . . . . . . 15 3.4. DoS Attacks on Memory and Address/Port Pools . . . . . . . 16
4. Issues Directly Related to Use of DNS-ALG . . . . . . . . . . 16 4. Issues Directly Related to Use of DNS-ALG . . . . . . . . . . 16
4.1. Address Selection Issues when Communicating with 4.1. Address Selection Issues when Communicating with
Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . . . 16 Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . . . 16
4.2. Non-global Validity of Translated RR Records . . . . . . . 17 4.2. Non-Global Validity of Translated RR Records . . . . . . . 18
4.3. Inappropriate Translation of Responses to A Queries . . . 18 4.3. Inappropriate Translation of Responses to A Queries . . . 19
4.4. DNS-ALG and Multi-addressed Nodes . . . . . . . . . . . . 18 4.4. DNS-ALG and Multi-Addressed Nodes . . . . . . . . . . . . 19
4.5. Limitations on Deployment of DNS Security Capabilities . . 18 4.5. Limitations on Deployment of DNS Security Capabilities . . 19
5. Impact on IPv6 Application Development . . . . . . . . . . . . 19 5. Impact on IPv6 Application Development . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 25
1. Introduction 1. Introduction
The Network Address Translator - Protocol Translator (NAT-PT) The Network Address Translator - Protocol Translator (NAT-PT)
document [RFC2766] defines a set of network-layer translation document [RFC2766] defines a set of network-layer translation
mechanisms designed to allow nodes that only support IPv4 to mechanisms designed to allow nodes that only support IPv4 to
communicate with nodes that only support IPv6 during the transition communicate with nodes that only support IPv6, during the transition
to the use of IPv6 in the Internet. to the use of IPv6 in the Internet.
[RFC2766] specifies the basic NAT-PT in which only addresses are [RFC2766] specifies the basic NAT-PT, in which only addresses are
translated and Network Address Port Translator - Protocol Translator translated, and the Network Address Port Translator - Protocol
(NAPT-PT), which also translates transport identifiers, allowing for Translator (NAPT-PT), which also translates transport identifiers,
greater economy of scarce IPv4 addresses. Protocol translation is allowing for greater economy of scarce IPv4 addresses. Protocol
performed using the Stateless IP/ICMP Translation Algorithm (SIIT) translation is performed using the Stateless IP/ICMP Translation
defined in [RFC2765]. In the following discussion, where the term Algorithm (SIIT) defined in [RFC2765]. In the following discussion,
"NAT-PT" is used unqualified, the discussion applies to both basic where the term "NAT-PT" is used unqualified, the discussion applies
NAT-PT and NAPT-PT. "Basic NAT-PT" will be used if points apply to to both basic NAT-PT and NAPT-PT. "Basic NAT-PT" will be used if
the basic address-only translator. points apply to the basic address-only translator.
A number of previous documents have raised issues with NAT-PT. This A number of previous documents have raised issues with NAT-PT. This
document will summarize these issues, note several other issues document will summarize these issues, note several other issues
carried over from traditional IPv4 NATs, and identify some additional carried over from traditional IPv4 NATs, and identify some additional
issues that have not been discussed elsewhere. Where solutions to issues that have not been discussed elsewhere. Proposed solutions to
the issues have been proposed, these are mentioned and any resulting the issues are mentioned and any resulting need for changes to the
need for changes to the specification is identified. specification is identified.
Whereas NAT is seen as an ongoing capability that is needed to work Whereas NAT is seen as an ongoing capability that is needed to work
around the limited availability of globally unique IPv4 addresses, around the limited availability of globally unique IPv4 addresses,
NAT-PT has a different status as a transition mechanism for IPv6. As NAT-PT has a different status as a transition mechanism for IPv6. As
such, NAT-PT should not be allowed to constrain the development of such, NAT-PT should not be allowed to constrain the development of
IPv6 applications or impose limitations on future developments of IPv6 applications or impose limitations on future developments of
IPv6. IPv6.
This document draws the conclusion that the technical and operational This document draws the conclusion that the technical and operational
difficulties resulting from these issues, especially the possible difficulties resulting from these issues, especially the possible
skipping to change at page 3, line 52 skipping to change at page 3, line 52
intercommunication between IPv6 networks and IPv4 networks. intercommunication between IPv6 networks and IPv4 networks.
Although the [RFC2766] form of packet translation is not generally Although the [RFC2766] form of packet translation is not generally
applicable, it is likely that in some circumstances a node that can applicable, it is likely that in some circumstances a node that can
only support IPv4 will need to communicate with a node that can only only support IPv4 will need to communicate with a node that can only
support IPv6; this needs a translation mechanism of some kind. support IPv6; this needs a translation mechanism of some kind.
Although this may be better carried out by an application-level proxy Although this may be better carried out by an application-level proxy
or transport-layer translator, there may still be scenarios in which or transport-layer translator, there may still be scenarios in which
a revised, possibly restricted version of NAT-PT can be a suitable a revised, possibly restricted version of NAT-PT can be a suitable
solution; accordingly, this document recommends that the IETF should solution; accordingly, this document recommends that the IETF should
reclassify RFC2766 from Proposed Standard to Historic status to avoid reclassify RFC 2766 from Proposed Standard to Historic status to
it being put into use in inappropriate scenarios while any avoid it from being used in inappropriate scenarios while any
replacement is developed. replacement is developed.
The following documents relating directly to NAT-PT have been The following documents relating directly to NAT-PT have been
reviewed while drafting this document: reviewed while drafting this document:
o Network Address Translation - Protocol Translation (NAT-PT) o Network Address Translation - Protocol Translation (NAT-PT)
[RFC2766] [RFC2766]
o Stateless IP/ICMP Translation Algorithm (SIIT) [RFC2765] o Stateless IP/ICMP Translation Algorithm (SIIT) [RFC2765]
o NAT-PT applicability statement
[I-D.satapati-v6ops-natpt-applicability] o NAT-PT Applicability Statement [NATP-APP]
o Issues with NAT-PT DNS ALG in RFC2766
[I-D.durand-natpt-dns-alg-issues] o Issues with NAT-PT DNS ALG (Application Layer Gateway) in RFC 2766
o NAT-PT DNS ALG solutions [I-D.hallin-natpt-dns-alg-solutions] [DNS-ALG-ISSUES]
o NAT-PT Security Considerations [I-D.okazaki-v6ops-natpt-security]
o Issues when translating between IPv4 and IPv6 o NAT-PT DNS ALG Solutions [DNS-ALG-SOL]
[I-D.vanderpol-v6ops-translation-issues]
o IPv6-IPv4 Translation mechanism for SIP-based services in Third o NAT-PT Security Considerations [NATPT-SEC]
Generation Partnership Project (3GPP) Networks
[I-D.elmalki-sipping-3gpp-translator] o Issues when Translating between IPv4 and IPv6 [TRANS-ISSUES]
o IPv6-IPv4 Translation Mechanism for SIP-Based Services in Third
Generation Partnership Project (3GPP) Networks [3GPP-TRANS]
o Analysis on IPv6 Transition in 3GPP Networks [RFC4215] o Analysis on IPv6 Transition in 3GPP Networks [RFC4215]
o Considerations for Mobile IP Support in NAT-PT
[I-D.lee-v6ops-natpt-mobility] o Considerations for Mobile IP Support in NAT-PT [NATPT-MOB]
o An IPv6/IPv4 Multicast Translator based on Internet Group
o An IPv6-IPv4 Multicast Translator based on Internet Group
Management Protocol / Multicast Listener Discovery (IGMP/MLD) Management Protocol / Multicast Listener Discovery (IGMP/MLD)
Proxying (mtp) [I-D.tsuchiya-mtp] Proxying (mtp) [MTP]
o An IPv4 - IPv6 multicast gateway [I-D.venaas-mboned-v4v6mcastgw]
o Scalable mNAT-PT Solution [I-D.park-scalable-multi-natpt] o An IPv4-IPv6 Multicast Gateway [MCASTGW]
o Scalable mNAT-PT Solution [MUL-NATPT]
Because the majority of the documents containing discussions of the Because the majority of the documents containing discussions of the
issues are Internet Drafts which are unlikely to become RFCs, the issues are documents that are unlikely to become RFCs, the issues are
issues are summarized here to avoid the need for normative summarized here to avoid the need for normative references.
references.
Some additional issues can be inferred from corresponding issues Some additional issues can be inferred from corresponding issues
known to exist in 'traditional' IPv4 NATs. The following documents known to exist in 'traditional' IPv4 NATs. The following documents
are relevant: are relevant:
o Protocol Complications with the IP Network Address Translator o Protocol Complications with the IP Network Address Translator
[RFC3027] [RFC3027]
o IP Network Address Translator (NAT) Terminology and Considerations o IP Network Address Translator (NAT) Terminology and Considerations
[RFC2663] [RFC2663]
There is some ambiguity in [RFC2766] about whether the Application There is some ambiguity in [RFC2766] about whether the Application
Layer Gateway (ALG) for DNS (referred to as DNS-ALG in this document) Layer Gateway (ALG) for DNS (referred to as DNS-ALG in this document)
is an integral and mandatory part of the specification. The is an integral and mandatory part of the specification. The
ambiguity arises mainly from the first section of the applicability ambiguity arises mainly from the first section of the applicability
section (Section 8), which appears to imply that 'simple' use of section (Section 8), which appears to imply that 'simple' use of
NAT-PT could avoid the use of the DNS-ALG. NAT-PT could avoid the use of the DNS-ALG.
skipping to change at page 5, line 18 skipping to change at page 5, line 30
[RFC2766] shows that the 'simple' case has not been worked out and it [RFC2766] shows that the 'simple' case has not been worked out and it
is unclear how information about the address translation could be is unclear how information about the address translation could be
passed to the hosts in the absence of the DNS-ALG. Therefore, this passed to the hosts in the absence of the DNS-ALG. Therefore, this
document assumes that the DNS-ALG is an integral part of NAT-PT; document assumes that the DNS-ALG is an integral part of NAT-PT;
accordingly, issues with the DNS-ALG must be considered as issues for accordingly, issues with the DNS-ALG must be considered as issues for
the whole specification. the whole specification.
Note that issues not specifically related to the use of the DNS-ALG Note that issues not specifically related to the use of the DNS-ALG
will apply to any network-layer translation scheme, including any will apply to any network-layer translation scheme, including any
based on the SIIT algorithm [RFC2765]. In the event that new forms based on the SIIT algorithm [RFC2765]. In the event that new forms
of translator are developed as alternatives to NAT-PT, the generic of a translator are developed as alternatives to NAT-PT, the generic
issues relevant to all IPv6-IPv4 translators should be borne in mind. issues relevant to all IPv6-IPv4 translators should be borne in mind.
Issues raised with IPv6-IPv4 translators in general and NAT-PT in Issues raised with IPv6-IPv4 translators in general and NAT-PT in
particular can be categorized as follows: particular can be categorized as follows:
o Issues that are independent of the use of a DNS-ALG and are, o Issues that are independent of the use of a DNS-ALG and are,
therefore, applicable to any form of IPv6-IPv4 translator: therefore, applicable to any form of an IPv6-IPv4 translator:
* Disruption of all protocols that embed IP addresses (and/or * Disruption of all protocols that embed IP addresses (and/or
ports) in packet payloads or apply integrity mechanisms using ports) in packet payloads or apply integrity mechanisms using
IP addresses (and ports). IP addresses (and ports).
* Inability to re-direct traffic for protocols that lack
* Inability to redirect traffic for protocols that lack
demultiplexing capabilities or are not built on top of specific demultiplexing capabilities or are not built on top of specific
transport-layer protocols in situations where one NAPT-PT is transport-layer protocols in situations where one NAPT-PT is
translating for multiple IPv6 hosts. translating for multiple IPv6 hosts.
* Requirement for applications to use keep alive mechanisms to * Requirement for applications to use keep alive mechanisms to
workaround connectivity issues caused by premature NAT-PT state workaround connectivity issues caused by premature NAT-PT state
timeout. timeout.
* Loss of information due to incompatible semantics between IPv4 * Loss of information due to incompatible semantics between IPv4
and IPv6 versions of headers and protocols. and IPv6 versions of headers and protocols.
* Need for additional state and/or packet reconstruction in * Need for additional state and/or packet reconstruction in
NAPT-PT translators dealing with packet fragmentation. NAPT-PT translators dealing with packet fragmentation.
* Interaction with SCTP and multihoming. * Interaction with SCTP and multihoming.
* Need for NAT-PT to act as proxy for correspondent node when * Need for NAT-PT to act as proxy for correspondent node when
IPv6 node is mobile, with consequent restrictions on mobility. IPv6 node is mobile, with consequent restrictions on mobility.
* NAT-PT not being able to handle multicast traffic. * NAT-PT not being able to handle multicast traffic.
o Issues that are exacerbated by the use of a DNS-ALG and are, o Issues that are exacerbated by the use of a DNS-ALG and are,
therefore, also applicable to any form of IPv6-IPv4 translator: therefore, also applicable to any form of an IPv6-IPv4 translator:
* Constraints on network topology. * Constraints on network topology.
* Scalability concerns together with introduction of single point
of failure and security attack nexus. * Scalability concerns together with introduction of a single
point of failure and a security attack nexus.
* Lack of address mapping persistence: Some applications require * Lack of address mapping persistence: Some applications require
address retention between sessions. The user traffic will be address retention between sessions. The user traffic will be
disrupted if a different mapping is used. The use of the DNS- disrupted if a different mapping is used. The use of the DNS-
ALG to create address mappings with limited lifetimes means ALG to create address mappings with limited lifetimes means
that applications must start using the address shortly after that applications must start using the address shortly after
the mapping is created, as well as keeping it alive once they the mapping is created, as well as keep it alive once they
start using it. start using it.
* Creation of a DoS threat relating to exhaustion of memory and
address/port pool resources on the translator. * Creation of a DoS (Denial of Service) threat relating to
exhaustion of memory and address/port pool resources on the
translator.
o Issues that result from the use of a DNS-ALG and are, therefore, o Issues that result from the use of a DNS-ALG and are, therefore,
specific to NAT-PT as defined in [RFC2766]: specific to NAT-PT as defined in [RFC2766]:
* Address selection issues when either the internal or external * Address selection issues when either the internal or external
hosts implement both IPv4 and IPv6. hosts implement both IPv4 and IPv6.
* Restricted validity of translated DNS records: a translated * Restricted validity of translated DNS records: a translated
record may be forwarded to an application that cannot use it. record may be forwarded to an application that cannot use it.
* Inappropriate translation of responses to A queries from IPv6 * Inappropriate translation of responses to A queries from IPv6
nodes. nodes.
* Address selection issues and resource consumption in DNS-ALG
* Address selection issues and resource consumption in a DNS-ALG
with multi-addressed nodes. with multi-addressed nodes.
* Limitations on DNS security capabilities when using DNS-ALG.
* Limitations on DNS security capabilities when using a DNS-ALG.
Section 2, Section 3 and Section 4 discuss these groups of issues. Section 2, Section 3 and Section 4 discuss these groups of issues.
Section 5 examines the consequences of deploying NAT-PT for Section 5 examines the consequences of deploying NAT-PT for
application developers and the long term effects of NAT-PT (or any application developers and the long term effects of NAT-PT (or any
form of generally deployed IPv6-IPv4 translator) on the further form of generally deployed IPv6-IPv4 translator) on the further
development of IPv6. development of IPv6.
The terminology used in this document is defined in [RFC2663], The terminology used in this document is defined in [RFC2663],
[RFC2766], and [RFC3314]. [RFC2766], and [RFC3314].
2. Issues Unrelated to DNS-ALG 2. Issues Unrelated to an DNS-ALG
2.1. Issues with Protocols Embedding IP Addresses 2.1. Issues with Protocols Embedding IP Addresses
It is well known from work on IPv4 NATs (see Section 8 of [RFC2663] It is well known from work on IPv4 NATs (see Section 8 of [RFC2663]
and [RFC3027]) that the large class of protocols that embed numeric and [RFC3027]) that the large class of protocols that embed numeric
IP addresses in their payloads either cannot work through NATs or IP addresses in their payloads either cannot work through NATs or
require specific ALGs as helpers to translate the payloads in line require specific ALGs as helpers to translate the payloads in line
with the address and port translations. The same set of protocols with the address and port translations. The same set of protocols
cannot pass through NAT-PT. The problem is exacerbated because the cannot pass through NAT-PT. The problem is exacerbated because the
IPv6 and IPv4 addresses are of different lengths so that packet IPv6 and IPv4 addresses are of different lengths, so that packet
lengths as well as contents are altered. [RFC2766] describes the lengths as well as packet contents are altered. [RFC2766] describes
consequences as part of the description of the FTP ALG: similar the consequences as part of the description of the FTP ALG. Similar
workarounds are needed for all protocols with embedded IP addresses workarounds are needed for all protocols with embedded IP addresses
that run over TCP transports. that run over TCP transports.
The issues raised in Sections 2 and 3 of [RFC2663], relating to The issues raised in Sections 2 and 3 of [RFC2663], relating to the
authentication and encryption with NAT, are also applicable to authentication and encryption with NAT, are also applicable to
NAT-PT. NAT-PT.
Implementing a suite of ALGs requires that NAT-PT equipment includes Implementing a suite of ALGs requires that NAT-PT equipment includes
the logic for each of the relevant protocols. Most of these the logic for each of the relevant protocols. Most of these
protocols are continuously evolving, requiring continual and protocols are continuously evolving, requiring continual and
coordinated updates of the ALGs to keep them in step. coordinated updates of the ALGs to keep them in step.
Assuming that the NAT-PT contains a co-located ALG for one of the Assuming that the NAT-PT contains a colocated ALG for one of the
relevant protocols, the ALG could replace the embedded IP addresses relevant protocols, the ALG could replace the embedded IP addresses
and ports. However, this replacement can only happen if no and ports. However, this replacement can only happen if no
cryptographic integrity mechanism is used and the protocol messages cryptographic integrity mechanism is used and the protocol messages
are sent in the clear (i.e., not encrypted). are sent in the clear (i.e., not encrypted).
A possible workaround relies on the NAT-PT being party to the A possible workaround relies on the NAT-PT being party to the
security association used to provide authentication and/or security association used to provide authentication and/or
encryption. NAT-PT would then be aware of the cryptographic encryption. NAT-PT would then be aware of the cryptographic
algorithms and keys used to secure the traffic. It could then modify algorithms and keys used to secure the traffic. It could then modify
and re-secure the packets; this would certainly complicate network and re-secure the packets; this would certainly complicate network
operations and provides additional points of security vulnerability. operations and provide additional points of security vulnerability.
Unless UDP encapsulation is used for IPsec [RFC3498], traffic using Unless UDP encapsulation is used for IPsec [RFC3498], traffic using
IPsec AH (in transport and tunnel mode) and IPsec ESP (in transport IPsec AH (Authentication Header), in transport and tunnel mode, and
mode) is unable to be carried through NAT-PT without terminating the IPsec ESP (Encapsulating Security Payload), in transport mode, is
security associations on the NAT-PT, due to their usage of unable to be carried through NAT-PT without terminating the security
cryptographic integrity protection. associations on the NAT-PT, due to their usage of cryptographic
integrity protection.
A related issue with DNS security is discussed in Section 4.5. A related issue with DNS security is discussed in Section 4.5.
2.2. NAPT-PT Redirection Issues 2.2. NAPT-PT Redirection Issues
Section 4.2 of [RFC3027] discusses problems specific to RSVP and Section 4.2 of [RFC3027] discusses problems specific to RSVP and
NATs, one of which is actually a more generic problem for all port NATs, one of which is actually a more generic problem for all port
translators. When several end-hosts are using a single NAPT-PT box, translators. When several end-hosts are using a single NAPT-PT box,
protocols that do not have a demultiplexing capability similar to protocols that do not have a demultiplexing capability similar to
transport-layer port numbers may be unable to work through NAPT-PT transport-layer port numbers may be unable to work through NAPT-PT
(and any other port translator) because there is nothing for NAPT-PT (and any other port translator) because there is nothing for NAPT-PT
to use to identify the correct binding. to use to identify the correct binding.
This type of issue affects IPsec encrypted packets where the This type of issue affects IPsec encrypted packets where the
transport port is not visible (although it might be possible to use transport port is not visible (although it might be possible to use
the Security Parameter Index (SPI) as an alternative demultiplexer) the Security Parameter Index (SPI) as an alternative demultiplexer),
and protocols, such as RSVP, which are carried directly in IP and protocols, such as RSVP, which are carried directly in IP
datagrams rather than using a standard transport-layer protocol such datagrams rather than using a standard transport-layer protocol such
as TCP or UDP. In the case of RSVP, packets going from the IPv4 as TCP or UDP. In the case of RSVP, packets going from the IPv4
domain to the IPv6 domain do not necessarily carry a suitable domain to the IPv6 domain do not necessarily carry a suitable
demultiplexing field, because the port fields in the flow identifier demultiplexing field, because the port fields in the flow identifier
and traffic specifications are optional. and traffic specifications are optional.
Several ad hoc workarounds could be used to solve the demultiplexing Several ad hoc workarounds could be used to solve the demultiplexing
issues, however in most cases these solutions are not documented issues, however in most cases these solutions are not documented
anywhere, which could lead to non-deterministic, undesirable behavior anywhere, which could lead to non-deterministic and undesirable
(for example, such workarounds often assume particular network behavior (for example, such workarounds often assume particular
topologies, etc., in order to function correctly; if the assumptions network topologies, etc., in order to function correctly; if the
are not met in a deployment, the workaround may not work as assumptions are not met in a deployment, the workaround may not work
expected). as expected).
This issue is closely related to the fragmentation issue described in This issue is closely related to the fragmentation issue described in
Section 2.5. Section 2.5.
2.3. NAT-PT Binding State Decay 2.3. NAT-PT Binding State Decay
NAT-PT will generally use dynamically created bindings to reduce the NAT-PT will generally use dynamically created bindings to reduce the
need for IPv4 addresses both for basic NAT-PT and NAPT-PT. Both need for IPv4 addresses both for basic NAT-PT and NAPT-PT. Both
basic NAT-PT and NAPT-PT use soft state mechanisms to manage the basic NAT-PT and NAPT-PT use soft state mechanisms to manage the
address and, in the case of NAPT-PT, port pools used for dynamically address and, in the case of NAPT-PT, port pools are used for
created address bindings. This allows all types of NAT-PT box to dynamically created address bindings. This allows all types of
operate autonomously without requiring clients to signal, either NAT-PT boxes to operate autonomously without requiring clients to
implicitly or explicitly, that a binding is no longer required. In signal, either implicitly or explicitly, that a binding is no longer
any case, without soft state timeouts, network and application required. In any case, without soft state timeouts, network and
unreliability would inevitably lead to leaks, eventually causing application unreliability would inevitably lead to leaks, eventually
address or port pool exhaustion. causing address or port pool exhaustion.
For a dynamic binding to persist for longer than the soft state For a dynamic binding to persist for longer than the soft state
timeout, packets must be sent periodically from one side of the timeout, packets must be sent periodically from one side of the
NAT-PT to the other (the direction is not specified by the NAT-PT NAT-PT to the other (the direction is not specified by the NAT-PT
specification). If no packets are sent in the proper direction, the specification). If no packets are sent in the proper direction, the
NAT-PT binding will not be refreshed and the application connection NAT-PT binding will not be refreshed and the application connection
will be broken. Hence, all applications need to maintain their will be broken. Hence, all applications need to maintain their
NAT-PT bindings during long idle periods by incorporating a keep- NAT-PT bindings during long idle periods by incorporating a keepalive
alive mechanism, which may not be possible for legacy systems. mechanism, which may not be possible for legacy systems.
Also, [RFC2766] does not specify how to choose timeouts for bindings. Also, [RFC2766] does not specify how to choose timeouts for bindings.
As is discussed in [RFC2663] for traditional NATs, selecting suitable As discussed in [RFC2663] for traditional NATs, selecting suitable
values is a matter of heuristics, and coordinating with application values is a matter of heuristics, and coordinating with application
expectations may be impossible. expectations may be impossible.
2.4. Loss of Information through Incompatible Semantics 2.4. Loss of Information through Incompatible Semantics
NAT-PT reuses the SIIT header and protocol translations defined in NAT-PT reuses the SIIT header and protocol translations defined in
[RFC2765]. Mismatches in semantics between IPv4 and IPv6 versions [RFC2765]. Mismatches in semantics between IPv4 and IPv6 versions
can lead to loss of information when packets are translated. Three can lead to loss of information when packets are translated. Three
issues arising from this are: issues arising from this are:
o There is no equivalent in IPv4 for the flow label field of the o There is no equivalent in IPv4 for the flow label field of the
IPv6 header. Hence, any special treatment of packets based on IPv6 header. Hence, any special treatment of packets based on
flow label patterns cannot be propagated into the IPv4 domain. flow label patterns cannot be propagated into the IPv4 domain.
o IPv6 extension headers provide flexibility for improvements in the
IP protocol suite in future. In the future, new headers may be o IPv6 extension headers provide flexibility for future improvements
defined that do not have equivalents in IPv4. In practice, some in the IP protocol suite and new headers that do not have
existing extensions such as routing headers and mobility equivalents in IPv4 may be defined. In practice, some existing
extensions are not translatable. extensions such as routing headers and mobility extensions are not
o As described in Section 2.2 of translatable.
[I-D.satapati-v6ops-natpt-applicability], there are no equivalents
in IPv6 for some ICMP(v4) messages, while for others (notably the o As described in Section 2.2 of [NATP-APP], there are no
'Parameter Problem' messages) the semantics are not equivalent. equivalents in IPv6 for some ICMP(v4) messages, while for others
Translation of such messages may lead to loss of information. (notably the 'Parameter Problem' messages) the semantics are not
However, this issue may not be very severe because the error equivalent. Translation of such messages may lead to the loss of
messages relate to packets that have been translated by NAT-PT information. However, this issue may not be very severe because
rather than arbitrary packets. If the NAT-PT is functioning the error messages relate to packets that have been translated by
correctly, there is, for example, no reason why IPv6 packets with NAT-PT rather than by arbitrary packets. If the NAT-PT is
unusual extension headers or options should be generated. This functioning correctly, there is, for example, no reason why IPv6
case is cited in [I-D.satapati-v6ops-natpt-applicability] as an packets with unusual extension headers or options should be
example where the IPv6 error has no equivalent in IPv4 resulting generated.
in lost information.
Loss of information in any of these cases could be a constraint to Loss of information in any of these cases could be a constraint to
certain applications. certain applications.
A related matter concerns the propagation of the Differentiated A related matter concerns the propagation of the Differentiated
Services Code Point (DSCP). NAT-PT and SIIT simply copy the DSCP Services Code Point (DSCP). NAT-PT and SIIT simply copy the DSCP
field when translating packets. Accordingly, the IPv4 and IPv6 field when translating packets. Accordingly, the IPv4 and IPv6
domains must have equivalent Per-Hop Behaviors for the same code domains must have equivalent Per-Hop Behaviors for the same code
point, or alternative means must be in place to translate the DSCP point, or alternative means must be in place to translate the DSCP
between domains. between domains.
2.5. NAT-PT and Fragmentation 2.5. NAT-PT and Fragmentation
As mentioned in [RFC3027], simple port translators are unable to As mentioned in [RFC3027], simple port translators are unable to
translate packet fragments, other than the first, from a fragmented translate packet fragments, other than the first, from a fragmented
packet, because subsequent fragments do not contain the port number packet, because subsequent fragments do not contain the port number
information. information.
This means that generally fragmentation cannot be allowed for any This means that, in general, fragmentation cannot be allowed for any
traffic that traverses a NAPT-PT. One attempted workaround requires traffic that traverses a NAPT-PT. One attempted workaround requires
the NAPT-PT to maintain state about fragmented packets in transit. the NAPT-PT to maintain state information derived from the first
This is not a complete solution because fragment misordering could fragment until all fragments of the packet have transited the
lead to the first fragment appearing at the NAPT-PT after later NAPT-PT. This is not a complete solution because fragment
fragments. The NAPT-PT would then not have the information needed to misordering could lead to the first fragment appearing at the NAPT-PT
translate the fragments received before the first. after later fragments. Consequently, the NAPT-PT would not have the
information needed to translate the fragments received before the
first.
Although it would not be expected in normal operation, NAPT-PT needs Although it would not be expected in normal operation, NAPT-PT needs
to be proofed against receiving short first fragments that don't to be proofed against receiving short first fragments that don't
contain the transport port numbers. Note that such packets are a contain the transport port numbers. Note that such packets are a
problem for IPv6 stateful packet inspection. The current problem for many forms of stateful packet inspection applied to IPv6
specifications of IPv6 do not mandate (1) any minimum packet size packets. The current specifications of IPv6 do not mandate (1) any
beyond the need to carry the unfragmentable part (which doesn't minimum packet size beyond the need to carry the unfragmentable part
include the transport port numbers) or (2) reassembly rules to (which doesn't include the transport port numbers) or (2) reassembly
minimize the effects of overlapping fragments. Thus, IPv6 is open to rules to minimize the effects of overlapping fragments. Thus, IPv6
the sort of attacks described in [RFC1858] and [RFC3128]. is open to the sort of attacks described in [RFC1858] and [RFC3128].
An additional concern arises when a fragmented IPv4 UDP packet, which An additional concern arises when a fragmented IPv4 UDP packet, which
does not have a transport-layer checksum, traverses any type of does not have a transport-layer checksum, traverses any type of
NAT-PT box. As described in [RFC2766], the NAT-PT has to reconstruct NAT-PT box. As described in [RFC2766], the NAT-PT has to reconstruct
the whole packet so that it can calculate the checksum needed for the the whole packet so that it can calculate the checksum needed for the
translated IPv6 packet. This can result in significant delay to the translated IPv6 packet. This can result in a significant delay to
packet, especially if it has to be re-fragmented before transmission the packet, especially if it has to be re-fragmented before
on the IPv6 side. transmission on the IPv6 side.
If NAT-PT boxes reassembled all incoming fragmented packets (both If NAT-PT boxes reassembled all incoming fragmented packets (both
from the IPv4 and IPv6 directions) in the same way as they have to do from the IPv4 and IPv6 directions) in the same way they have to for
for unchecksummed IPv4 UDP packets, this would be a solution to the unchecksummed IPv4 UDP packets, this would be a solution to the first
first problem. The resource cost would be considerable apart from problem. The resource cost would be considerable apart from the
the potential delay problem if the outgoing packet has to be re- potential delay problem if the outgoing packet has to be re-
fragmented. In any case, fragmentation would mean that the NAT-PT fragmented. In any case, fragmentation would mean that the NAT-PT
would consume extra memory and CPU resources, making the NAT-PT even would consume extra memory and CPU resources, making the NAT-PT even
less scalable (see Section 3.2). less scalable (see Section 3.2).
Packet reassembly in a NAT-PT box also opens up the possibility of Packet reassembly in a NAT-PT box also opens up the possibility of
various fragment-related security attacks. Some of these are various fragment-related security attacks. Some of these are
analogous to attacks identified for IPv4. Of particular concern is a analogous to attacks identified for IPv4. Of particular concern is a
DoS attack based on sending large numbers of small fragments without DoS attack based on sending large numbers of small fragments without
a terminating last fragment, which would potentially overload the a terminating last fragment, which would potentially overload the
reconstruction buffers and consume large amounts of CPU resources. reconstruction buffers and consume large amounts of CPU resources.
2.6. NAT-PT Interaction with SCTP and Multihoming 2.6. NAT-PT Interaction with SCTP and Multihoming
The Stream Control Transmission Protocol (SCTP) [RFC2960] is a The Stream Control Transmission Protocol (SCTP) [RFC2960] is a
transport protocol, which has been standardized since SIIT was transport protocol, which has been standardized since SIIT was
specified. SIIT does not explicitly cover translation of SCTP, but specified. SIIT does not explicitly cover the translation of SCTP,
SCTP uses transport port numbers in the same way as UDP and TCP so but SCTP uses transport port numbers in the same way that UDP and TCP
that similar techniques could be used. do, so similar techniques can be used when translating SCTP packets.
However, SCTP also supports multihoming. During connection setup, However, SCTP also supports multihoming. During connection setup,
SCTP control packets carry embedded addresses that would have to be SCTP control packets carry embedded addresses that would have to be
translated. This would also require that the types of the options translated. This would also require that the types of the options
fields in the SCTP control packets be changed with consequent changes fields in the SCTP control packets be changed with consequent changes
to packet length; the transport checksum would also have to be to packet length; the transport checksum would also have to be
recalculated. The ramifications of multihoming as it might interact recalculated. The ramifications of multihoming as it might interact
with NAT-PT have not been fully explored. Because of the 'chunked' with NAT-PT have not been fully explored. Because of the 'chunked'
nature of data transfer, it does not appear that state would have to nature of data transfer, it does not appear that that state would
be maintained to relate packets transmitted using the different IP have to be maintained to relate packets transmitted using the
addresses associated with the connection. different IP addresses associated with the connection.
Even if these technical issues can be overcome, using SCTP in a Even if these technical issues can be overcome, using SCTP in a
NAT-PT environment may effectively nullify the multihoming advantages NAT-PT environment may effectively nullify the multihoming advantages
of SCTP if all the connections run through the same NAT-PT. The of SCTP if all the connections run through the same NAT-PT. The
consequences of running a multihomed network with separate NAT-PT consequences of running a multihomed network with separate NAT-PT
boxes associated with each of the 'homes' have not been fully boxes associated with each of the 'homes' have not been fully
explored, but one issue that will arise is described in Section 4.4. explored, but one issue that will arise is described in Section 4.4.
SCTP will need an associated 'ALG' -- actually a Transport Layer SCTP will need an associated "ALG" -- actually a Transport Layer
Gateway -- to handle the packet payload modifications. If it turns Gateway -- to handle the packet payload modifications. If it turns
out that state is required, the state would have to distributed and out that that state is required, the state would have to be
synchronized across several NAT-PT boxes in a multihomed environment. distributed and synchronized across several NAT-PT boxes in a
multihomed environment.
SCTP running through NAT-PT in a multihomed environment is also SCTP running through NAT-PT in a multihomed environment is also
incompatible with IPsec as described in Section 2.1. incompatible with IPsec as described in Section 2.1.
2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 2.7. NAT-PT as a Proxy Correspondent Node for MIPv6
As discussed in [I-D.lee-v6ops-natpt-mobility], it is not possible to As discussed in [NATPT-MOB], it is not possible to propagate Mobile
propagate Mobile IPv6 control messages into the IPv4 domain. IPv6 (MIPv6) control messages into the IPv4 domain. According to the
According to the IPv6 Node Requirements [RFC4294], IPv6 nodes should IPv6 Node Requirements [RFC4294], IPv6 nodes should normally be
normally be prepared to support the route optimization mechanisms prepared to support the route optimization mechanisms needed in a
needed in a correspondent node. If communications from an IPv6 correspondent node. If communications from an IPv6 mobile node are
mobile node are traversing a NAT-PT, the destination IPv4 node will traversing a NAT-PT, the destination IPv4 node will certainly not be
certainly not be able to support the correspondent node features able to support the correspondent node features needed for route
needed for route optimization. optimization.
This can be resolved in two ways: This can be resolved in two ways:
o The NAT-PT can discard messages and headers relating to changes of o The NAT-PT can discard messages and headers relating to changes of
care-of addresses, including reverse routing checks. care-of addresses, including reverse routing checks.
Communications with the mobile node will continue through the home Communications with the mobile node will continue through the home
agent without route optimization. This is clearly sub-optimal, agent without route optimization. This is clearly sub-optimal,
but communication should remain possible. but communication should remain possible.
o Additional functionality could be implemented in the NAT-PT to o Additional functionality could be implemented in the NAT-PT to
allow it to function as a proxy correspondent node for all IPv4 allow it to function as a proxy correspondent node for all IPv4
nodes for which it has bindings. This scheme adds considerably to nodes for which it has bindings. This scheme adds considerably to
the complexity of NAT-PT. Depending on the routability of the the complexity of NAT-PT. Depending on the routability of the
IPv6 PREFIX used for translated IPv4 addresses, it may also limit IPv6 PREFIX used for translated IPv4 addresses, it may also limit
the extent of mobility of the mobile node: all communications to the extent of mobility of the mobile node: all communications to
the IPv4 destination have to go through the same NAT-PT, even if the IPv4 destination have to go through the same NAT-PT, even if
the mobile node moves to a network that does not have direct IPv6 the mobile node moves to a network that does not have direct IPv6
connectivity with the NAT-PT. connectivity with the NAT-PT.
skipping to change at page 12, line 8 skipping to change at page 12, line 43
the IPv4 destination have to go through the same NAT-PT, even if the IPv4 destination have to go through the same NAT-PT, even if
the mobile node moves to a network that does not have direct IPv6 the mobile node moves to a network that does not have direct IPv6
connectivity with the NAT-PT. connectivity with the NAT-PT.
In both cases, the existing NAT-PT specification would need to be In both cases, the existing NAT-PT specification would need to be
extended to deal with IPv6 mobile nodes, and neither is a fully extended to deal with IPv6 mobile nodes, and neither is a fully
satisfactory solution. satisfactory solution.
2.8. NAT-PT and Multicast 2.8. NAT-PT and Multicast
SIIT [RFC2765] cannot handle translation of multicast packets and SIIT [RFC2765] cannot handle the translation of multicast packets and
NAT-PT does not discuss a way to map multicast addresses between IPv4 NAT-PT does not discuss a way to map multicast addresses between IPv4
and IPv6. Some separate work has been done to provide an alternative and IPv6. Some separate work has been done to provide an alternative
mechanism to handle multicast. This uses a separate gateway that mechanism to handle multicast. This work uses a separate gateway
understands some or all of the relevant multicast control and routing that understands some or all of the relevant multicast control and
protocols in each domain. This work has not been carried through routing protocols in each domain. It has not yet been carried
into standards as yet. through into standards.
A basic mechanism, which involves only IGMP on the IPv4 side and MLD A basic mechanism, which involves only IGMP on the IPv4 side and MLD
on the IPv6 side, is described in 'An IPv6/IPv4 Multicast Translator on the IPv6 side, is described in 'An IPv6-IPv4 Multicast Translator
based on IGMP/MLD Proxying (mtp)' [I-D.tsuchiya-mtp]. A more based on IGMP/MLD Proxying (mtp)' [MTP]. A more comprehensive
comprehensive approach, which includes proxying of the multicast approach, which includes proxying of the multicast routing protocols,
routing protocols, is described in 'An IPv4 - IPv6 multicast gateway' is described in 'An IPv4 - IPv6 multicast gateway' [MCASTGW]. Both
[I-D.venaas-mboned-v4v6mcastgw]. Both approaches have several of the approaches have several of the issues described in this section,
issues described in this section, notably issues with embedded notably issues with embedded addresses.
addresses.
[I-D.okazaki-v6ops-natpt-security] identifies the possibility of a [NATPT-SEC] identifies the possibility of a multiplicative reflection
multiplicative reflection attack if the NAT-PT can be spoofed into attack if the NAT-PT can be spoofed into creating a binding for a
creating a binding for a multicast address. This attack would be multicast address. This attack would be very hard to mount because
very hard to mount because routers should not forward packets with routers should not forward packets with multicast addresses in the
multicast addresses in the source address field. However, it source address field. However, it highlights the possibility that a
highlights the possibility that a naively implemented DNS-ALG could naively implemented DNS-ALG could create such bindings from spoofed
create such bindings from spoofed DNS responses since [RFC2766] does DNS responses since [RFC2766] does not mention the need for checks on
not mention the need for checks on the types of addresses in these the types of addresses in these responses.
responses.
The issues for NAT-PT and multicast reflect the fact that NAT-PT is The issues for NAT-PT and multicast reflect the fact that NAT-PT is
at best a partial solution. Completing the translation solution to at best a partial solution. Completing the translation solution to
cater for multicast traffic is likely to carry a similar set of cater for multicast traffic is likely to carry a similar set of
issues to the current unicast NAT-PT and may open up significant issues to the current unicast NAT-PT and may open up significant
additional security risks. additional security risks.
3. Issues exacerbated by the Use of DNS-ALG 3. Issues Exacerbated by the Use of DNS-ALG
3.1. Network Topology Constraints Implied by NAT-PT 3.1. Network Topology Constraints Implied by NAT-PT
Traffic flow initiators in a NAT-PT environment are dependent on the Traffic flow initiators in a NAT-PT environment are dependent on the
DNS-ALG in the NAT-PT to provide the mapped address needed to DNS-ALG in the NAT-PT to provide the mapped address needed to
communicate with the flow destination on the other side of the communicate with the flow destination on the other side of the
NAT-PT. Whether used for flows initiated in the IPv4 domain or the NAT-PT. Whether used for flows initiated in the IPv4 domain or the
IPv6 domain, the NAT-PT has to be on the path taken by the DNS query IPv6 domain, the NAT-PT has to be on the path taken by the DNS query
sent by the flow initiator to the relevant DNS server; otherwise, the sent by the flow initiator to the relevant DNS server; otherwise, the
DNS query will not be modified and the response type would not be DNS query will not be modified and the response type will not be
appropriate. appropriate.
The implication is that the NAT-PT box also has to be the default The implication is that the NAT-PT box also has to be the default
IPv6 router for the site so that the DNS-ALG is able to examine all IPv6 router for the site so that the DNS-ALG is able to examine all
DNS requests made over IPv6. On sites with both IPv6 and dual-stack DNS requests made over IPv6. On sites with both IPv6 and dual-stack
nodes, this will result in all traffic flowing through the NAT-PT nodes, this will result in all traffic flowing through the NAT-PT
with consequent scalability concerns. with consequent scalability concerns.
These constraints are described in more detail in These constraints are described in more detail in [DNS-ALG-ISSUES].
[I-D.durand-natpt-dns-alg-issues].
[I-D.hallin-natpt-dns-alg-solutions] proposes a solution for flows [DNS-ALG-SOL] proposes a solution for flows initiated from the IPv6
initiated from the IPv6 domain, but it appears that this solution domain, but it appears that this solution still has issues.
still has issues.
For IPv6-only clients, the solution requires the use of a DNS server For IPv6-only clients, the solution requires the use of a DNS server
in the IPv4 domain accessed via an IPv6 address which uses the NAT-PT in the IPv4 domain, accessed via an IPv6 address which uses the
PREFIX (see [RFC2766]). Queries to this server would necessarily NAT-PT PREFIX (see [RFC2766]). Queries to this server would
pass through the NAT-PT. Dual-stack hosts would use a separate DNS necessarily pass through the NAT-PT. Dual-stack hosts would use a
server accessed through a normal IPv6 address. This removes the need separate DNS server accessed through a normal IPv6 address. This
for the NAT-PT box to be the default IPv6 gateway for the domain. removes the need for the NAT-PT box to be the default IPv6 gateway
for the domain.
The primary proposal suggests that the IPv6-only clients should use The primary proposal suggests that the IPv6-only clients should use
this DNS server for all queries. This is expensive on NAT-PT this DNS server for all queries. This is expensive on NAT-PT
resources because requests relating to hosts with native IPv6 resources because requests relating to hosts with native IPv6
addresses would also use the NAT-PT DNS-ALG. addresses would also use the NAT-PT DNS-ALG.
The alternate suggestion to reduce this burden appears to be flawed: The alternate suggestion to reduce this burden appears to be flawed:
if IPv6-only clients are provided with a list of DNS servers if IPv6-only clients are provided with a list of DNS servers
including both the server accessed via NAT-PT and server(s) accessed including both the server accessed via NAT-PT and server(s) accessed
natively via IPv6, the proposal suggests that the client could avoid natively via IPv6, the proposal suggests that the client could avoid
using NAT-PT for hosts that have native IPv6 addresses. using NAT-PT for hosts that have native IPv6 addresses.
Unfortunately for the alternate suggestion, there is no a priori way Unfortunately, for the alternate suggestion, there is no a priori way
in which the initiator can decide which DNS server to use for a in which the initiator can decide which DNS server to use for a
particular query. In the event that the initiator makes the wrong particular query. In the event that the initiator makes the wrong
choice, the DNS query will return an empty list rather than failing choice, the DNS query will return an empty list rather than failing
to respond. With standard DNS logic, the initiator will not try to respond. With standard DNS logic, the initiator will not try
alternative DNS servers because it has received a response. This alternative DNS servers because it has received a response. This
means that the solution would consist of always using DNS servers means that the solution would consist of always using DNS servers
having the NAT-PT prefix. This imposes the burden of always having the NAT-PT PREFIX. This imposes the burden of always
requiring DNS RR [RFC1035] translation. requiring the DNS RR (Resource Record) [RFC1035] translation.
For flows initiated from the IPv4 network, the proposal recommends For flows initiated from the IPv4 network, the proposal recommends
that the advertised DNS servers for the IPv6 network would have the that the advertised DNS servers for the IPv6 network would have the
IPv4 address of the NAT-PT. Again there is no deterministic way to IPv4 address of the NAT-PT. Again there is no deterministic way to
choose the correct DNS server for each query resulting in the same choose the correct DNS server for each query resulting in the same
issues as were raised for flows initiated from the IPv6 domain. issues as were raised for flows initiated from the IPv6 domain.
Although the engineering workaround, just described, provides a Although the engineering workaround, just described, provides a
partial solution to the topology constraints issue, it mandates that partial solution to the topology constraints issue, it mandates that
DNS queries and responses should still go through a NAT-PT even if DNS queries and responses should still go through a NAT-PT even if
there would normally be no reason to do so. This mandatory passage there would normally be no reason to do so. This mandatory passage
through the NAT-PT for all DNS requests will exacerbate the other through the NAT-PT for all DNS requests will exacerbate the other
DNS-related issues discussed in Section 3.4 and Section 4.1. DNS-related issues discussed in Section 3.4 and Section 4.1.
3.2. Scalability and Single Point of Failure Concerns 3.2. Scalability and Single Point of Failure Concerns
As with traditional NAT, NAT-PT is a bottleneck in the network with As with traditional NAT, NAT-PT is a bottleneck in the network with
significant scalability concerns and the anchoring of flows to a significant scalability concerns. Furthermore, the anchoring of
particular NAT-PT makes the NAT-PT a potential single point of flows to a particular NAT-PT makes the NAT-PT a potential single
failure in the network. The addition of the DNS-ALG in NAT-PT point of failure in the network. The addition of the DNS-ALG in
further increases the scalability concerns. NAT-PT further increases the scalability concerns.
Solutions to both problems have been envisaged using collections of Solutions to both problems have been envisaged using collections of
cooperating NAT-PT boxes, but such solutions require coordination and cooperating NAT-PT boxes, but such solutions require coordination and
state synchronization, which has not yet been standardized and again state synchronization, which has not yet been standardized and again
adds to the functional and operational complexity of NAT-PT. One adds to the functional and operational complexity of NAT-PT. One
such solution is described in [I-D.park-scalable-multi-natpt]. such solution is described in [MUL-NATPT].
As with traditional NAT, the concentration of flows through NAT-PT As with traditional NAT, the concentration of flows through NAT-PT
and the legitimate modification of packets in the NAT-PT make NAT-PTs and the legitimate modification of packets in the NAT-PT make NAT-PTs
enticing targets for security attacks. enticing targets for security attacks.
3.3. Issues with Lack of Address Persistence 3.3. Issues with Lack of Address Persistence
Using the DNS-ALG to create address bindings requires that the Using the DNS-ALG to create address bindings requires that the
application uses the translated address returned by the DNS query translated address returned by the DNS query is used for
before the NAT-PT binding state is timed out (see Section 2.3). communications before the NAT-PT binding state is timed out (see
Applications will not normally be aware of this constraint, which may Section 2.3). Applications will not normally be aware of this
be different from the existing lifetime of DNS query responses. This constraint, which may be different from the existing lifetime of DNS
could lead to "difficult to diagnose" problems with applications. query responses. This could lead to "difficult to diagnose" problems
with applications.
Additionally, the DNS-ALG needs to determine the initial lifetime of Additionally, the DNS-ALG needs to determine the initial lifetime of
bindings that it creates. As noted in Section 2.3, this may need to bindings that it creates. As noted in Section 2.3, this may need to
be determined heuristically. The DNS-ALG does not know which be determined heuristically. The DNS-ALG does not know which
protocol the mapping is to be used for, and so needs another way to protocol the mapping is to be used for, and so needs another way to
determine the initial lifetime. This could be tied to the DNS determine the initial lifetime. This could be tied to the DNS
response lifetime, but that might open up additional DoS attack response lifetime, but that might open up additional DoS attack
possibilities if very long validities are allowed. Also, the possibilities if very long binding lifetimes are allowed. Also, the
lifetime should be adjusted once the NAT-PT determines which protocol lifetime should be adjusted once the NAT-PT determines which protocol
is being used with the binding. is being used with the binding.
As with traditional NATs (see Section 2.5 of [RFC3027], NAT-PT will As with traditional NATs (see Section 2.5 of [RFC3027]), NAT-PT will
most likely break applications that require address mapping to be most likely break applications that require address mapping to be
retained across contiguous sessions. These applications require the retained across contiguous sessions. These applications require the
IPv4 to IPv6 address mapping to be retained between sessions so the IPv4 to IPv6 address mapping to be retained between sessions so the
same mapped address may be reused for subsequent session same mapped address may be reused for subsequent session
interactions. NAT-PT cannot know this requirement and may reassign interactions. NAT-PT cannot know this requirement and may reassign
the previously used mapped address to different hosts between the previously used mapped address to different hosts between
sessions. sessions.
Trying to keep NAT-PT from discarding an address mapping would Trying to keep NAT-PT from discarding an address mapping would
require either a NAT-PT extension protocol that would allow the require either a NAT-PT extension protocol that would allow the
application to request the NAT-PT device to retain the mappings, or application to request the NAT-PT device to retain the mappings, or
an extended ALG (which has all the issues discussed in Section 2.1) an extended ALG (which has all the issues discussed in Section 2.1)
that can interact with NAT-PT to keep the address mapping from being that can interact with NAT-PT to keep the address mapping from being
discarded after a session. discarded after a session.
3.4. DoS Attacks on Memory and Address/Port Pools 3.4. DoS Attacks on Memory and Address/Port Pools
As discussed in Section 2.3, a NAT-PT may create dynamic NAT As discussed in Section 2.3, a NAT-PT may create dynamic NAT
bindings, each of which consumes memory resources as well as an bindings, each of which consumes memory resources as well as an
address (or port if NAPT-PT is used) from an address (or port) pool. address (or port if NAPT-PT is used) from an address (or port) pool.
A number of documents, including [RFC2766] and A number of documents, including [RFC2766] and [NATPT-SEC] discuss
[I-D.okazaki-v6ops-natpt-security] discuss possible denial of service the possible denial of service (DoS) attacks on basic NAT-PT and
(DoS) attacks on basic NAT-PT and NAPT-PT that result in resource NAPT-PT that would result in a resource depletion associated with
depletion associated with address and port pools. NAT-PT does not address and port pools. NAT-PT does not specify any authentication
specify any authentication mechanisms; thus, an attacker may be able mechanisms; thus, an attacker may be able to create spurious bindings
to create spurious bindings by spoofing addresses in packets sent by spoofing addresses in packets sent through NAT-PT. The attack is
through NAT-PT. The attack is more damaging if the attacker is able more damaging if the attacker is able to spoof protocols with long
to spoof protocols with long binding timeouts (typically used for binding timeouts (typically used for TCP).
TCP).
The use of the DNS-ALG in NAT-PT introduces another vulnerability The use of the DNS-ALG in NAT-PT introduces another vulnerability
that can result in resource depletion. The attack identified in that can result in resource depletion. The attack identified in
[I-D.durand-natpt-dns-alg-issues] exploits the use of DNS queries [DNS-ALG-ISSUES] exploits the use of DNS queries traversing NAT-PT to
traversing NAT-PT to create dynamic bindings. Every time a DNS query create dynamic bindings. Every time a DNS query is sent through the
is sent through the NAT-PT, the NAT-PT may create a new basic NAT-PT NAT-PT, the NAT-PT may create a new basic NAT-PT or NAPT-PT binding
or NAPT-PT binding without any end-host authentication or without any end-host authentication or authorization mechanisms.
authorization mechanisms. This behavior could lead to a serious DoS This behavior could lead to a serious DoS attack on both memory and
attack on both memory and address or port pools. Address spoofing is address or port pools. Address spoofing is not required for this
not required for this attack to be successful. attack to be successful.
[I-D.hallin-natpt-dns-alg-solutions] proposes to mitigate the DoS [DNS-ALG-SOL] proposes to mitigate the DoS attack by using Access
attack by using Access Control Lists (ACLs) and static binds, which Control Lists (ACLs) and static binds, which increases the
increases the operational cost and may not always be practical. operational cost and may not always be practical.
The ideal mitigation solution would be to disallow dynamically The ideal mitigation solution would be to disallow dynamically
created binds until authentication and authorization of the end-host created binds until authentication and authorization of the end-host
needing the protocol translation has been carried out. This would needing the protocol translation has been carried out. This would
require that the proper security infrastructure be in place to require that the proper security infrastructure be in place to
support the authentication and authorization, which increases the support the authentication and authorization, which increases the
network operational complexity. network operational complexity.
4. Issues Directly Related to Use of DNS-ALG 4. Issues Directly Related to Use of DNS-ALG
4.1. Address Selection Issues when Communicating with Dual-Stack End- 4.1. Address Selection Issues when Communicating with Dual-Stack End-
Hosts Hosts
[I-D.durand-natpt-dns-alg-issues] discusses NAT-PT DNS-ALG issues [DNS-ALG-ISSUES] discusses NAT-PT DNS-ALG issues with regard to
with regard to address selection. As specified in [RFC2766], the address selection. As specified in [RFC2766], the DNS-ALG returns
DNS-ALG returns AAAA resource records (RRs) from two possible sources AAAA Resource Records (RRs) from two possible sources, to the IPv6
to the IPv6 host that has made an AAAA DNS query. host that has made an AAAA DNS query.
If the query relates to a dual-stack host, the query will return both If the query relates to a dual-stack host, the query will return both
the native IPv6 address(es) and the translated IPv4 address(es) in the native IPv6 address(es) and the translated IPv4 address(es) in
AAAA RRs. Without additional information, the IPv6 host address AAAA RRs. Without additional information, the IPv6 host address
selection may pick a translated IPv4 address instead of selecting the selection may pick a translated IPv4 address instead of selecting the
more appropriate native IPv6 address. Under some circumstances, the more appropriate native IPv6 address. Under some circumstances, the
address selection algorithms [RFC3484] will always prefer the address selection algorithms [RFC3484] will always prefer the
translated address over the native IPv6 address; this is obviously translated address over the native IPv6 address; this is obviously
undesirable. undesirable.
[I-D.hallin-natpt-dns-alg-solutions] proposes a solution that [DNS-ALG-SOL] proposes a solution that involves modification to the
involves modification to the NAT-PT specification intended to return NAT-PT specification intended to return only the most appropriate
only the most appropriate address(es) to an IPv6 capable host: address(es) to an IPv6 capable host as described below:
o When a DNS AAAA query traverses the NAT-PT DNS-ALG, the NAT-PT o When a DNS AAAA query traverses the NAT-PT DNS-ALG, the NAT-PT
will forward the query to the DNS server in the IPv4 domain will forward the query to the DNS server in the IPv4 domain
unchanged, but using IPv4 transport: unchanged, but using IPv4 transport. The following two results
can occur:
* If the authoritative DNS server has one or more AAAA records, * If the authoritative DNS server has one or more AAAA records,
it returns them. The DNS-ALG then forwards this response to it returns them. The DNS-ALG then forwards this response to
the IPv6 host and does not send an A query as the standard the IPv6 host and does not send an A query as the standard
NAT-PT would do. NAT-PT would do.
* Otherwise, if the DNS server does not understand the AAAA query * Otherwise, if the DNS server does not understand the AAAA query
or has no AAAA entry for the host, it will return an error. or has no AAAA entry for the host, it will return an error.
The NAT-PT DNS-ALG will intercept the error or empty return and The NAT-PT DNS-ALG will intercept the error or empty return and
send an A query for the same host. If this query returns an send an A query for the same host. If this query returns an
IPv4 address, the ALG creates a binding and synthesizes a IPv4 address, the ALG creates a binding and synthesizes a
corresponding AAAA record, which it sends back to the IPv6 corresponding AAAA record, which it sends back to the IPv6
host. host.
o The NAT-PT thus forwards the result of the first successful DNS o The NAT-PT thus forwards the result of the first successful DNS
response back to the end-host or an error if neither succeeds. response back to the end-host or an error if neither succeeds.
skipping to change at page 17, line 6 skipping to change at page 17, line 41
o The NAT-PT thus forwards the result of the first successful DNS o The NAT-PT thus forwards the result of the first successful DNS
response back to the end-host or an error if neither succeeds. response back to the end-host or an error if neither succeeds.
Consequently, only AAAA RRs from one source will be provided Consequently, only AAAA RRs from one source will be provided
instead of two as specified in [RFC2766], and it will contain the instead of two as specified in [RFC2766], and it will contain the
most appropriate address for a dual-stack or IPv6-only querier. most appropriate address for a dual-stack or IPv6-only querier.
There is, however, still an issue with the proposed solution: There is, however, still an issue with the proposed solution:
o The DNS client may timeout the query if it doesn't receive a o The DNS client may timeout the query if it doesn't receive a
response in time. This is more likely because the NAT-PT may have response in time. This is more likely than for queries not
to make two separate, sequential queries of which the client is passing through a DNS ALG because the NAT-PT may have to make two
not aware. It may be possible to reduce the response time by separate, sequential queries of which the client is not aware. It
sending the two queries in parallel and ignoring the result of the may be possible to reduce the response time by sending the two
A query if the AAAA returns one or more addresses. However, it is queries in parallel and ignoring the result of the A query if the
still necessary to delay after receiving the first response to AAAA returns one or more addresses. However, it is still
determine if a second is coming, which may still trigger the DNS necessary to delay after receiving the first response to determine
client timeout. if a second is coming, which may still trigger the DNS client
timeout.
Unfortunately, the two queries cannot be combined in a single DNS Unfortunately, the two queries cannot be combined in a single DNS
request (all known DNS servers only process a single DNS query per request (all known DNS servers only process a single DNS query per
request message because of difficulties expressing authoritativeness request message because of difficulties expressing authoritativeness
for arbitrary combinations of requests). for arbitrary combinations of requests).
An alternative solution would be to allow the IPv6 host to have, An alternative solution would be to allow the IPv6 host to use the
within its address selection policies, the NAT-PT PREFIX [RFC2766] NAT-PT PREFIX [RFC2766] within its address selection policies and to
used and to assign it a low selection priority. This solution assign it a low selection priority. This solution requires an
requires an automatic configuration of the NAT-PT PREFIX as well as automatic configuration of the NAT-PT PREFIX as well as its
its integration within the address selection policies. The simplest integration within the address selection policies. The simplest way
way to integrate this automatic configuration would be through to integrate this automatic configuration would be through a
configuration file download (in case the host or Dynamic Host configuration file download (in case the host or Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) server did not support Configuration Protocol for IPv6 (DHCPv6) server did not support
vendor options, to avoid standardization effort on the NAT-PT PREFIX vendor options and to avoid a standardization effort on the NAT-PT
option). This solution does not require any modification to the PREFIX option). This solution does not require any modification to
NAT-PT specification. the NAT-PT specification.
Neither of these solutions resolves a second issue related to address Neither of these solutions resolves a second issue related to address
selection that is identified in [I-D.durand-natpt-dns-alg-issues]. selection that is identified in [DNS-ALG-ISSUES]. Applications have
Applications have no way of knowing that the IPv6 address returned no way of knowing that the IPv6 address returned from the DNS-ALG is
from the DNS-ALG is not a 'real' IPv6 address, but a translated IPv4 not a 'real' IPv6 address, but a translated IPv4 address. The
address. The application may therefore be led to believe that it has application may therefore, be led to believe that it has end-to-end
end-to-end IPv6 connectivity with the destination. As a result, the IPv6 connectivity with the destination. As a result, the application
application may use IPv6-specific options that are not supported by may use IPv6-specific options that are not supported by NAT-PT. This
NAT-PT. This issue is closely related to the issue described in issue is closely related to the issue described in Section 4.2 and
Section 4.2 and the discussion in Section 5. the discussion in Section 5.
4.2. Non-global Validity of Translated RR Records 4.2. Non-Global Validity of Translated RR Records
Some applications propagate information records retrieved from DNS to Some applications propagate information records retrieved from DNS to
other applications. The published semantics of DNS imply that the other applications. The published semantics of DNS imply that the
results will be consistent to any user for the duration of the results will be consistent to any user for the duration of the
attached lifetime. RR records translated by NAT-PT violate these attached lifetime. RR records translated by NAT-PT violate these
semantics because the retrieved addresses are only usable for semantics because the retrieved addresses are only usable for
communications through the translating NAT-PT. communications through the translating NAT-PT.
Applications that pass on retrieved DNS records to other applications Applications that pass on retrieved DNS records to other applications
will generally assume that they can rely on the passed on addresses will generally assume that they can rely on the passed on addresses
skipping to change at page 18, line 17 skipping to change at page 19, line 13
translation. translation.
4.3. Inappropriate Translation of Responses to A Queries 4.3. Inappropriate Translation of Responses to A Queries
Some applications running on dual-stack nodes may wish to query the Some applications running on dual-stack nodes may wish to query the
IPv4 address of a destination. If the resulting A query passes IPv4 address of a destination. If the resulting A query passes
through the NAT-PT DNS-ALG, the DNS-ALG will translate the response through the NAT-PT DNS-ALG, the DNS-ALG will translate the response
inappropriately into a AAAA record using a translated address. This inappropriately into a AAAA record using a translated address. This
happens because the DNS-ALG specified in [RFC2766] operates happens because the DNS-ALG specified in [RFC2766] operates
statelessly and hence has no memory of the IPv6 query that induced statelessly and hence has no memory of the IPv6 query that induced
the A request on IPv4 side. The default action is to translate the the A request on the IPv4 side. The default action is to translate
response. the response.
The specification of NAT-PT could be modified to maintain minimal The specification of NAT-PT could be modified to maintain a minimal
state about queries passed through the DNS-ALG, and hence to respond state about queries passed through the DNS-ALG, and hence to respond
correctly to A queries as well as AAAA queries. correctly to A queries as well as AAAA queries.
4.4. DNS-ALG and Multi-addressed Nodes 4.4. DNS-ALG and Multi-Addressed Nodes
Many IPv6 nodes, especially in multihomed situations but also in Many IPv6 nodes, especially in multihomed situations but also in
single homed deployments, can expect to have multiple global single homed deployments, can expect to have multiple global
addresses. The same may be true for multihomed IPv4 nodes. addresses. The same may be true for multihomed IPv4 nodes.
Responses to DNS queries for these nodes will normally contain all Responses to DNS queries for these nodes will normally contain all
these addresses. Since the DNS-ALG in the NAT-PT has no knowledge these addresses. Since the DNS-ALG in the NAT-PT has no knowledge
which of the addresses can or will be used by the application issuing which of the addresses can or will be used by the application issuing
the query, it is obliged to translate all of them. the query, it is obliged to translate all of them.
This could be a significant drain on resources in both basic NAT-PT This could be a significant drain on resources in both basic NAT-PT
and NAPT-PT, as bindings will have to be created for each address. and NAPT-PT, as bindings will have to be created for each address.
When using SCTP in a multihomed network, the problem is exacerbated When using SCTP in a multihomed network, the problem is exacerbated
if multiple NAT-PTs translate multiple addresses. Also, it is not if multiple NAT-PTs translate multiple addresses. Also, it is not
clear that SCTP will actually look up all the destination IP clear that SCTP will actually look up all the destination IP
addresses via DNS so that bindings may not be in place when packets addresses via DNS, so that bindings may not be in place when packets
arrive. arrive.
4.5. Limitations on Deployment of DNS Security Capabilities 4.5. Limitations on Deployment of DNS Security Capabilities
Secure DNS (DNSSEC) [RFC4033] uses public key cryptographic signing Secure DNS (DNSSEC) [RFC4033] uses public key cryptographic signing
to authenticate DNS responses. The DNS-ALG modifies DNS query to authenticate DNS responses. The DNS-ALG modifies DNS query
responses traversing the NAT-PT in both directions which would responses traversing the NAT-PT in both directions, which would
invalidate the signatures as (partially) described in Section 7.5 of invalidate the signatures as (partially) described in Section 7.5 of
[RFC2766]. [RFC2766].
Workarounds have been proposed, such as making the DNS-ALG behave Workarounds have been proposed, such as making the DNS-ALG behave
like a secure DNS server. This would need to be done separately for like a secure DNS server. This would need to be done separately for
both the IPv6 and IPv4 domains. This is operationally very complex both the IPv6 and IPv4 domains. This is operationally very complex
and there is a risk that the server could be mistaken for a and there is a risk that the server could be mistaken for a
conventional DNS server. The NAT-PT specification would have to be conventional DNS server. The NAT-PT specification would have to be
altered to implement any such workaround. altered to implement any such workaround.
Hence DNSSEC is not deployable in domains that use NAT-PT as Hence, DNSSEC is not deployable in domains that use NAT-PT as
currently specified. Widespread deployment of NAT-PT would become a currently specified. Widespread deployment of NAT-PT would become a
serious obstacle to the large scale deployment of DNSSEC. serious obstacle to the large scale deployment of DNSSEC.
5. Impact on IPv6 Application Development 5. Impact on IPv6 Application Development
One of the major design goals for IPv6 is to restore the end-to-end One of the major design goals for IPv6 is to restore the end-to-end
transparency of the Internet. Therefore, because IPv6 may be transparency of the Internet. Therefore, because IPv6 may be
expected to remove the need for NATs and similar impediments to expected to remove the need for NATs and similar impediments to
transparency, developers creating applications to work with IPv6 may transparency, developers creating applications to work with IPv6 may
be tempted to assume that the complex expedients that might have been be tempted to assume that the complex expedients that might have been
skipping to change at page 20, line 12 skipping to change at page 21, line 6
bad idea: the behavior of the application in native IPv6 and NAT-PT bad idea: the behavior of the application in native IPv6 and NAT-PT
environments would be likely to be significantly different. environments would be likely to be significantly different.
6. Security Considerations 6. Security Considerations
This document summarizes security issues related to the NAT-PT This document summarizes security issues related to the NAT-PT
[RFC2766] specification. Security issues are discussed in various [RFC2766] specification. Security issues are discussed in various
sections: sections:
o Section 2.1 discusses how IPsec AH (transport and tunnel mode) and o Section 2.1 discusses how IPsec AH (transport and tunnel mode) and
IPsec ESP transport mode are broken by NAT-PT (when IPSEC UDP IPsec ESP transport mode are broken by NAT-PT (when IPsec UDP
encapsulation is not used [RFC3498]); and authentication and encapsulation is not used [RFC3498]) and authentication and
encryption are generally incompatible with NAT-PT. encryption are generally incompatible with NAT-PT.
o Section 2.5 discusses possible fragmentation related security o Section 2.5 discusses possible fragmentation related security
attacks on NAT-PT. attacks on NAT-PT.
o Section 2.8 discusses security issues related to multicast o Section 2.8 discusses security issues related to multicast
addresses and NAT-PT. addresses and NAT-PT.
o Section 3.3 highlights that NAT-PT is an enticing nexus for o Section 3.3 highlights that NAT-PT is an enticing nexus for
security attacks. security attacks.
o Section 3.4 discusses possible NAT-PT DoS attacks on both memory o Section 3.4 discusses possible NAT-PT DoS attacks on both memory
and address/port pools. and address/port pools.
o Section 4.5 discusses why NAT-PT is incompatible with DNSSEC o Section 4.5 discusses why NAT-PT is incompatible with DNSSEC
[RFC4033] and how deployment of NAT-PT may inhibit deployment of [RFC4033] and how deployment of NAT-PT may inhibit deployment of
DNSSEC. DNSSEC.
7. IANA Considerations 7. Conclusion
There are no IANA considerations defined in this document.
8. Conclusion
This document has discussed a number of significant issues with This document has discussed a number of significant issues with
NAT-PT as defined in [RFC2766]. From a deployment perspective, 3GPP NAT-PT as defined in [RFC2766]. From a deployment perspective, 3GPP
networks are currently the only 'standardised' scenario where an networks are currently the only 'standardised' scenario where NAT-PT
IPv6-only host communicates with an IPv4-only host using NAT-PT as is envisaged as a potential mechanism to allow communication between
described in the 3GPP IPv6 transition analysis [RFC4215], but NAT-PT an IPv6-only host and an IPv4-only host as discussed in the 3GPP IPv6
has seen some limited usage for other purposes. transition analysis [RFC4215]. But RFC 4215 recommends that the
generic form of NAT-PT should not be used and that modified forms
should only be used under strict conditions. Moreover, it documents
a number of caveats and security issues specific to 3GPP. In
addition, NAT-PT has seen some limited usage for other purposes.
Although some of the issues identified with NAT-PT appear to have Although some of the issues identified with NAT-PT appear to have
solutions, many of the solutions proposed required significant solutions, many of the solutions proposed require significant
alterations to the existing specification and would be likely to alterations to the existing specification and would likely increase
increase operational complexity. Even if these solutions were operational complexity. Even if these solutions were applied, we
applied, we have shown that NAT-PT still has significant, have shown that NAT-PT still has significant, irresolvable issues and
irresolvable issues and appears to have limited applicability. The appears to have limited applicability. The potential constraints on
potential constraints on the development of IPv6 applications the development of IPv6 applications described in Section 5 are
described in Section 5 are particularly undesirable. It appears that particularly undesirable. It appears that alternatives to NAT-PT
alternatives to NAT-PT exist to cover the circumstances where NAT-PT exist to cover the circumstances where NAT-PT has been suggested as a
has been suggested as a solution, such as the use of tunneling and solution, such as the use of application proxies in 3GPP scenarios
header compression in 3GPP scenarios. [RFC4215]
However, it is clear that in some circumstances an IPv6/IPv4 protocol However, it is clear that in some circumstances an IPv6-IPv4 protocol
translation solution may be a useful transitional solution, translation solution may be a useful transitional solution,
particularly in more constrained situations where the translator is particularly in more constrained situations where the translator is
not required to deal with traffic for a wide variety of protocols not required to deal with traffic for a wide variety of protocols
that are not determined in advance. Therefore, it is possible that a that are not determined in advance. Therefore, it is possible that a
more limited form of NAT-PT could be defined for use in specific more limited form of NAT-PT could be defined for use in specific
situations. situations.
Accordingly, we recommend that Accordingly, we recommend that:
o the IETF no longer suggest its usage as a general IPv4/IPv6
o the IETF no longer suggest its usage as a general IPv4-IPv6
transition mechanism in the Internet, and transition mechanism in the Internet, and
o RFC2766 is moved to Historic status to limit the possibility of it
being deployed inappropriately.
9. Acknowledgments o RFC 2766 is moved to Historic status to limit the possibility of
it being deployed inappropriately.
8. Acknowledgments
This work builds on a large body of existing work examining the This work builds on a large body of existing work examining the
issues and applicability of NAT-PT: the work of the authors of the issues and applicability of NAT-PT: the work of the authors of the
documents referred to in Section 1 has been extremely useful in documents referred to in Section 1 has been extremely useful in
creating this document. Particular thanks are due to Pekka Savola creating this document. Particular thanks are due to Pekka Savola
for rapid and thorough review of the document. for rapid and thorough review of the document.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation
(SIIT)", RFC 2765, February 2000. Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766, Translation - Protocol Translation (NAT-PT)",
February 2000. RFC 2766, February 2000.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol
with the IP Network Address Translator", RFC 3027, Complications with the IP Network Address
January 2001. Translator", RFC 3027, January 2001.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards", Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002. RFC 3314, September 2002.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484,
February 2003.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006. April 2006.
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks", RFC 4215, Generation Partnership Project (3GPP) Networks",
October 2005. RFC 4215, October 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D.,
Rose, "DNS Security Introduction and Requirements", and S. Rose, "DNS Security Introduction and
RFC 4033, March 2005. Requirements", RFC 4033, March 2005.
10.2. Informative References 9.2. Informative References
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858, Considerations for IP Fragment Filtering",
October 1995. RFC 1858, October 1995.
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny [RFC3128] Miller, I., "Protection Against a Variant of the
Fragment Attack (RFC 1858)", RFC 3128, June 2001. Tiny Fragment Attack (RFC 1858)", RFC 3128,
June 2001.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla,
Zhang, L., and V. Paxson, "Stream Control Transmission M., Zhang, L., and V. Paxson, "Stream Control
Protocol", RFC 2960, October 2000. Transmission Protocol", RFC 2960, October 2000.
[RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher,
Managed Objects for Synchronous Optical Network (SONET) "Definitions of Managed Objects for Synchronous
Linear Automatic Protection Switching (APS) Optical Network (SONET) Linear Automatic Protection
Architectures", RFC 3498, March 2003. Switching (APS) Architectures", RFC 3498,
March 2003.
[I-D.satapati-v6ops-natpt-applicability] [NATP-APP] Satapati, S., "NAT-PT Applicability", Work
Satapati, S., "NAT-PT Applicability", in Progress, October 2003.
draft-satapati-v6ops-natpt-applicability-00 (work in
progress), October 2003.
[I-D.durand-natpt-dns-alg-issues] [DNS-ALG-ISSUES] Durand, A., "Issues with NAT-PT DNS ALG in
Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", RFC2766", Work in Progress, February 2002.
draft-durand-natpt-dns-alg-issues-00 (work in progress),
February 2002.
[I-D.hallin-natpt-dns-alg-solutions] [DNS-ALG-SOL] Hallingby, P. and S. Satapati, "NAT-PT DNS ALG
Hallingby, P. and S. Satapati, "NAT-PT DNS ALG solutions", solutions", Work in Progress, July 2002.
draft-hallin-natpt-dns-alg-solutions-01 (work in
progress), July 2002.
[I-D.lee-v6ops-natpt-mobility] [NATPT-MOB] Shin, M. and J. Lee, "Considerations for Mobility
Shin, M. and J. Lee, "Considerations for Mobility Support Support in NAT-PT", Work in Progress, July 2005.
in NAT-PT", draft-lee-v6ops-natpt-mobility-01 (work in
progress), July 2005.
[I-D.okazaki-v6ops-natpt-security] [NATPT-SEC] Okazaki, S. and A. Desai, "NAT-PT Security
Okazaki, S. and A. Desai, "NAT-PT Security Considerations", Work in Progress, June 2003.
Considerations", draft-okazaki-v6ops-natpt-security-00
(work in progress), June 2003.
[I-D.vanderpol-v6ops-translation-issues] [TRANS-ISSUES] Pol, R., Satapati, S., and S. Sivakumar, "Issues
Pol, R., Satapati, S., and S. Sivakumar, "Issues when when translating between IPv4 and IPv6", Work
translating between IPv4 and IPv6", in Progress, January 2003.
draft-vanderpol-v6ops-translation-issues-00 (work in
progress), January 2003.
[I-D.elmalki-sipping-3gpp-translator] [3GPP-TRANS] Malki, K., "IPv6-IPv4 Translation mechanism for
Malki, K., "IPv6-IPv4 Translation mechanism for SIP-based SIP-based services in Third Generation Partnership
services in Third Generation Partnership Project (3GPP) Project (3GPP) Networks", Work in Progress,
Networks", draft-elmalki-sipping-3gpp-translator-00 (work December 2003.
in progress), December 2003.
[I-D.tsuchiya-mtp] [MTP] Tsuchiya, K., Higuchi, H., Sawada, S., and S.
Tsuchiya, K., Higuchi, H., Sawada, S., and S. Nozaki, "An Nozaki, "An IPv6/IPv4 Multicast Translator based on
IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying IGMP/MLD Proxying (mtp)", Work in Progress,
(mtp)", draft-tsuchiya-mtp-01 (work in progress),
February 2003. February 2003.
[I-D.venaas-mboned-v4v6mcastgw] [MCASTGW] Venaas, S., "An IPv4 - IPv6 multicast gateway",
Venaas, S., "An IPv4 - IPv6 multicast gateway", Work in Progress, February 2003.
draft-venaas-mboned-v4v6mcastgw-00 (work in progress),
February 2003.
[I-D.park-scalable-multi-natpt] [MUL-NATPT] Park, S., "Scalable mNAT-PT Solution", Work
Park, S., "Scalable mNAT-PT Solution", in Progress, May 2003.
draft-park-scalable-multi-natpt-00 (work in progress),
May 2003.
Authors' Addresses Authors' Addresses
Cedric Aoun Cedric Aoun
Energize Urnet Energize Urnet
Paris Paris
France France
Email: ietf@energizeurnet.com EMail: ietf@energizeurnet.com
Elwyn B. Davies Elwyn B. Davies
Folly Consulting Folly Consulting
Soham, Cambs Soham, Cambs
UK UK
Phone: +44 7889 488 335 Phone: +44 7889 488 335
Email: elwynd@dial.pipex.com EMail: elwynd@dial.pipex.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 25, line 45 skipping to change at page 25, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 134 change blocks. 
389 lines changed or deleted 387 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/