draft-ietf-v6ops-natpt-to-exprmntl-02.txt | draft-ietf-v6ops-natpt-to-exprmntl-03.txt | |||
---|---|---|---|---|
v6ops Working Group C. Aoun | v6ops Working Group C. Aoun | |||
Internet-Draft ZTE/ENST Paris | Internet-Draft ZTE/ENST Paris | |||
Updates: 2766 (if approved) E. Davies | Updates: 2766 (if approved) E. Davies | |||
Expires: October 3, 2005 Consultant | Expires: April 23, 2006 Consultant | |||
April 2005 | October 20, 2005 | |||
Reasons to Move NAT-PT to Experimental | Reasons to Move NAT-PT to Experimental | |||
draft-ietf-v6ops-natpt-to-exprmntl-02 | draft-ietf-v6ops-natpt-to-exprmntl-03 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
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 | |||
skipping to change at page 1, line 35 | skipping to change at page 1, line 35 | |||
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 October 3, 2005. | This Internet-Draft will expire on April 23, 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 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 | |||
skipping to change at page 2, line 11 | skipping to change at page 2, line 11 | |||
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 | |||
Standards Track to Experimental status. | 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. NAT-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 . . . . . . . . . . . . . . . . . . . 12 | |||
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 . . . . . 14 | |||
3.3. Issues with Lack of Address Persistence . . . . . . . . . 14 | 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 . . . . . . . 15 | |||
4. Issues Directly Related to use of DNS-ALG . . . . . . . . . . 15 | 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 . . . . . . . . . . . . . . . . . . . 15 | Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . . . 16 | |||
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 . . . 18 | |||
4.4. DNS-ALG and Multi-addressed Nodes . . . . . . . . . . . . 17 | 4.4. DNS-ALG and Multi-addressed Nodes . . . . . . . . . . . . 18 | |||
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 . . . . . . . . . . . . 19 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . 24 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 25 | 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) | |||
[RFC2766] defines a set of network layer translation mechanisms | document [RFC2766] defines a set of network-layer translation | |||
designed to allow nodes which only support IPv4 to communicate with | mechanisms designed to allow nodes that only support IPv4 to | |||
nodes which only support IPv6 during the transition to the use of | communicate with nodes that only support IPv6 during the transition | |||
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 NAPT-PT (Network Address Port Translator - Protocol | translated and Network Address Port Translator - Protocol Translator | |||
Translator)which also translates transport identifiers, allowing for | (NAPT-PT), 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]. In the following discussion, where the term | |||
"NAT-PT" is used unqualified, the discussion applies to both basic | ||||
NAT-PT and NAPT-PT. "Basic NAT-PT" will be used if 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 which have not been discussed elsewhere. Where solutions to | issues that have not been discussed elsewhere. Where solutions to | |||
the issues have been proposed these are mentioned and any resulting | the issues have been proposed, these are mentioned and any resulting | |||
need for changes to the specification identified. | need for changes to the specification is identified. | |||
Whereas NAT is seen as an on-going capability which is needed to | Whereas NAT is seen as an ongoing capability that is needed to work | |||
workaround the limited availability of globally unique IPv4 | around the limited availability of globally unique IPv4 addresses, | |||
addresses, NAT-PT has a different status as a transition mechanism | NAT-PT has a different status as a transition mechanism for IPv6. As | |||
for IPv6. As such, NAT-PT should not be allowed to constrain the | such, NAT-PT should not be allowed to constrain the development of | |||
development of IPv6 applications or impose limitations on future | IPv6 applications or impose limitations on future developments of | |||
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 | |||
future constraints on the development of IPv6 networks (see | future constraints on the development of IPv6 networks (see | |||
Section 5), make it undesirable to recommend NAT-PT as described in | Section 5), make it undesirable to recommend NAT-PT as described in | |||
[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 that can | |||
only support IPv4 will need to communicate with a node which can only | only support IPv4 will need to communicate with a node that can only | |||
support IPv6: this is bound to need a translation mechanism of some | support IPv6; this needs a translation mechanism of some kind. | |||
kind. Although this may be better carried out by an application | Although this may be better carried out by an application-level proxy | |||
level proxy or transport layer translator, there may still be | or transport-layer translator, there may still be scenarios in which | |||
scenarios in which a (possibly restricted) version of NAT-PT can be a | a (possibly restricted) version of NAT-PT can be a suitable solution; | |||
suitable solution: accordingly this document recommends that the IETF | accordingly, this document recommends that the IETF should reclassify | |||
should reclassify RFC2766 from Standards Track to Experiemental | RFC2766 from Standards Track to Experimental status. | |||
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 [I-D.satapati-v6ops-natpt- | o NAT-PT applicability statement [I-D.satapati-v6ops-natpt- | |||
applicability] | applicability] | |||
o Issues with NAT-PT DNS ALG in RFC2766 [I-D.durand-natpt-dns-alg- | o Issues with NAT-PT DNS ALG in RFC2766 [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 [I-D.vanderpol- | o Issues when translating between IPv4 and IPv6 [I-D.vanderpol- | |||
skipping to change at page 4, line 23 | skipping to change at page 4, line 26 | |||
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 [I-D.vanderpol- | o Issues when translating between IPv4 and IPv6 [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 [I-D.elmalki- | Generation Partnership Project (3GPP) Networks [I-D.elmalki- | |||
sipping-3gpp-translator] | sipping-3gpp-translator] | |||
o Analysis on IPv6 Transition in 3GPP Networks [I-D.ietf-v6ops-3gpp- | o Analysis on IPv6 Transition in 3GPP Networks [I-D.ietf-v6ops-3gpp- | |||
analysis] | analysis] | |||
o Considerations for Mobile IP Support in NAT-PT [I-D.lee-v6ops- | o Considerations for Mobile IP Support in NAT-PT [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 Internet Group | |||
[I-D.tsuchiya-mtp] | Management Protocol / Multicast Listener Discovery (IGMP/MLD) | |||
Proxying (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. | |||
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 | |||
skipping to change at page 4, line 36 | skipping to change at page 4, line 40 | |||
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. | |||
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. | |||
This is important because a number of the major issues arise from the | This is important because a number of the major issues arise from the | |||
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. Therefore, this | |||
therefore 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 the issues which are not specifically related to the use of | Note that issues not specifically related to the use of the DNS-ALG | |||
the DNS-ALG will apply to any network layer translation scheme, | will apply to any network-layer translation scheme, including any | |||
including any based on the SIIT algorithm [RFC2765]. | 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: | |||
* Disruption of all protocols which embed IP addresses (and/or | ||||
ports) in packet payloads or which apply integrity mechanisms | o Issues that are independent of the use of a DNS-ALG and are, | |||
using IP addresses (and ports). | therefore, applicable to any form of IPv6-IPv4 translator: | |||
* Inability to re-direct traffic for protocols without any | * Disruption of all protocols that embed IP addresses (and/or | |||
demultiplexing capabilities or not built on top of specific | ports) in packet payloads or apply integrity mechanisms using | |||
transport layer protocols in situations where one NAPT-PT is | IP addresses (and ports). | |||
* Inability to re-direct traffic for protocols that lack | ||||
demultiplexing capabilities or are not built on top of specific | ||||
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 that 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 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 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 that 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 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 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 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 contents are altered. [RFC2766] describes the | |||
consequences as part of the description of the FTP ALG: similar | 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 | |||
authentication and encryption with NAT are also applicable to NAT-PT. | authentication and encryption with NAT, are also applicable to | |||
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 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 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. 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 [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 (in transport and tunnel mode) and IPsec ESP (in transport | |||
mode) are unable to be carried through NAT-PT without terminating the | mode) is 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 | |||
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 SPI as an alternative demultiplexer) and protocols, such as RSVP, | the Security Parameter Index (SPI) as an alternative demultiplexer) | |||
which are carried directly in IP datagrams rather than using a | and protocols, such as RSVP, which are carried directly in IP | |||
standard transport layer protocol such as TCP or UDP. In the case of | datagrams rather than using a standard transport-layer protocol such | |||
RSVP, packets going from the IPv4 domain to the IPv6 domain do not | as TCP or UDP. In the case of RSVP, packets going from the IPv4 | |||
necessarily carry a suitable demultiplexing field, because the port | domain to the IPv6 domain do not necessarily carry a suitable | |||
fields in the flow identifer and traffic specifications are optional. | demultiplexing field, because the port 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 | |||
not met in a deployment the workaround may not work as expected). | are 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. | |||
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 NAT-PT and NAPT-PT. NA(P)T-PT uses | need for IPv4 addresses both for basic NAT-PT and NAPT-PT. Both | |||
soft state mechanisms to manage the address and port pools used for | basic NAT-PT and NAPT-PT use soft state mechanisms to manage the | |||
dynamically created address bindings. This allows the NA(P)T-PT to | address and, in the case of NAPT-PT, port pools used for dynamically | |||
operate autonomously without requiring clients to signal either | created address bindings. This allows all types of NAT-PT box to | |||
implicitly or explicitly that a binding is no longer required. In | operate autonomously without requiring clients to signal, either | |||
any case, without soft state timeouts network and application | implicitly or explicitly, that a binding is no longer required. In | |||
any case, without soft state timeouts, network and application | ||||
unreliability would inevitably lead to leaks, eventually causing | unreliability would inevitably lead to leaks, eventually causing | |||
address or port pool exhaustion. | 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 (which 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 NAT-PT | will be broken. Hence, all applications need to maintain their | |||
bindings during long idle periods by incorporating a keep-alive | NAT-PT bindings during long idle periods by incorporating a keep- | |||
mechanism, which may not be possible for legacy systems. | alive 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 is 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 flow | IPv6 header. Hence, any special treatment of packets based on | |||
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 | 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. In the future, new headers may be | |||
which do not have equivalents in IPv4. In practice, some existing | defined that do not have equivalents in IPv4. In practice, some | |||
extensions such as routing headers and mobility extensions are not | existing extensions such as routing headers and mobility | |||
translatable. | extensions are not translatable. | |||
o As described in section 2.2 of [I-D.satapati-v6ops-natpt- | o As described in Section 2.2 of [I-D.satapati-v6ops-natpt- | |||
applicability] there are no equivalents in IPv6 for some ICMP(v4) | applicability], there are no equivalents in IPv6 for some ICMP(v4) | |||
messages, while for others (notably the 'Parameter Problem' | messages, while for others (notably the 'Parameter Problem' | |||
messages) the semantics are not equivalent. Translation of such | messages) the semantics are not equivalent. Translation of such | |||
messages may lead to loss of information. However, this issue may | messages may lead to loss of information. However, this issue may | |||
not be very severe because the error messages relate to packets | not be very severe because the error messages relate to packets | |||
that have been translated by NAT-PT rather than arbitrary packets. | that have been translated by NAT-PT rather than arbitrary packets. | |||
If the NAT-PT is functioning correctly, there is, for example, no | If the NAT-PT is functioning correctly, there is, for example, no | |||
reason why IPv6 packets with unusual extension headers or options | reason why IPv6 packets with unusual extension headers or options | |||
should be generated. This case is cited in [I-D.satapati-v6ops- | should be generated. This case is cited in [I-D.satapati-v6ops- | |||
natpt-applicability] as an example where the IPv6 error has no | natpt-applicability] as an example where the IPv6 error has no | |||
equivalent in IPv4 resulting in lost information. | equivalent in IPv4 resulting 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. NA(P)T-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 generally 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 about fragmented packets in transit. | |||
This is not a complete solution because fragment misordering could | This is not a complete solution because fragment misordering could | |||
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 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 IPv6 stateful packet inspection. The current | |||
specifications of IPv6 do not mandate any minimum packet size beyond | specifications of IPv6 do not mandate (1) any minimum packet size | |||
the need to carry the unfragmentable part (which doesn't include the | beyond the need to carry the unfragmentable part (which doesn't | |||
transport port numbers) or reassembly rules to minimise the effects | include the transport port numbers) or (2) reassembly rules to | |||
of overlapping fragments, leaving IPv6 open to the sort of attacks | minimize the effects of overlapping fragments. Thus, IPv6 is open to | |||
described in [RFC1858] and [RFC3128]. | 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 a NAT-PT box. As | does not have a transport-layer checksum, traverses any type of | |||
described in [RFC2766], the NAT-PT has to reconstruct the whole | NAT-PT box. As described in [RFC2766], the NAT-PT has to reconstruct | |||
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 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 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 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 NAT-PT | |||
the NAT-PT even less scaleable (see Section 3.2). | would consume extra memory and CPU resources, making the NAT-PT even | |||
less scalable (see Section 3.2). | ||||
Packet reassembly in NA(P)T-PT 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 | |||
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 | |||
that similar techniques could be used. | that similar techniques could be used. | |||
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 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 were changed with consequent | fields in the SCTP control packets be changed with consequent changes | |||
changes to packet length: the transport checksum would also have to | to packet length; the transport checksum would also have to be | |||
be recalculated. The ramifications of multihoming as it might | recalculated. The ramifications of multihoming as it might interact | |||
interact with NAT-PT have not been fully explored. Because of the | with NAT-PT have not been fully explored. Because of the 'chunked' | |||
'chunked' nature of data transfer it does not appear that state would | nature of data transfer, it does not appear that state would have to | |||
have to be maintained to relate packets transmitted using the | be maintained to relate packets transmitted using the different IP | |||
different IP addresses associated with the connection. [Author's | 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 | |||
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 [I-D.ietf-ipv6-node- | According to the IPv6 Node Requirements [I-D.ietf-ipv6-node- | |||
requirements], IPv6 nodes should normally be prepared to support the | requirements], IPv6 nodes should normally be prepared to support the | |||
route optimization mechanisms needed in a correspondent node. If | route optimization mechanisms needed in a correspondent node. If | |||
communications from an IPv6 mobile node is traversing a NAT-PT, the | communications from an IPv6 mobile node are traversing a NAT-PT, the | |||
destination IPv4 node is not going to support the correspondent node | destination IPv4 node will certainly not be able to support the | |||
features needed for route optimization. | correspondent node features needed for route 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, | |||
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 which 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 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 which | mechanism to handle multicast. This uses a separate gateway that | |||
understands some or all of the relevant multicast control and routing | understands some or all of the relevant multicast control and routing | |||
protocols in each domain. This work has not been carried through | protocols in each domain. This work has not been carried through | |||
into standards as yet. | into standards as yet. | |||
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)' [I-D.tsuchiya-mtp]. A more | |||
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 | |||
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 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 so that the DNS-ALG is able to examine all | |||
all DNS requests made over IPv6. On sites with both IPv6 and dual- | DNS requests made over IPv6. On sites with both IPv6 and dual-stack | |||
stack nodes, this will result in all traffic flowing through the | nodes, this will result in all traffic flowing through the NAT-PT | |||
NAT-PT with consequent scalability concerns. | with consequent scalability concerns. | |||
These constraints are described in more detail in [I-D.durand-natpt- | These constraints are described in more detail in [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 | |||
for the NAT-PT box to be the default IPv6 gateway for the domain. | 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. | |||
skipping to change at page 13, line 28 | skipping to change at page 14, line 4 | |||
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 DNS RR [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 DNS | through the NAT-PT for all DNS requests will exacerbate the other | |||
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 and the anchoring of flows to a | |||
particular NAT-PT makes the NAT-PT a potential single point of | particular NAT-PT makes the NAT-PT a potential single point of | |||
failure in the network. The addition of the DNS-ALG in NAT-PT | failure in the network. The addition of the DNS-ALG in NAT-PT | |||
further increases the scalability concerns. | 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 [I-D.park-scalable-multi-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 | 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 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 this 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 lifetime | possibilities if very long validities are allowed. Also, the | |||
should be adjusted once the NAT-PT determines which protocol is being | lifetime should be adjusted once the NAT-PT determines which protocol | |||
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 bindings | As discussed in Section 2.3, a NAT-PT may create dynamic NAT | |||
each of which consumes memory resources as well as an address (or | bindings, each of which consumes memory resources as well as an | |||
port if NAPT-PT is used) from an address (or port) pool. A number of | address (or port if NAPT-PT is used) from an address (or port) pool. | |||
documents, including [RFC2766] and [I-D.okazaki-v6ops-natpt-security] | A number of documents, including [RFC2766] and [I-D.okazaki-v6ops- | |||
discuss possible denial of service (DOS) attacks on NA(P)T-PT which | natpt-security] discuss possible denial of service (DoS) attacks on | |||
result in resource depletion associated with address and port pools. | basic NAT-PT and NAPT-PT that result in resource depletion associated | |||
NAT-PT does not specify any authentication mechanisms so that an | with address and port pools. NAT-PT does not specify any | |||
attacker may be able to create spurious binds by spoofing addresses | authentication mechanisms; thus, an attacker may be able to create | |||
in packets sent through NAT-PT. The attack is more damaging if the | spurious bindings by spoofing addresses in packets sent through | |||
attacker is able to spoof protocols with long binding timeouts | NAT-PT. The attack is more damaging if the attacker is able to spoof | |||
(typically used for TCP). | protocols with long binding 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 | that 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 basic NAT-PT | |||
without any end-host authentication or authorization mechanisms. | or NAPT-PT binding without any end-host authentication or | |||
This behavior could lead to a serious DOS attack on both memory and | authorization mechanisms. This behavior could lead to a serious DoS | |||
address or port pools. Address spoofing is not required for this | attack on both memory and address or port pools. Address spoofing is | |||
attack to be successful. | not required for this attack to be successful. | |||
[I-D.hallin-natpt-dns-alg-solutions] proposes to mitigate the DOS | [I-D.hallin-natpt-dns-alg-solutions] proposes to mitigate the DoS | |||
attack by using ACLs and static binds which increases the operational | attack by using Access Control Lists (ACLs) and static binds, which | |||
cost and may not always be practical. | increases the 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 | [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 resource records (RRs) from two possible sources | |||
which has made an AAAA DNS query AAAA. | to the IPv6 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 which is obviously | translated address over the native IPv6 address; this is obviously | |||
undesirable. | undesirable. | |||
[I-D.hallin-natpt-dns-alg-solutions] proposes a solution which | [I-D.hallin-natpt-dns-alg-solutions] proposes a solution that | |||
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, sequential queries of which the client is | |||
aware of. It may be possible to reduce the response time by | not aware. 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 | |||
A query if the AAAA returns one or more addresses. However it is | A query if the AAAA returns one or more addresses. However, it is | |||
still necessary to delay after receiving the first response to | still necessary to delay after receiving the first response to | |||
determine if a second is coming, which may still trigger the DNS | determine if a second is coming, which may still trigger the DNS | |||
client timeout. | 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 have, | |||
within its address selection policies the NAT-PT PREFIX [RFC2766] | within its address selection policies, the NAT-PT PREFIX [RFC2766] | |||
used and assign to it a low selection priority. This solution | used and to assign it a low selection priority. This solution | |||
requires a automatic configuration of the NAT-PT PREFIX as well as | requires an automatic configuration of the NAT-PT PREFIX as well as | |||
its integration within the address selection policies. The simplest | its integration within the address selection policies. The simplest | |||
way to integrate this automatic configuration would be through | way to integrate this automatic configuration would be through | |||
configuration file download (in case the host or DHCPv6 server did | configuration file download (in case the host or Dynamic Host | |||
not support vendor options - to avoid standardization effort on the | Configuration Protocol for IPv6 (DHCPv6) server did not support | |||
NAT-PT PREFIX option). This solution does not require any | vendor options, to avoid standardization effort on the NAT-PT PREFIX | |||
modification to the NAT-PT specification. | option). This solution does not require any modification to 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 identified in [I-D.durand-natpt-dns-alg-issues]. | selection that is identified in [I-D.durand-natpt-dns-alg-issues]. | |||
Applications have no way of knowing that the IPv6 address returned | Applications have no way of knowing that the IPv6 address returned | |||
from the DNS-ALG is not a 'real' IPv6 address, but a translated IPv4 | from the DNS-ALG is not a 'real' IPv6 address, but a translated IPv4 | |||
address. The application may therefore be led to believe that it has | address. The application may therefore be led to believe that it has | |||
end-to-end IPv6 connectivity with the destination. As a result, the | end-to-end IPv6 connectivity with the destination. As a result, the | |||
application may use IPv6 specific options that are not supported by | application may use IPv6-specific options that are not supported by | |||
NAT-PT. This issue is closely related to the issue described in | NAT-PT. This issue is closely related to the issue described in | |||
Section 4.2 and the discussion in Section 5. | Section 4.2 and 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 which pass on retrieved DNS records to other | Applications that pass on retrieved DNS records to other applications | |||
applications will generally assume that they can rely on the passed | will generally assume that they can rely on the passed on addresses | |||
on addresses to be usable by the receiving application. This may not | to be usable by the receiving application. This may not be the case | |||
be the case if the receiving application is on another node | if the receiving application is on another node, especially if it is | |||
especially if it is not in the domain served by the NAT-PT which | not in the domain served by the NAT-PT that generated the | |||
generated the 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 which 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 IPv4 side. The default action is to translate the | |||
response. | response. | |||
The specification of NAT-PT could be modified to maintain minimal | The specification of NAT-PT could be modified to maintain 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 NAT-PT and | This could be a significant drain on resources in both basic NAT-PT | |||
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 mutiple addresses: also it is not clear | if multiple NAT-PTs translate multiple addresses. Also, it is not | |||
that SCTP will actually look up all the destination IP addresses via | clear that SCTP will actually look up all the destination IP | |||
DNS so that bindings may not be in place when packets arrive. | addresses via DNS so that bindings may not be in place when packets | |||
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 | |||
Section 7.5 of [RFC2766]. | Section 7.5 of [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 accessed in mistake for | and there is a risk that the server could be mistaken for a | |||
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. Because IPv6 may be expected to remove | transparency of the Internet. Therefore, because IPv6 may be | |||
the need for NATs and similar impediments to transparency, developers | expected to remove the need for NATs and similar impediments to | |||
creating applications to work with IPv6 may be tempted to assume that | transparency, developers creating applications to work with IPv6 may | |||
the complex and (development) time-consuming expedients that might | be tempted to assume that the complex expedients that might have been | |||
have been needed to make the application work in an 'NATted' IPv4 | needed to make the application work in a 'NATted' IPv4 environment | |||
environment are not required. | are not required. | |||
Consequently some classes of applications (e.g., peer-to-peer) that | Consequently, some classes of applications (e.g., peer-to-peer) that | |||
would need special measures to manage NAT traversal, including | would need special measures to manage NAT traversal, including | |||
special encapsulations, attention to binding lifetime and provision | special encapsulations, attention to binding lifetime, and provision | |||
of keepalives, may build in assumptions on whether IPv6 is being used | of keepalives, may build in assumptions on whether IPv6 is being used | |||
or not. Developers would also like to exploit additional | or not. Developers would also like to exploit additional | |||
capabilities of IPv6 not available in IPv4. | capabilities of IPv6 not available in IPv4. | |||
NAT-PT as specified in [RFC2766] is intended to work autonomously and | NAT-PT as specified in [RFC2766] is intended to work autonomously and | |||
be transparent to applications. There is therefore no way for | be transparent to applications. Therefore, there is no way for | |||
application developers to discover that a path contains a NAT-PT. | application developers to discover that a path contains a NAT-PT. | |||
If NAT-PT is deployed, applications that have assumed a NAT-free IPv6 | If NAT-PT is deployed, applications that have assumed a NAT-free IPv6 | |||
environment may break when the traffic passes through a NAT-PT. This | environment may break when the traffic passes through a NAT-PT. This | |||
is bad enough, but requiring developers to include special | is bad enough, but requiring developers to include special | |||
capabilities to workaround what is supposed to be a temporary | capabilities to workaround what is supposed to be a temporary | |||
transition 'aid' is even worse. Finally, deployment of NAT-PT is | transition 'aid' is even worse. Finally, deployment of NAT-PT is | |||
likely to inhibit the development and use of additional IPv6 | likely to inhibit the development and use of additional IPv6 | |||
capabilities enabled by the flexible extension header system in IPv6 | capabilities enabled by the flexible extension header system in IPv6 | |||
packets. | packets. | |||
Some of these deleterious effects could possibly be alleviated if | Some of these deleterious effects could possibly be alleviated if | |||
applications could discover the presence of NAT-PT boxes on paths in | applications could discover the presence of NAT-PT boxes on paths in | |||
use, allowing them to take steps to workaround the problems. However | use, allowing the applications to take steps to workaround the | |||
requiring applications to incorporate extra code to workaround | problems. However, requiring applications to incorporate extra code | |||
problems with a transition aid still seems to be a very bad idea: the | to workaround problems with a transition aid still seems to be a very | |||
behavior of the application in native IPv6 and NAT-PT environments | bad idea: the behavior of the application in native IPv6 and NAT-PT | |||
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. | |||
skipping to change at page 19, line 34 | skipping to change at page 20, line 21 | |||
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 | |||
[RFC2535] and how deployment of NAT-PT may inhibit deployment of | [RFC2535] and how deployment of NAT-PT may inhibit deployment of | |||
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 'standardised' scenario where an | |||
only host communicates with an IPv4 only host using NAT-PT as | IPv6-only host communicates with an IPv4-only host using NAT-PT as | |||
described in the 3GPP IPv6 transition analysis [I-D.ietf-v6ops-3gpp- | described in the 3GPP IPv6 transition analysis [I-D.ietf-v6ops-3gpp- | |||
analysis] but NAT-PT has seen some limited usage for other purposes. | analysis], but NAT-PT has seen some limited usage for other purposes. | |||
Although some of 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 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 | |||
solution, such as the use of tunneling and header compression in 3GPP | solution, such as the use of tunneling and header compression in 3GPP | |||
scenarios. | scenarios. | |||
However it is clear that in some circumstances a 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 | |||
which are not determined in advance. It is therefore 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 the IETF no longer suggest its usage as | Accordingly, we recommend that the IETF no longer suggest its usage | |||
a general IPv4/IPv6 transition mechanism in the Internet but retain | as a general IPv4/IPv6 transition mechanism in the Internet, but | |||
it as an experimental mechanism while further experience is gained | retain it as an experimental mechanism while further experience is | |||
and any future replacement is defined and deployed. Consequently we | gained and any future replacement is defined and deployed. | |||
recommend moving RFC2766 to experimental status. | Consequently, we recommend moving RFC2766 to 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 to in Section 1 has been extremely useful in | |||
this document. Particular thanks are due to Pekka Savola for rapid | creating this document. Particular thanks are due to Pekka Savola | |||
and thorough review of the document. | for rapid and thorough review of the document. | |||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm | [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm | |||
(SIIT)", RFC 2765, February 2000. | (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)", RFC 2766, | |||
End of changes. 123 change blocks. | ||||
277 lines changed or deleted | 305 lines changed or added | |||
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |