draft-ietf-v6ops-natpt-to-exprmntl-00.txt   draft-ietf-v6ops-natpt-to-exprmntl-01.txt 
v6ops Working Group C. Aoun v6ops Working Group C. Aoun
Internet-Draft Nortel Networks/ENST Paris Internet-Draft ENST
Updates: 2766 (if approved) E. Davies Updates: 2766 (if approved) E. Davies
Expires: July 5, 2005 Consultant Expires: January 6, 2006 Consultant
January 2005 July 5, 2005
Reasons to Move NAT-PT to Experimental Reasons to Move NAT-PT to Experimental
draft-ietf-v6ops-natpt-to-exprmntl-00 draft-ietf-v6ops-natpt-to-exprmntl-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 5, 2005. This Internet-Draft will expire on January 6, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document discusses issues with the specific form of IPv6-IPv4 This document discusses general issues with all forms of IPv6-IPv4
translation and specific issues related to the 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 specific issues are sufficiently serious that recommending RFC 2766
general purpose transition mechanism is no longer desirable, and this as a general purpose transition mechanism is no longer desirable, and
document requests that the IETF reclassifies RFC 2766 from Standards this document recommends that the IETF should reclassify RFC 2766
Track to Experimental status. from Standards Track to Experimental status.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Issues Unrelated to DNS-ALG . . . . . . . . . . . . . . . . 6 2. Issues Unrelated to DNS-ALG . . . . . . . . . . . . . . . . 6
2.1 Issues with Protocols Embedding IP Addresses . . . . . . . 6 2.1 Issues with Protocols Embedding IP Addresses . . . . . . . 6
2.2 NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 7 2.2 NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 7
2.3 NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 7 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 . . . . 8
2.5 NA(P)T-PT and Fragmentation . . . . . . . . . . . . . . . 9 2.5 NA(P)T-PT and Fragmentation . . . . . . . . . . . . . . . 9
2.6 NAT-PT Interaction with SCTP and Multihoming . . . . . . . 10 2.6 NAT-PT Interaction with SCTP and Multihoming . . . . . . . 10
2.7 NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 10 2.7 NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 11
2.8 NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 11 2.8 NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 11
3. Issues exacerbated by the Use of DNS-ALG . . . . . . . . . . 12 3. Issues exacerbated by the Use of DNS-ALG . . . . . . . . . . 12
3.1 Network Topology Constraints Implied by NAT-PT . . . . . . 12 3.1 Network Topology Constraints Implied by NAT-PT . . . . . . 12
3.2 Scalability and Single Point of Failure Concerns . . . . . 13 3.2 Scalability and Single Point of Failure Concerns . . . . . 13
3.3 Issues with Lack of Address Persistence . . . . . . . . . 13 3.3 Issues with Lack of Address Persistence . . . . . . . . . 14
3.4 DOS Attacks on Memory and Address/Port Pools . . . . . . . 14 3.4 DOS Attacks on Memory and Address/Port Pools . . . . . . . 14
4. Issues Directly Related to use of DNS-ALG . . . . . . . . . 15 4. Issues Directly Related to use of DNS-ALG . . . . . . . . . 15
4.1 Address Selection Issues when Communicating with 4.1 Address Selection Issues when Communicating with
Dual-Stack End-hosts . . . . . . . . . . . . . . . . . . . 15 Dual-Stack End-hosts . . . . . . . . . . . . . . . . . . . 15
4.2 Non-global Validity of Translated RR Records . . . . . . . 17 4.2 Non-global Validity of Translated RR Records . . . . . . . 17
4.3 Inappropriate Translation of Responses to A Queries . . . 17 4.3 Inappropriate Translation of Responses to A Queries . . . 17
4.4 DNS-ALG and Multi-addressed Nodes . . . . . . . . . . . . 17 4.4 DNS-ALG and Multi-addressed Nodes . . . . . . . . . . . . 17
4.5 Limitations on Deployment of DNS Security Capabilities . . 18 4.5 Limitations on Deployment of DNS Security Capabilities . . 18
5. Impact on IPv6 Application Development . . . . . . . . . . . 18 5. Impact on IPv6 Application Development . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1 Normative References . . . . . . . . . . . . . . . . . . 20 10.1 Normative References . . . . . . . . . . . . . . . . . . 21
10.2 Informative References . . . . . . . . . . . . . . . . . 21 10.2 Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . 25
1. Introduction 1. Introduction
The Network Address Translator - Protocol Translator NAT-PT) document The Network Address Translator - Protocol Translator NAT-PT) document
[RFC2766] defines a set of network layer translation mechanisms [RFC2766] defines a set of network layer translation mechanisms.
designed to allow nodes which only support IPv4 to communicate with These mechanisms are designed to allow nodes which only support IPv4
nodes which only support IPv6 during the transition to the use of to communicate with nodes which only support IPv6 during the
IPv6 in the Internet. transition 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 NAPT-PT (Network Address Port Translator - Protocol translated and NAPT-PT (Network Address Port Translator - Protocol
Translator)which also translates transport identifiers, allowing for Translator)which also translates transport identifiers, allowing for
greater economy of scarce IPv4 addresses. Protocol translation is greater economy of scarce IPv4 addresses. Protocol translation is
performed using the Stateless IP/ICMP Translation Algorithm (SIIT) performed using the Stateless IP/ICMP Translation Algorithm (SIIT)
defined in [RFC2765]. defined in [RFC2765].
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
skipping to change at page 3, line 48 skipping to change at page 3, line 48
[RFC2766] as a general purpose transition mechanism for [RFC2766] as a general purpose transition mechanism for
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 which can applicable, it is likely that in some circumstances a node which can
only support IPv4 will need to communicate with a node which can only only support IPv4 will need to communicate with a node which can only
support IPv6: this is bound to need a translation mechanism of some support IPv6: this is bound to need a translation mechanism of some
kind. Although this may be better carried out by an application kind. Although this may be better carried out by an application
level proxy or transport layer translator, there may still be level proxy or transport layer translator, there may still be
scenarios in which a (possibly restricted) version of NAT-PT can be a scenarios in which a (possibly restricted) version of NAT-PT can be a
suitable solution: accordingly this document requests the IETF to suitable solution: accordingly this document recommends that the IETF
reclassify RFC2766 from Standards Track to Experiemental status. should reclassify RFC2766 from Standards Track to Experimental
status.
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 o NAT-PT applicability statement [I-D.satapati-v6ops-natpt-
[I-D.satapati-v6ops-natpt-applicability] applicability]
o Issues with NAT-PT DNS ALG in RFC2766 o Issues with NAT-PT DNS ALG in RFC2766 [I-D.durand-natpt-dns-alg-
[I-D.durand-natpt-dns-alg-issues] issues]
o NAT-PT DNS ALG solutions [I-D.hallin-natpt-dns-alg-solutions] o NAT-PT DNS ALG solutions [I-D.hallin-natpt-dns-alg-solutions]
o NAT-PT Security Considerations [I-D.okazaki-v6ops-natpt-security] o NAT-PT Security Considerations [I-D.okazaki-v6ops-natpt-security]
o Issues when translating between IPv4 and IPv6 o Issues when translating between IPv4 and IPv6 [I-D.vanderpol-
[I-D.vanderpol-v6ops-translation-issues] v6ops-translation-issues]
o IPv6-IPv4 Translation mechanism for SIP-based services in Third o IPv6-IPv4 Translation mechanism for SIP-based services in Third
Generation Partnership Project (3GPP) Networks Generation Partnership Project (3GPP) Networks [I-D.elmalki-
[I-D.elmalki-sipping-3gpp-translator] sipping-3gpp-translator]
o Analysis on IPv6 Transition in 3GPP Networks o Analysis on IPv6 Transition in 3GPP Networks [I-D.ietf-v6ops-3gpp-
[I-D.ietf-v6ops-3gpp-analysis] analysis]
o Considerations for Mobile IP Support in NAT-PT o Considerations for Mobile IP Support in NAT-PT [I-D.lee-v6ops-
[I-D.lee-v6ops-natpt-mobility] natpt-mobility]
o An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp) o An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)
[I-D.tsuchiya-mtp] [I-D.tsuchiya-mtp]
o An IPv4 - IPv6 multicast gateway [I-D.venaas-mboned-v4v6mcastgw] o An IPv4 - IPv6 multicast gateway [I-D.venaas-mboned-v4v6mcastgw]
o Scalable mNAT-PT Solution [I-D.park-scalable-multi-natpt] o Scalable mNAT-PT Solution [I-D.park-scalable-multi-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 Internet Drafts which are unlikely to become RFCs, the
issues are summarized here to avoid the need for normative issues are summarized here to avoid the need for normative
references. references.
skipping to change at page 5, line 10 skipping to change at page 5, line 11
interactions between DNS and NAT-PT. However, detailed inspection of interactions between DNS and NAT-PT. However, detailed inspection of
[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. This document passed to the hosts in the absence of the DNS-ALG. This document
therefore assumes that the DNS-ALG is an integral part of NAT-PT: therefore 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 the issues which are not specifically related to the use of Note that the issues which are not specifically related to the use of
the DNS-ALG will apply to any network layer translation scheme, the DNS-ALG will apply to any network layer translation scheme,
including any based on the SIIT algorithm [RFC2765]. including any based on the SIIT algorithm [RFC2765]. In the event
that new forms of translator are developed as alternatives to NAT-PT,
the generic issues relevant to all IPv6-IPv4 translators should be
borne in mind.
Issues raised with NAT-PT can be categorized as follows: Issues raised with IPv6-IPv4 translators in general and NAT-PT in
o Issues which are independent of the use of a DNS-ALG: particular can be categorized as follows:
o Issues which are independent of the use of a DNS-ALG and are,
therefore, applicable to any form of IPv6-IPv4 translator:
* Disruption of all protocols which embed IP addresses (and/or * Disruption of all protocols which embed IP addresses (and/or
ports) in packet payloads or which apply integrity mechanisms ports) in packet payloads or which apply integrity mechanisms
using IP addresses (and ports). using IP addresses (and ports).
* Inability to re-direct traffic for protocols without any * Inability to re-direct traffic for protocols without any
demultiplexing capabilities or not built on top of specific demultiplexing capabilities or 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 which are exacerbated by the use of a DNS-ALG: o Issues which are exacerbated by the use of a DNS-ALG and are,
therefore also applicable to any form of IPv6-IPv4 translator:
* Constraints on network topology. * Constraints on network topology.
* Scalability concerns together with introduction of single point * Scalability concerns together with introduction of single point
of failure and security attack nexus. of failure and 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 disrupted if a different mapping is used. The use of the DNS-
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 keeping it alive once they
start using it. start using it.
* Creation of a DOS threat relating to exhaustion of memory and * Creation of a DOS threat relating to exhaustion of memory and
address/port pool resources on the translator. address/port pool resources on the translator.
o Issues which result from the use of a DNS-ALG: o Issues which result from the use of a DNS-ALG and are, therefore,
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 which cannot use it. record may be forwarded to an application which 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 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 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 on the application developers and the long term effects of NAT-PT or any
further development of IPv6. form of generally deployed IPv6-IPv4 translator on the further
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 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 which embed numeric and [RFC3027]) that the large class of protocols which embed numeric
skipping to change at page 6, line 49 skipping to change at page 7, line 11
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 co-located 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 clear (i.e. not encrypted). are sent in 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. The NAT-PT should then be aware of the cryptographic encryption. NAT-PT would then be aware of the cryptographic
algorithms and keys used to secure the traffic and could modify and algorithms and keys used to secure the traffic. It could then modify
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 provides additional points of security vulnerability.
Unless UDP encapsulation is used for IPsec [RFC3948], 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 (in transport and tunnel mode) and IPsec ESP (in transport
mode) are unable to be carried through NAT-PT without terminating the mode) are unable to be carried through NAT-PT without terminating the
security associations on the NAT-PT, due to their usage of security associations on the NAT-PT, due to their usage of
cryptographic integrity protection. 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
skipping to change at page 7, line 30 skipping to change at page 7, line 41
(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 SPI as an alternative demultiplexer) and protocols, such as RSVP, the SPI as an alternative demultiplexer) and protocols, such as RSVP,
which are carried directly in IP datagrams rather than using a which are carried directly in IP datagrams rather than using a
standard transport layer protocol such as TCP or UDP. In the case of standard transport layer protocol such as TCP or UDP. In the case of
RSVP, packets going from the IPv4 domain to the IPv6 domain do not RSVP, packets going from the IPv4 domain to the IPv6 domain do not
necessarily carry a suitable demultiplexing field, because the port necessarily carry a suitable demultiplexing field, because the port
fields in the flow identifer and traffic specifications are optional. fields in the flow identifier 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, undesirable behavior
(for example, such workarounds often assume particular network (for example, such workarounds often assume particular network
topologies etc in order to function correctly; if the assumptions are topologies etc in order to function correctly; if the assumptions are
not met in a deployment the workaround may not work as expected). not met in a deployment the workaround may not work 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.
skipping to change at page 8, line 33 skipping to change at page 8, line 46
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 flow IPv6 header. Hence any special treatment of packets based on flow
label patterns cannot be propagated into the IPv4 domain. label patterns cannot be propagated into the IPv4 domain.
o IPv6 extension headers provide flexibility for improvements in the o IPv6 extension headers provide flexibility for improvements in the
IP protocol suite in future. New headers may be defined in future IP protocol suite in future. New headers may be defined in future
which do not have equivalents in IPv4. In practice, some existing which do not have equivalents in IPv4. In practice, some existing
extensions such as routing headers and mobility extensions are not extensions such as routing headers and mobility extensions are not
translatable. translatable.
o As described in section 2.2 of o As described in section 2.2 of [I-D.satapati-v6ops-natpt-
[I-D.satapati-v6ops-natpt-applicability] there are no equivalents applicability] there are no equivalents in IPv6 for some ICMP(v4)
in IPv6 for some ICMP(v4) messages, while for others (notably the messages, while for others (notably the 'Parameter Problem'
'Parameter Problem' messages) the semantics are not equivalent. messages) the semantics are not equivalent. Translation of such
Translation of such messages may lead to loss of information. messages may lead to loss of information. However, this issue may
However, this issue may not be very severe because the error not be very severe because the error messages relate to packets
messages relate to packets that have been translated by NAT-PT that have been translated by NAT-PT rather than arbitrary packets.
rather than arbitrary packets. If the NAT-PT is functioning If the NAT-PT is functioning correctly, there is, for example, no
correctly, there is, for example, no reason why IPv6 packets with reason why IPv6 packets with unusual extension headers or options
unusual extension headers or options should be generated. This should be generated. This case is cited in [I-D.satapati-v6ops-
case is cited in [I-D.satapati-v6ops-natpt-applicability] as an natpt-applicability] as an example where the IPv6 error has no
example where the IPv6 error has no equivalent in IPv4 resulting equivalent in IPv4 resulting in lost information.
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.
skipping to change at page 9, line 29 skipping to change at page 9, line 42
lead to the first fragment appearing at the NAPT-PT after later lead to the first fragment appearing at the NAPT-PT after later
fragments. The NAPT-PT would then not have the information needed to fragments. The NAPT-PT would then not have the information needed to
translate the fragments received before the first. 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 which don't to be proofed against receiving short first fragments which 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 IPv6 stateful packet inspection. The current
specifications of IPv6 do not mandate any minimum packet size beyond specifications of IPv6 do not mandate any minimum packet size beyond
the need to carry the unfragmentable part (which doesn't include the the need to carry the unfragmentable part (which doesn't include the
transport port numbers) or reassembly rules to minimise the effects transport port numbers) or reassembly rules to minimize the effects
of overlapping fragments, leaving IPv6 open to the sort of attacks of overlapping fragments, leaving IPv6 open to the sort of attacks
described in [RFC1858] and [RFC3128]. 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 a NAT-PT box. As does not have a transport layer checksum, traverses a NAT-PT box. As
described in [RFC2766], the NAT-PT has to reconstruct the whole described in [RFC2766], the NAT-PT has to reconstruct the whole
packet so that it can calculate the checksum needed for the 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 significant delay to the
packet, especially if it has to be re-fragmented before transmission packet, especially if it has to be re-fragmented before transmission
on the IPv6 side. on the IPv6 side.
If NA(P)T-PT boxes reassembled all incoming fragmented packets (both If NA(P)T-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 as they have to do
for unchecksummed IPv4 UDP packets, this would be a solution to the for unchecksummed IPv4 UDP packets, this would be a solution to the
first problem. The cost would be considerable: apart from the first problem. The resource cost would be considerable apart from
potential delay problem if the outgoing packet has to be fragmented, the potential delay problem if the outgoing packet has to be re-
the NA(P)T-PT would consume extra memory and CPU resources, making fragmented. In any case fragmentation would mean that the NA(P)T-PT
the NAT-PT even less scaleable (see Section 3.2). would consume extra memory and CPU resources, making the NAT-PT even
less scaleable (see Section 3.2).
Packet reassembly in NA(P)T-PT also opens up the possibility of Packet reassembly in NA(P)T-PT also opens up the possibility of
various fragment-related security attacks. Some of these are various fragment-related security attacks. Some of these are
analagous 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 translation of SCTP, but
SCTP uses transport port numbers in the same way as UDP and TCP so SCTP uses transport port numbers in the same way as UDP and TCP so
skipping to change at page 10, line 25 skipping to change at page 10, line 39
However, SCTP also supports multihoming. During connection setup However, SCTP also supports multihoming. During connection setup
SCTP control packets carry embedded addresses which would have to be SCTP control packets carry embedded addresses which 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 were changed with consequent fields in the SCTP control packets were changed with consequent
changes to packet length: the transport checksum would also have to changes to packet length: the transport checksum would also have to
be recalculated. The ramifications of multihoming as it might be recalculated. The ramifications of multihoming as it might
interact with NAT-PT have not been fully explored. Because of the interact with NAT-PT have not been fully explored. Because of the
'chunked' nature of data transfer it does not appear that state would 'chunked' nature of data transfer it does not appear that state would
have to be maintained to relate packets transmitted using the have to be maintained to relate packets transmitted using the
different IP addresses associated with the connection. [Author's different IP addresses associated with the connection.
Note: This needs to be considered by an SCTP expert].
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 state is required, the state would have to distributed and
synchronized across several NAT-PT boxes in a multihomed environment. 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
skipping to change at page 10, line 46 skipping to change at page 11, line 12
out that state is required, the state would have to distributed and out that state is required, the state would have to distributed and
synchronized across several NAT-PT boxes in a multihomed environment. 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 [I-D.lee-v6ops-natpt-mobility], it is not possible to
propagate Mobile IPv6 control messages into the IPv4 domain. propagate Mobile IPv6 control messages into the IPv4 domain.
According to the IPv6 Node Requirements According to the IPv6 Node Requirements [I-D.ietf-ipv6-node-
[I-D.ietf-ipv6-node-requirements], IPv6 nodes should normally be requirements], IPv6 nodes should normally be prepared to support the
prepared to support the route optimization mechanisms needed in a route optimization mechanisms needed in a correspondent node. If
correspondent node. If communications from an IPv6 mobile node is communications from an IPv6 mobile node are traversing a NAT-PT, the
traversing a NAT-PT, the destination IPv4 node is not going to destination IPv4 node will certainly not be able to support the
support the correspondent node features needed for route correspondent node features 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 but agent without route optimization. This is clearly sub-optimal but
communication should remain possible. 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
skipping to change at page 11, line 49 skipping to change at page 12, line 13
comprehensive approach which includes proxying of the multicast comprehensive approach which includes proxying of the multicast
routing protocols is described in 'An IPv4 - IPv6 multicast gateway' routing protocols is described in 'An IPv4 - IPv6 multicast gateway'
[I-D.venaas-mboned-v4v6mcastgw]. Both approaches have several of the [I-D.venaas-mboned-v4v6mcastgw]. Both approaches have several of the
issues described in this section, notably issues with embedded issues described in this section, notably issues with embedded
addresses. addresses.
[I-D.okazaki-v6ops-natpt-security] identifies the possibility of a [I-D.okazaki-v6ops-natpt-security] identifies the possibility of a
multiplicative reflection attack if the NAT-PT can be spoofed into multiplicative reflection attack if the NAT-PT can be spoofed into
creating a binding for a multicast address. This attack would be creating a binding for a multicast address. This attack would be
very hard to mount because routers should not forward packets with very hard to mount because routers should not forward packets with
muticast addresses in the source address field. However, it points multicast addresses in the source address field. However, it
up that a naively implemented DNS-ALG could create such bindings from highlights the possibility that a naively implemented DNS-ALG could
spoofed DNS responses since [RFC2766] does not mention the need for create such bindings from spoofed DNS responses since [RFC2766] does
checks on the types of addresses in these responses. not mention the need for checks on the types of addresses in these
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
skipping to change at page 12, line 27 skipping to change at page 12, line 40
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 would 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 in order that the DNS-ALG is able to examine IPv6 router for the site in order that the DNS-ALG is able to examine
all DNS requests made over IPv6. On sites with both IPv6 and all DNS requests made over IPv6. On sites with both IPv6 and dual-
dual-stack nodes, this will result in all traffic flowing through the stack nodes, this will result in all traffic flowing through the
NAT-PT with consequent scalability concerns. NAT-PT with consequent scalability concerns.
These constraints are described in more detail in These constraints are described in more detail in [I-D.durand-natpt-
[I-D.durand-natpt-dns-alg-issues]. dns-alg-issues].
[I-D.hallin-natpt-dns-alg-solutions] proposes a solution for flows [I-D.hallin-natpt-dns-alg-solutions] proposes a solution for flows
initiated from the IPv6 domain but it appears that this solution initiated from the IPv6 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 NAT-PT
PREFIX (see [RFC2766]). Queries to this server would necessarily PREFIX (see [RFC2766]). Queries to this server would necessarily
pass through the NAT-PT. Dual-stack hosts would use a separate DNS pass through the NAT-PT. Dual-stack hosts would use a separate DNS
server accessed through a normal IPv6 address. This removes the need server accessed through a normal IPv6 address. This removes the need
skipping to change at page 14, line 8 skipping to change at page 14, line 22
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 application uses the translated address returned by the DNS query
before the NAT-PT binding state is timed out (see Section 2.3). before the NAT-PT binding state is timed out (see Section 2.3).
Applications will not normally be aware of this constraint, which may Applications will not normally be aware of this constraint, which may
be different from the existing lifetime of DNS query responses. This be different from the existing lifetime of DNS query responses. This
could lead to difficult diagnosis problems with applications. 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 which it creates. As noted in Section 2.3, this may need to bindings which 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 this might open up additional DOS attack response lifetime but this might open up additional DOS attack
possibilities if very long validities are allowed. Also the lifetime possibilities if very long validities are allowed. Also the lifetime
should be adjusted once the NAT-PT determines which protocol is being should be adjusted once the NAT-PT determines which protocol is being
used with the binding. used with the binding.
skipping to change at page 14, line 45 skipping to change at page 15, line 10
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 bindings As discussed in Section 2.3 a NAT-PT may create dynamic NAT bindings
each of which consumes memory resources as well as an address (or each of which consumes memory resources as well as an address (or
port if NAPT-PT is used) from an address (or port) pool. A number of port if NAPT-PT is used) from an address (or port) pool. A number of
documents, including [RFC2766] and [I-D.okazaki-v6ops-natpt-security] documents, including [RFC2766] and [I-D.okazaki-v6ops-natpt-security]
discuss possible denial of service (DOS) attacks on NA(P)T-PT which discuss possible denial of service (DOS) attacks on NA(P)T-PT which
result in resource depletion associated with address and port pools. result in resource depletion associated with address and port pools.
NAT-PT does not specify any authentication mechanisms so that an NAT-PT does not specify any authentication mechanisms so that an
attacker may be able to create spurious binds by spoofing addresses attacker may be able to create spurious bindings by spoofing
in packets sent through NAT-PT. The attack is more damaging if the addresses in packets sent through NAT-PT. The attack is more
attacker is able to spoof protocols with long binding timeouts damaging if the attacker is able to spoof protocols with long binding
(typically used for TCP). timeouts (typically used for 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
which can result in resource depletion. The attack identified in which can result in resource depletion. The attack identified in
[I-D.durand-natpt-dns-alg-issues] exploits the use of DNS queries [I-D.durand-natpt-dns-alg-issues] exploits the use of DNS queries
traversing NAT-PT to create dynamic bindings. Every time a DNS query traversing NAT-PT to create dynamic bindings. Every time a DNS query
is sent through the NAT-PT the NAT-PT may create a new NA(P)T-PT bind is sent through the NAT-PT the NAT-PT may create a new NA(P)T-PT bind
without any end-host authentication or authorization mechanisms. without any end-host authentication or authorization mechanisms.
This behavior could lead to a serious DOS attack on both memory and This behavior could lead to a serious DOS attack on both memory and
address or port pools. Address spoofing is not required for this address or port pools. Address spoofing is not required for this
attack to be successful. attack to be successful.
skipping to change at page 15, line 25 skipping to change at page 15, line 38
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 4.1 Address Selection Issues when Communicating with Dual-Stack End-
End-hosts hosts
[I-D.durand-natpt-dns-alg-issues] discusses NAT-PT DNS-ALG issues [I-D.durand-natpt-dns-alg-issues] discusses NAT-PT DNS-ALG issues
with regard to address selection. As specified in [RFC2766], the with regard to address selection. As specified in [RFC2766], the
DNS-ALG returns AAAA RRs from two possible sources to the IPv6 host DNS-ALG returns AAAA RRs from two possible sources to the IPv6 host
which has made an AAAA DNS query AAAA. which 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 will always prefer the translated address selection algorithms will always prefer the translated
address over the native IPv6 address which is obviously undesirable. address over the native IPv6 address which is obviously undesirable.
[I-D.hallin-natpt-dns-alg-solutions] proposes a solution which [I-D.hallin-natpt-dns-alg-solutions] proposes a solution which
skipping to change at page 16, line 4 skipping to change at page 16, line 16
[I-D.hallin-natpt-dns-alg-solutions] proposes a solution which [I-D.hallin-natpt-dns-alg-solutions] proposes a solution which
involves modification to the NAT-PT specification intended to return involves modification to the NAT-PT specification intended to return
only the most appropriate address(es) to an IPv6 capable host: only the most appropriate address(es) to an IPv6 capable host:
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:
* 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 host. corresponding AAAA record which it sends back to the IPv6 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 succeeeds. 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 because the NAT-PT may have
to make two separate queries sequentially which the client is not to make two separate queries sequentially which the client is not
aware of. It may be possible to reduce the response time by aware of. It may be possible to reduce the response time by
sending the two queries in parallel and ignoring the result of the sending the two queries in parallel and ignoring the result of the
skipping to change at page 17, line 50 skipping to change at page 18, line 14
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 NAT-PT and This could be a significant drain on resources in both NAT-PT and
NAPT-PT, as bindings will have to be created for each address. 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 mutiple 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) [I-D.ietf-dnsext-dnssec-intro] uses public key Secure DNS (DNSSEC) [I-D.ietf-dnsext-dnssec-intro] uses public key
cryptographic signing to authenticate DNS responses. The DNS-ALG cryptographic signing to authenticate DNS responses. The DNS-ALG
modifies DNS query responses traversing the NAT-PT in both directions modifies DNS query responses traversing the NAT-PT in both directions
which would invalidate the signatures as (partially) described in which would invalidate the signatures as (partially) described in
skipping to change at page 19, line 22 skipping to change at page 19, line 35
behavior of the application in native IPv6 and NAT-PT environments behavior of the application in native IPv6 and NAT-PT environments
would be likely to be significantly different. 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 [RFC3948]); 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
skipping to change at page 19, line 44 skipping to change at page 20, line 9
DNSSEC. DNSSEC.
7. IANA Considerations 7. IANA Considerations
There are no IANA considerations defined in this document. There are no IANA considerations defined in this document.
8. Conclusion 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 IPv6 networks are currently the only 'standardized' scenario where an IPv6
only host communicates with an IPv4 only host using NAT-PT as only host communicates with an IPv4 only host using NAT-PT as
described in the 3GPP IPv6 transition analysis described in the 3GPP IPv6 transition analysis [I-D.ietf-v6ops-3gpp-
[I-D.ietf-v6ops-3gpp-analysis] but NAT-PT has seen some limited usage analysis] but NAT-PT has seen some limited usage for other purposes.
for other purposes.
Although some of issues identified with NAT-PT appear to have Although some of issues identified with NAT-PT appear to have
solutions, many of the solutions required significant alterations to solutions, many of the solutions required significant alterations to
the existing specification and would be likely to increase the existing specification and would be likely to increase
operational complexity. Even if these solutions were applied, we operational complexity. Even if these solutions were applied, we
have shown that NAT-PT still has significant irresolvable issues and have shown that NAT-PT still has significant irresolvable issues and
appears to have limited applicability. The potential constraints on appears to have limited applicability. The potential constraints on
the development of IPv6 applications described in Section 5 are the development of IPv6 applications described in Section 5 are
particularly un desirable. It appears that alternatives to NAT-PT particularly un desirable. It appears that alternatives to NAT-PT
exist to cover the circumstances where NAT-PT has been suggested as a exist to cover the circumstances where NAT-PT has been suggested as a
skipping to change at page 20, line 22 skipping to change at page 20, line 34
scenarios. scenarios.
However it is clear that in some circumstances a IPv6/IPv4 protocol However it is clear that in some circumstances a 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
which are not determined in advance. It is therefore possible that a which are not determined in advance. It is therefore 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 the IETF no longer recommends its usage as a general Accordingly we recommend that the IETF no longer suggest its usage as
purpose IPv4/IPv6 transition mechanisms but NAT-PT will be retained a general IPv4/IPv6 transition mechanism in the Internet but retain
as an experimental mechanisms while further experience is gained and it as an experimental mechanism while further experience is gained
any future replacement is defined and deployed. Consequently, we and any future replacement is defined and deployed. Consequently we
request that RFC2766 is reclassified from Standards Track to recommend moving RFC2766 to experimental status.
Experimental status.
9. Acknowledgments 9. 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 in Section 1 has been extremely useful in creating documents referred in Section 1 has been extremely useful in creating
this document. Particular thanks are due to Pekka Savola for rapid this document. Particular thanks are due to Pekka Savola for rapid
and thorough review of the document. and thorough review of the document.
10. References 10. References
skipping to change at page 21, line 8 skipping to change at page 21, line 22
February 2000. February 2000.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[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 Complications
with the IP Network Address Translator", RFC 3027, January with the IP Network Address Translator", RFC 3027,
2001. January 2001.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
Compression (ROHC): Framework and four profiles: RTP, UDP, Compression (ROHC): Framework and four profiles: RTP, UDP,
ESP, and uncompressed", RFC 3095, July 2001. ESP, and uncompressed", RFC 3095, July 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.
skipping to change at page 21, line 42 skipping to change at page 22, line 7
Loughney, J., "IPv6 Node Requirements", Loughney, J., "IPv6 Node Requirements",
draft-ietf-ipv6-node-requirements-11 (work in progress), draft-ietf-ipv6-node-requirements-11 (work in progress),
August 2004. August 2004.
[I-D.ietf-v6ops-3gpp-analysis] [I-D.ietf-v6ops-3gpp-analysis]
Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in
progress), October 2004. progress), October 2004.
[I-D.ietf-dnsext-dnssec-intro] [I-D.ietf-dnsext-dnssec-intro]
Arends, R., Austein, R., Massey, D., Larson, M. and S. Arends, R., Austein, R., Massey, D., Larson, M., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-13 (work in progress), draft-ietf-dnsext-dnssec-intro-13 (work in progress),
October 2004. October 2004.
10.2 Informative References 10.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", RFC 1858,
October 1995. October 1995.
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny [RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001. 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, M.,
Zhang, L. and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. Protocol", RFC 2960, October 2000.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Managed Objects for Synchronous Optical Network (SONET)
RFC 3948, January 2005. Linear Automatic Protection Switching (APS)
Architectures", RFC 3498, March 2003.
[I-D.satapati-v6ops-natpt-applicability] [I-D.satapati-v6ops-natpt-applicability]
Satapati, S., "NAT-PT Applicability", Satapati, S., "NAT-PT Applicability",
draft-satapati-v6ops-natpt-applicability-00 (work in draft-satapati-v6ops-natpt-applicability-00 (work in
progress), October 2003. progress), October 2003.
[I-D.durand-natpt-dns-alg-issues] [I-D.durand-natpt-dns-alg-issues]
Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
draft-durand-natpt-dns-alg-issues-00 (work in progress), draft-durand-natpt-dns-alg-issues-00 (work in progress),
February 2002. February 2002.
skipping to change at page 22, line 48 skipping to change at page 23, line 14
Shin, M. and J. Lee, "Considerations for Mobility Support Shin, M. and J. Lee, "Considerations for Mobility Support
in NAT-PT", draft-lee-v6ops-natpt-mobility-00 (work in in NAT-PT", draft-lee-v6ops-natpt-mobility-00 (work in
progress), June 2003. progress), June 2003.
[I-D.okazaki-v6ops-natpt-security] [I-D.okazaki-v6ops-natpt-security]
Okazaki, S. and A. Desai, "NAT-PT Security Okazaki, S. and A. Desai, "NAT-PT Security
Considerations", draft-okazaki-v6ops-natpt-security-00 Considerations", draft-okazaki-v6ops-natpt-security-00
(work in progress), June 2003. (work in progress), June 2003.
[I-D.vanderpol-v6ops-translation-issues] [I-D.vanderpol-v6ops-translation-issues]
Pol, R., Satapati, S. and S. Sivakumar, "Issues when Pol, R., Satapati, S., and S. Sivakumar, "Issues when
translating between IPv4 and IPv6", translating between IPv4 and IPv6",
draft-vanderpol-v6ops-translation-issues-00 (work in draft-vanderpol-v6ops-translation-issues-00 (work in
progress), January 2003. progress), January 2003.
[I-D.elmalki-sipping-3gpp-translator] [I-D.elmalki-sipping-3gpp-translator]
Malki, K., "IPv6-IPv4 Translation mechanism for SIP-based Malki, K., "IPv6-IPv4 Translation mechanism for SIP-based
services in Third Generation Partnership Project (3GPP) services in Third Generation Partnership Project (3GPP)
Networks", draft-elmalki-sipping-3gpp-translator-00 (work Networks", draft-elmalki-sipping-3gpp-translator-00 (work
in progress), December 2003. in progress), December 2003.
[I-D.tsuchiya-mtp] [I-D.tsuchiya-mtp]
Tsuchiya, K., Higuchi, H., Sawada, S. and S. Nozaki, "An Tsuchiya, K., Higuchi, H., Sawada, S., and S. Nozaki, "An
IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying
(mtp)", draft-tsuchiya-mtp-01 (work in progress), February (mtp)", draft-tsuchiya-mtp-01 (work in progress),
2003. February 2003.
[I-D.venaas-mboned-v4v6mcastgw] [I-D.venaas-mboned-v4v6mcastgw]
Venaas, S., "An IPv4 - IPv6 multicast gateway", Venaas, S., "An IPv4 - IPv6 multicast gateway",
draft-venaas-mboned-v4v6mcastgw-00 (work in progress), draft-venaas-mboned-v4v6mcastgw-00 (work in progress),
February 2003. February 2003.
[I-D.park-scalable-multi-natpt] [I-D.park-scalable-multi-natpt]
Park, S., "Scalable mNAT-PT Solution", Park, S., "Scalable mNAT-PT Solution",
draft-park-scalable-multi-natpt-00 (work in progress), May draft-park-scalable-multi-natpt-00 (work in progress),
2003. May 2003.
Authors' Addresses Authors' Addresses
Cedric Aoun Cedric Aoun
Nortel Networks/ENST Paris ENST
Paris
France France
Email: cedric.aoun@nortel.com Email: cedric@caoun.net
Elwyn B. Davies Elwyn B. Davies
Consultant Consultant
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
Intellectual Property Statement Intellectual Property Statement
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/