draft-ietf-v6ops-natpt-to-exprmntl-00.txt | draft-ietf-v6ops-natpt-to-exprmntl-01.txt | |||
---|---|---|---|---|
v6ops Working Group C. Aoun | v6ops Working Group C. Aoun | |||
Internet-Draft Nortel Networks/ENST Paris | Internet-Draft ENST | |||
Updates: 2766 (if approved) E. Davies | Updates: 2766 (if approved) E. Davies | |||
Expires: July 5, 2005 Consultant | Expires: January 6, 2006 Consultant | |||
January 2005 | July 5, 2005 | |||
Reasons to Move NAT-PT to Experimental | Reasons to Move NAT-PT to Experimental | |||
draft-ietf-v6ops-natpt-to-exprmntl-00 | draft-ietf-v6ops-natpt-to-exprmntl-01 | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is subject to all provisions | By submitting this Internet-Draft, each author represents that any | |||
of Section 3 of RFC 3667. By submitting this Internet-Draft, each | applicable patent or other IPR claims of which he or she is aware | |||
author represents that any applicable patent or other IPR claims of | have been or will be disclosed, and any of which he or she becomes | |||
which he or she is aware have been or will be disclosed, and any of | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
which he or she become aware will be disclosed, in accordance with | ||||
RFC 3668. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as | other groups may also distribute working documents as Internet- | |||
Internet-Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on July 5, 2005. | This Internet-Draft will expire on January 6, 2006. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2005). | |||
Abstract | Abstract | |||
This document discusses issues with the specific form of IPv6-IPv4 | This document discusses general issues with all forms of IPv6-IPv4 | |||
translation and specific issues related to the form of IPv6-IPv4 | ||||
protocol translation mechanism implemented by the Network Address | protocol translation mechanism implemented by the Network Address | |||
Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These | Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These | |||
issues are sufficiently serious that recommending RFC 2766 as a | specific issues are sufficiently serious that recommending RFC 2766 | |||
general purpose transition mechanism is no longer desirable, and this | as a general purpose transition mechanism is no longer desirable, and | |||
document requests that the IETF reclassifies RFC 2766 from Standards | this document recommends that the IETF should reclassify RFC 2766 | |||
Track to Experimental status. | from Standards Track to Experimental status. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Issues Unrelated to DNS-ALG . . . . . . . . . . . . . . . . 6 | 2. Issues Unrelated to DNS-ALG . . . . . . . . . . . . . . . . 6 | |||
2.1 Issues with Protocols Embedding IP Addresses . . . . . . . 6 | 2.1 Issues with Protocols Embedding IP Addresses . . . . . . . 6 | |||
2.2 NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 7 | 2.2 NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 7 | |||
2.3 NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 7 | 2.3 NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 8 | |||
2.4 Loss of Information through Incompatible Semantics . . . . 8 | 2.4 Loss of Information through Incompatible Semantics . . . . 8 | |||
2.5 NA(P)T-PT and Fragmentation . . . . . . . . . . . . . . . 9 | 2.5 NA(P)T-PT and Fragmentation . . . . . . . . . . . . . . . 9 | |||
2.6 NAT-PT Interaction with SCTP and Multihoming . . . . . . . 10 | 2.6 NAT-PT Interaction with SCTP and Multihoming . . . . . . . 10 | |||
2.7 NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 10 | 2.7 NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 11 | |||
2.8 NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 11 | 2.8 NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 11 | |||
3. Issues exacerbated by the Use of DNS-ALG . . . . . . . . . . 12 | 3. Issues exacerbated by the Use of DNS-ALG . . . . . . . . . . 12 | |||
3.1 Network Topology Constraints Implied by NAT-PT . . . . . . 12 | 3.1 Network Topology Constraints Implied by NAT-PT . . . . . . 12 | |||
3.2 Scalability and Single Point of Failure Concerns . . . . . 13 | 3.2 Scalability and Single Point of Failure Concerns . . . . . 13 | |||
3.3 Issues with Lack of Address Persistence . . . . . . . . . 13 | 3.3 Issues with Lack of Address Persistence . . . . . . . . . 14 | |||
3.4 DOS Attacks on Memory and Address/Port Pools . . . . . . . 14 | 3.4 DOS Attacks on Memory and Address/Port Pools . . . . . . . 14 | |||
4. Issues Directly Related to use of DNS-ALG . . . . . . . . . 15 | 4. Issues Directly Related to use of DNS-ALG . . . . . . . . . 15 | |||
4.1 Address Selection Issues when Communicating with | 4.1 Address Selection Issues when Communicating with | |||
Dual-Stack End-hosts . . . . . . . . . . . . . . . . . . . 15 | Dual-Stack End-hosts . . . . . . . . . . . . . . . . . . . 15 | |||
4.2 Non-global Validity of Translated RR Records . . . . . . . 17 | 4.2 Non-global Validity of Translated RR Records . . . . . . . 17 | |||
4.3 Inappropriate Translation of Responses to A Queries . . . 17 | 4.3 Inappropriate Translation of Responses to A Queries . . . 17 | |||
4.4 DNS-ALG and Multi-addressed Nodes . . . . . . . . . . . . 17 | 4.4 DNS-ALG and Multi-addressed Nodes . . . . . . . . . . . . 17 | |||
4.5 Limitations on Deployment of DNS Security Capabilities . . 18 | 4.5 Limitations on Deployment of DNS Security Capabilities . . 18 | |||
5. Impact on IPv6 Application Development . . . . . . . . . . . 18 | 5. Impact on IPv6 Application Development . . . . . . . . . . . 18 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . 19 | 6. Security Considerations . . . . . . . . . . . . . . . . . . 19 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 | |||
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
10.1 Normative References . . . . . . . . . . . . . . . . . . 20 | 10.1 Normative References . . . . . . . . . . . . . . . . . . 21 | |||
10.2 Informative References . . . . . . . . . . . . . . . . . 21 | 10.2 Informative References . . . . . . . . . . . . . . . . . 22 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 23 | |||
Intellectual Property and Copyright Statements . . . . . . . 24 | Intellectual Property and Copyright Statements . . . . . . . 25 | |||
1. Introduction | 1. Introduction | |||
The Network Address Translator - Protocol Translator NAT-PT) document | The Network Address Translator - Protocol Translator NAT-PT) document | |||
[RFC2766] defines a set of network layer translation mechanisms | [RFC2766] defines a set of network layer translation mechanisms. | |||
designed to allow nodes which only support IPv4 to communicate with | These mechanisms are designed to allow nodes which only support IPv4 | |||
nodes which only support IPv6 during the transition to the use of | to communicate with nodes which only support IPv6 during the | |||
IPv6 in the Internet. | transition to the use of IPv6 in the Internet. | |||
[RFC2766] specifies the basic NAT-PT in which only addresses are | [RFC2766] specifies the basic NAT-PT in which only addresses are | |||
translated and NAPT-PT (Network Address Port Translator - Protocol | translated and NAPT-PT (Network Address Port Translator - Protocol | |||
Translator)which also translates transport identifiers, allowing for | Translator)which also translates transport identifiers, allowing for | |||
greater economy of scarce IPv4 addresses. Protocol translation is | greater economy of scarce IPv4 addresses. Protocol translation is | |||
performed using the Stateless IP/ICMP Translation Algorithm (SIIT) | performed using the Stateless IP/ICMP Translation Algorithm (SIIT) | |||
defined in [RFC2765]. | defined in [RFC2765]. | |||
A number of previous documents have raised issues with NAT-PT. This | A number of previous documents have raised issues with NAT-PT. This | |||
document will summarize these issues, note several other issues | document will summarize these issues, note several other issues | |||
skipping to change at page 3, line 48 | skipping to change at page 3, line 48 | |||
[RFC2766] as a general purpose transition mechanism for | [RFC2766] as a general purpose transition mechanism for | |||
intercommunication between IPv6 networks and IPv4 networks. | intercommunication between IPv6 networks and IPv4 networks. | |||
Although the [RFC2766] form of packet translation is not generally | Although the [RFC2766] form of packet translation is not generally | |||
applicable, it is likely that in some circumstances a node which can | applicable, it is likely that in some circumstances a node which can | |||
only support IPv4 will need to communicate with a node which can only | only support IPv4 will need to communicate with a node which can only | |||
support IPv6: this is bound to need a translation mechanism of some | support IPv6: this is bound to need a translation mechanism of some | |||
kind. Although this may be better carried out by an application | kind. Although this may be better carried out by an application | |||
level proxy or transport layer translator, there may still be | level proxy or transport layer translator, there may still be | |||
scenarios in which a (possibly restricted) version of NAT-PT can be a | scenarios in which a (possibly restricted) version of NAT-PT can be a | |||
suitable solution: accordingly this document requests the IETF to | suitable solution: accordingly this document recommends that the IETF | |||
reclassify RFC2766 from Standards Track to Experiemental status. | should reclassify RFC2766 from Standards Track to Experimental | |||
status. | ||||
The following documents relating directly to NAT-PT have been | The following documents relating directly to NAT-PT have been | |||
reviewed while drafting this document: | reviewed while drafting this document: | |||
o Network Address Translation - Protocol Translation (NAT-PT) | o Network Address Translation - Protocol Translation (NAT-PT) | |||
[RFC2766] | [RFC2766] | |||
o Stateless IP/ICMP Translation Algorithm (SIIT) [RFC2765] | o Stateless IP/ICMP Translation Algorithm (SIIT) [RFC2765] | |||
o NAT-PT applicability statement | o NAT-PT applicability statement [I-D.satapati-v6ops-natpt- | |||
[I-D.satapati-v6ops-natpt-applicability] | applicability] | |||
o Issues with NAT-PT DNS ALG in RFC2766 | o Issues with NAT-PT DNS ALG in RFC2766 [I-D.durand-natpt-dns-alg- | |||
[I-D.durand-natpt-dns-alg-issues] | issues] | |||
o NAT-PT DNS ALG solutions [I-D.hallin-natpt-dns-alg-solutions] | o NAT-PT DNS ALG solutions [I-D.hallin-natpt-dns-alg-solutions] | |||
o NAT-PT Security Considerations [I-D.okazaki-v6ops-natpt-security] | o NAT-PT Security Considerations [I-D.okazaki-v6ops-natpt-security] | |||
o Issues when translating between IPv4 and IPv6 | o Issues when translating between IPv4 and IPv6 [I-D.vanderpol- | |||
[I-D.vanderpol-v6ops-translation-issues] | v6ops-translation-issues] | |||
o IPv6-IPv4 Translation mechanism for SIP-based services in Third | o IPv6-IPv4 Translation mechanism for SIP-based services in Third | |||
Generation Partnership Project (3GPP) Networks | Generation Partnership Project (3GPP) Networks [I-D.elmalki- | |||
[I-D.elmalki-sipping-3gpp-translator] | sipping-3gpp-translator] | |||
o Analysis on IPv6 Transition in 3GPP Networks | o Analysis on IPv6 Transition in 3GPP Networks [I-D.ietf-v6ops-3gpp- | |||
[I-D.ietf-v6ops-3gpp-analysis] | analysis] | |||
o Considerations for Mobile IP Support in NAT-PT | o Considerations for Mobile IP Support in NAT-PT [I-D.lee-v6ops- | |||
[I-D.lee-v6ops-natpt-mobility] | natpt-mobility] | |||
o An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp) | o An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp) | |||
[I-D.tsuchiya-mtp] | [I-D.tsuchiya-mtp] | |||
o An IPv4 - IPv6 multicast gateway [I-D.venaas-mboned-v4v6mcastgw] | o An IPv4 - IPv6 multicast gateway [I-D.venaas-mboned-v4v6mcastgw] | |||
o Scalable mNAT-PT Solution [I-D.park-scalable-multi-natpt] | o Scalable mNAT-PT Solution [I-D.park-scalable-multi-natpt] | |||
Because the majority of the documents containing discussions of the | Because the majority of the documents containing discussions of the | |||
issues are Internet Drafts which are unlikely to become RFCs, the | issues are Internet Drafts which are unlikely to become RFCs, the | |||
issues are summarized here to avoid the need for normative | issues are summarized here to avoid the need for normative | |||
references. | references. | |||
skipping to change at page 5, line 10 | skipping to change at page 5, line 11 | |||
interactions between DNS and NAT-PT. However, detailed inspection of | interactions between DNS and NAT-PT. However, detailed inspection of | |||
[RFC2766] shows that the 'simple' case has not been worked out and it | [RFC2766] shows that the 'simple' case has not been worked out and it | |||
is unclear how information about the address translation could be | is unclear how information about the address translation could be | |||
passed to the hosts in the absence of the DNS-ALG. This document | passed to the hosts in the absence of the DNS-ALG. This document | |||
therefore assumes that the DNS-ALG is an integral part of NAT-PT: | therefore assumes that the DNS-ALG is an integral part of NAT-PT: | |||
accordingly issues with the DNS-ALG must be considered as issues for | accordingly issues with the DNS-ALG must be considered as issues for | |||
the whole specification. | the whole specification. | |||
Note that the issues which are not specifically related to the use of | Note that the issues which are not specifically related to the use of | |||
the DNS-ALG will apply to any network layer translation scheme, | the DNS-ALG will apply to any network layer translation scheme, | |||
including any based on the SIIT algorithm [RFC2765]. | including any based on the SIIT algorithm [RFC2765]. In the event | |||
that new forms of translator are developed as alternatives to NAT-PT, | ||||
the generic issues relevant to all IPv6-IPv4 translators should be | ||||
borne in mind. | ||||
Issues raised with NAT-PT can be categorized as follows: | Issues raised with IPv6-IPv4 translators in general and NAT-PT in | |||
o Issues which are independent of the use of a DNS-ALG: | particular can be categorized as follows: | |||
o Issues which are independent of the use of a DNS-ALG and are, | ||||
therefore, applicable to any form of IPv6-IPv4 translator: | ||||
* Disruption of all protocols which embed IP addresses (and/or | * Disruption of all protocols which embed IP addresses (and/or | |||
ports) in packet payloads or which apply integrity mechanisms | ports) in packet payloads or which apply integrity mechanisms | |||
using IP addresses (and ports). | using IP addresses (and ports). | |||
* Inability to re-direct traffic for protocols without any | * Inability to re-direct traffic for protocols without any | |||
demultiplexing capabilities or not built on top of specific | demultiplexing capabilities or not built on top of specific | |||
transport layer protocols in situations where one NAPT-PT is | transport layer protocols in situations where one NAPT-PT is | |||
translating for multiple IPv6 hosts. | translating for multiple IPv6 hosts. | |||
* Requirement for applications to use keep alive mechanisms to | * Requirement for applications to use keep alive mechanisms to | |||
workaround connectivity issues caused by premature NAT-PT state | workaround connectivity issues caused by premature NAT-PT state | |||
timeout. | timeout. | |||
* Loss of information due to incompatible semantics between IPv4 | * Loss of information due to incompatible semantics between IPv4 | |||
and IPv6 versions of headers and protocols. | and IPv6 versions of headers and protocols. | |||
* Need for additional state and/or packet reconstruction in | * Need for additional state and/or packet reconstruction in | |||
NAPT-PT translators dealing with packet fragmentation. | NAPT-PT translators dealing with packet fragmentation. | |||
* Interaction with SCTP and multihoming. | * Interaction with SCTP and multihoming. | |||
* Need for NAT-PT to act as proxy for correspondent node when | * Need for NAT-PT to act as proxy for correspondent node when | |||
IPv6 node is mobile, with consequent restrictions on mobility. | IPv6 node is mobile, with consequent restrictions on mobility. | |||
* NAT-PT not being able to handle multicast traffic. | * NAT-PT not being able to handle multicast traffic. | |||
o Issues which are exacerbated by the use of a DNS-ALG: | o Issues which are exacerbated by the use of a DNS-ALG and are, | |||
therefore also applicable to any form of IPv6-IPv4 translator: | ||||
* Constraints on network topology. | * Constraints on network topology. | |||
* Scalability concerns together with introduction of single point | * Scalability concerns together with introduction of single point | |||
of failure and security attack nexus. | of failure and security attack nexus. | |||
* Lack of address mapping persistence: Some applications require | * Lack of address mapping persistence: Some applications require | |||
address retention between sessions. The user traffic will be | address retention between sessions. The user traffic will be | |||
disrupted if a different mapping is used. The use of the | disrupted if a different mapping is used. The use of the DNS- | |||
DNS-ALG to create address mappings with limited lifetimes means | ALG to create address mappings with limited lifetimes means | |||
that applications must start using the address shortly after | that applications must start using the address shortly after | |||
the mapping is created, as well as keeping it alive once they | the mapping is created, as well as keeping it alive once they | |||
start using it. | start using it. | |||
* Creation of a DOS threat relating to exhaustion of memory and | * Creation of a DOS threat relating to exhaustion of memory and | |||
address/port pool resources on the translator. | address/port pool resources on the translator. | |||
o Issues which result from the use of a DNS-ALG: | o Issues which result from the use of a DNS-ALG and are, therefore, | |||
specific to NAT-PT as defined in [RFC2766]: | ||||
* Address selection issues when either the internal or external | * Address selection issues when either the internal or external | |||
hosts implement both IPv4 and IPv6. | hosts implement both IPv4 and IPv6. | |||
* Restricted validity of translated DNS records: a translated | * Restricted validity of translated DNS records: a translated | |||
record may be forwarded to an application which cannot use it. | record may be forwarded to an application which cannot use it. | |||
* Inappropriate translation of responses to A queries from IPv6 | * Inappropriate translation of responses to A queries from IPv6 | |||
nodes. | nodes. | |||
* Address selection issues and resource consumption in DNS-ALG | * Address selection issues and resource consumption in DNS-ALG | |||
with multi-addressed nodes. | with multi-addressed nodes. | |||
* Limitations on DNS security capabilities when using DNS-ALG. | * Limitations on DNS security capabilities when using DNS-ALG. | |||
Section 2, Section 3 and Section 4 discuss these groups of issues. | Section 2, Section 3 and Section 4 discuss these groups of issues. | |||
Section 5 examines the consequences of deploying NAT-PT for | Section 5 examines the consequences of deploying NAT-PT for | |||
application developers and the long term effects of NAT-PT on the | application developers and the long term effects of NAT-PT or any | |||
further development of IPv6. | form of generally deployed IPv6-IPv4 translator on the further | |||
development of IPv6. | ||||
The terminology used in this document is defined in [RFC2663], | The terminology used in this document is defined in [RFC2663], | |||
[RFC2766] and [RFC3314]. | [RFC2766] and [RFC3314]. | |||
2. Issues Unrelated to DNS-ALG | 2. Issues Unrelated to DNS-ALG | |||
2.1 Issues with Protocols Embedding IP Addresses | 2.1 Issues with Protocols Embedding IP Addresses | |||
It is well known from work on IPv4 NATs (see Section 8 of [RFC2663] | It is well known from work on IPv4 NATs (see Section 8 of [RFC2663] | |||
and [RFC3027]) that the large class of protocols which embed numeric | and [RFC3027]) that the large class of protocols which embed numeric | |||
skipping to change at page 6, line 49 | skipping to change at page 7, line 11 | |||
coordinated updates of the ALGs to keep them in step. | coordinated updates of the ALGs to keep them in step. | |||
Assuming that the NAT-PT contains a co-located ALG for one of the | Assuming that the NAT-PT contains a co-located ALG for one of the | |||
relevant protocols, the ALG could replace the embedded IP addresses | relevant protocols, the ALG could replace the embedded IP addresses | |||
and ports. However this replacement can only happen if no | and ports. However this replacement can only happen if no | |||
cryptographic integrity mechanism is used and the protocol messages | cryptographic integrity mechanism is used and the protocol messages | |||
are sent in clear (i.e. not encrypted). | are sent in clear (i.e. not encrypted). | |||
A possible workaround relies on the NAT-PT being party to the | A possible workaround relies on the NAT-PT being party to the | |||
security association used to provide authentication and/or | security association used to provide authentication and/or | |||
encryption. The NAT-PT should then be aware of the cryptographic | encryption. NAT-PT would then be aware of the cryptographic | |||
algorithms and keys used to secure the traffic and could modify and | algorithms and keys used to secure the traffic. It could then modify | |||
re-secure the packets: this would certainly complicate network | and re-secure the packets: this would certainly complicate network | |||
operations and provides additional points of security vulnerability. | operations and provides additional points of security vulnerability. | |||
Unless UDP encapsulation is used for IPsec [RFC3948], traffic using | Unless UDP encapsulation is used for IPsec [RFC3498], traffic using | |||
IPsec AH (in transport and tunnel mode) and IPsec ESP (in transport | IPsec AH (in transport and tunnel mode) and IPsec ESP (in transport | |||
mode) are unable to be carried through NAT-PT without terminating the | mode) are unable to be carried through NAT-PT without terminating the | |||
security associations on the NAT-PT, due to their usage of | security associations on the NAT-PT, due to their usage of | |||
cryptographic integrity protection. | cryptographic integrity protection. | |||
A related issue with DNS security is discussed in Section 4.5. | A related issue with DNS security is discussed in Section 4.5. | |||
2.2 NAPT-PT Redirection Issues | 2.2 NAPT-PT Redirection Issues | |||
Section 4.2 of [RFC3027] discusses problems specific to RSVP and | Section 4.2 of [RFC3027] discusses problems specific to RSVP and | |||
skipping to change at page 7, line 30 | skipping to change at page 7, line 41 | |||
(and any other port translator) because there is nothing for NAPT-PT | (and any other port translator) because there is nothing for NAPT-PT | |||
to use to identify the correct binding. | to use to identify the correct binding. | |||
This type of issue affects IPsec encrypted packets where the | This type of issue affects IPsec encrypted packets where the | |||
transport port is not visible (although it might be possible to use | transport port is not visible (although it might be possible to use | |||
the SPI as an alternative demultiplexer) and protocols, such as RSVP, | the SPI as an alternative demultiplexer) and protocols, such as RSVP, | |||
which are carried directly in IP datagrams rather than using a | which are carried directly in IP datagrams rather than using a | |||
standard transport layer protocol such as TCP or UDP. In the case of | standard transport layer protocol such as TCP or UDP. In the case of | |||
RSVP, packets going from the IPv4 domain to the IPv6 domain do not | RSVP, packets going from the IPv4 domain to the IPv6 domain do not | |||
necessarily carry a suitable demultiplexing field, because the port | necessarily carry a suitable demultiplexing field, because the port | |||
fields in the flow identifer and traffic specifications are optional. | fields in the flow identifier and traffic specifications are | |||
optional. | ||||
Several ad hoc workarounds could be used to solve the demultiplexing | Several ad hoc workarounds could be used to solve the demultiplexing | |||
issues, however in most cases these solutions are not documented | issues, however in most cases these solutions are not documented | |||
anywhere which could lead to non-deterministic, undesirable behavior | anywhere which could lead to non-deterministic, undesirable behavior | |||
(for example, such workarounds often assume particular network | (for example, such workarounds often assume particular network | |||
topologies etc in order to function correctly; if the assumptions are | topologies etc in order to function correctly; if the assumptions are | |||
not met in a deployment the workaround may not work as expected). | not met in a deployment the workaround may not work as expected). | |||
This issue is closely related to the fragmentation issue described in | This issue is closely related to the fragmentation issue described in | |||
Section 2.5. | Section 2.5. | |||
skipping to change at page 8, line 33 | skipping to change at page 8, line 46 | |||
can lead to loss of information when packets are translated. Three | can lead to loss of information when packets are translated. Three | |||
issues arising from this are: | issues arising from this are: | |||
o There is no equivalent in IPv4 for the flow label field of the | o There is no equivalent in IPv4 for the flow label field of the | |||
IPv6 header. Hence any special treatment of packets based on flow | IPv6 header. Hence any special treatment of packets based on flow | |||
label patterns cannot be propagated into the IPv4 domain. | label patterns cannot be propagated into the IPv4 domain. | |||
o IPv6 extension headers provide flexibility for improvements in the | o IPv6 extension headers provide flexibility for improvements in the | |||
IP protocol suite in future. New headers may be defined in future | IP protocol suite in future. New headers may be defined in future | |||
which do not have equivalents in IPv4. In practice, some existing | which do not have equivalents in IPv4. In practice, some existing | |||
extensions such as routing headers and mobility extensions are not | extensions such as routing headers and mobility extensions are not | |||
translatable. | translatable. | |||
o As described in section 2.2 of | o As described in section 2.2 of [I-D.satapati-v6ops-natpt- | |||
[I-D.satapati-v6ops-natpt-applicability] there are no equivalents | applicability] there are no equivalents in IPv6 for some ICMP(v4) | |||
in IPv6 for some ICMP(v4) messages, while for others (notably the | messages, while for others (notably the 'Parameter Problem' | |||
'Parameter Problem' messages) the semantics are not equivalent. | messages) the semantics are not equivalent. Translation of such | |||
Translation of such messages may lead to loss of information. | messages may lead to loss of information. However, this issue may | |||
However, this issue may not be very severe because the error | not be very severe because the error messages relate to packets | |||
messages relate to packets that have been translated by NAT-PT | that have been translated by NAT-PT rather than arbitrary packets. | |||
rather than arbitrary packets. If the NAT-PT is functioning | If the NAT-PT is functioning correctly, there is, for example, no | |||
correctly, there is, for example, no reason why IPv6 packets with | reason why IPv6 packets with unusual extension headers or options | |||
unusual extension headers or options should be generated. This | should be generated. This case is cited in [I-D.satapati-v6ops- | |||
case is cited in [I-D.satapati-v6ops-natpt-applicability] as an | natpt-applicability] as an example where the IPv6 error has no | |||
example where the IPv6 error has no equivalent in IPv4 resulting | equivalent in IPv4 resulting in lost information. | |||
in lost information. | ||||
Loss of information in any of these cases could be a constraint to | Loss of information in any of these cases could be a constraint to | |||
certain applications. | certain applications. | |||
A related matter concerns the propagation of the Differentiated | A related matter concerns the propagation of the Differentiated | |||
Services Code Point (DSCP). NAT-PT and SIIT simply copy the DSCP | Services Code Point (DSCP). NAT-PT and SIIT simply copy the DSCP | |||
field when translating packets. Accordingly the IPv4 and IPv6 | field when translating packets. Accordingly the IPv4 and IPv6 | |||
domains must have equivalent Per-Hop Behaviors for the same code | domains must have equivalent Per-Hop Behaviors for the same code | |||
point or alternative means must be in place to translate the DSCP | point or alternative means must be in place to translate the DSCP | |||
between domains. | between domains. | |||
skipping to change at page 9, line 29 | skipping to change at page 9, line 42 | |||
lead to the first fragment appearing at the NAPT-PT after later | lead to the first fragment appearing at the NAPT-PT after later | |||
fragments. The NAPT-PT would then not have the information needed to | fragments. The NAPT-PT would then not have the information needed to | |||
translate the fragments received before the first. | translate the fragments received before the first. | |||
Although it would not be expected in normal operation, NAPT-PT needs | Although it would not be expected in normal operation, NAPT-PT needs | |||
to be proofed against receiving short first fragments which don't | to be proofed against receiving short first fragments which don't | |||
contain the transport port numbers. Note that such packets are a | contain the transport port numbers. Note that such packets are a | |||
problem for IPv6 stateful packet inspection. The current | problem for IPv6 stateful packet inspection. The current | |||
specifications of IPv6 do not mandate any minimum packet size beyond | specifications of IPv6 do not mandate any minimum packet size beyond | |||
the need to carry the unfragmentable part (which doesn't include the | the need to carry the unfragmentable part (which doesn't include the | |||
transport port numbers) or reassembly rules to minimise the effects | transport port numbers) or reassembly rules to minimize the effects | |||
of overlapping fragments, leaving IPv6 open to the sort of attacks | of overlapping fragments, leaving IPv6 open to the sort of attacks | |||
described in [RFC1858] and [RFC3128]. | described in [RFC1858] and [RFC3128]. | |||
An additional concern arises when a fragmented IPv4 UDP packet, which | An additional concern arises when a fragmented IPv4 UDP packet, which | |||
does not have a transport layer checksum, traverses a NAT-PT box. As | does not have a transport layer checksum, traverses a NAT-PT box. As | |||
described in [RFC2766], the NAT-PT has to reconstruct the whole | described in [RFC2766], the NAT-PT has to reconstruct the whole | |||
packet so that it can calculate the checksum needed for the | packet so that it can calculate the checksum needed for the | |||
translated IPv6 packet. This can result in significant delay to the | translated IPv6 packet. This can result in significant delay to the | |||
packet, especially if it has to be re-fragmented before transmission | packet, especially if it has to be re-fragmented before transmission | |||
on the IPv6 side. | on the IPv6 side. | |||
If NA(P)T-PT boxes reassembled all incoming fragmented packets (both | If NA(P)T-PT boxes reassembled all incoming fragmented packets (both | |||
from the IPv4 and IPv6 directions) in the same way as they have to do | from the IPv4 and IPv6 directions) in the same way as they have to do | |||
for unchecksummed IPv4 UDP packets, this would be a solution to the | for unchecksummed IPv4 UDP packets, this would be a solution to the | |||
first problem. The cost would be considerable: apart from the | first problem. The resource cost would be considerable apart from | |||
potential delay problem if the outgoing packet has to be fragmented, | the potential delay problem if the outgoing packet has to be re- | |||
the NA(P)T-PT would consume extra memory and CPU resources, making | fragmented. In any case fragmentation would mean that the NA(P)T-PT | |||
the NAT-PT even less scaleable (see Section 3.2). | would consume extra memory and CPU resources, making the NAT-PT even | |||
less scaleable (see Section 3.2). | ||||
Packet reassembly in NA(P)T-PT also opens up the possibility of | Packet reassembly in NA(P)T-PT also opens up the possibility of | |||
various fragment-related security attacks. Some of these are | various fragment-related security attacks. Some of these are | |||
analagous to attacks identified for IPv4. Of particular concern is a | analogous to attacks identified for IPv4. Of particular concern is a | |||
DOS attack based on sending large numbers of small fragments without | DOS attack based on sending large numbers of small fragments without | |||
a terminating last fragment which would potentially overload the | a terminating last fragment which would potentially overload the | |||
reconstruction buffers and consume large amounts of CPU resources. | reconstruction buffers and consume large amounts of CPU resources. | |||
2.6 NAT-PT Interaction with SCTP and Multihoming | 2.6 NAT-PT Interaction with SCTP and Multihoming | |||
The Stream Control Transmission Protocol (SCTP) [RFC2960] is a | The Stream Control Transmission Protocol (SCTP) [RFC2960] is a | |||
transport protocol which has been standardized since SIIT was | transport protocol which has been standardized since SIIT was | |||
specified. SIIT does not explicitly cover translation of SCTP, but | specified. SIIT does not explicitly cover translation of SCTP, but | |||
SCTP uses transport port numbers in the same way as UDP and TCP so | SCTP uses transport port numbers in the same way as UDP and TCP so | |||
skipping to change at page 10, line 25 | skipping to change at page 10, line 39 | |||
However, SCTP also supports multihoming. During connection setup | However, SCTP also supports multihoming. During connection setup | |||
SCTP control packets carry embedded addresses which would have to be | SCTP control packets carry embedded addresses which would have to be | |||
translated. This would also require that the types of the options | translated. This would also require that the types of the options | |||
fields in the SCTP control packets were changed with consequent | fields in the SCTP control packets were changed with consequent | |||
changes to packet length: the transport checksum would also have to | changes to packet length: the transport checksum would also have to | |||
be recalculated. The ramifications of multihoming as it might | be recalculated. The ramifications of multihoming as it might | |||
interact with NAT-PT have not been fully explored. Because of the | interact with NAT-PT have not been fully explored. Because of the | |||
'chunked' nature of data transfer it does not appear that state would | 'chunked' nature of data transfer it does not appear that state would | |||
have to be maintained to relate packets transmitted using the | have to be maintained to relate packets transmitted using the | |||
different IP addresses associated with the connection. [Author's | different IP addresses associated with the connection. | |||
Note: This needs to be considered by an SCTP expert]. | ||||
Even if these technical issues can be overcome, using SCTP in a | Even if these technical issues can be overcome, using SCTP in a | |||
NAT-PT environment may effectively nullify the multihoming advantages | NAT-PT environment may effectively nullify the multihoming advantages | |||
of SCTP if all the connections run through the same NAT-PT. The | of SCTP if all the connections run through the same NAT-PT. The | |||
consequences of running a multihomed network with separate NAT-PT | consequences of running a multihomed network with separate NAT-PT | |||
boxes associated with each of the 'homes' have not been fully | boxes associated with each of the 'homes' have not been fully | |||
explored, but one issue that will arise is described in Section 4.4. | explored, but one issue that will arise is described in Section 4.4. | |||
SCTP will need an associated 'ALG' - actually a Transport Layer | SCTP will need an associated 'ALG' - actually a Transport Layer | |||
Gateway - to handle the packet payload modifications. If it turns | Gateway - to handle the packet payload modifications. If it turns | |||
out that state is required, the state would have to distributed and | out that state is required, the state would have to distributed and | |||
synchronized across several NAT-PT boxes in a multihomed environment. | synchronized across several NAT-PT boxes in a multihomed environment. | |||
SCTP running through NAT-PT in a multihomed environment is also | SCTP running through NAT-PT in a multihomed environment is also | |||
incompatible with IPsec as described in Section 2.1. | incompatible with IPsec as described in Section 2.1. | |||
2.7 NAT-PT as a Proxy Correspondent Node for MIPv6 | 2.7 NAT-PT as a Proxy Correspondent Node for MIPv6 | |||
skipping to change at page 10, line 46 | skipping to change at page 11, line 12 | |||
out that state is required, the state would have to distributed and | out that state is required, the state would have to distributed and | |||
synchronized across several NAT-PT boxes in a multihomed environment. | synchronized across several NAT-PT boxes in a multihomed environment. | |||
SCTP running through NAT-PT in a multihomed environment is also | SCTP running through NAT-PT in a multihomed environment is also | |||
incompatible with IPsec as described in Section 2.1. | incompatible with IPsec as described in Section 2.1. | |||
2.7 NAT-PT as a Proxy Correspondent Node for MIPv6 | 2.7 NAT-PT as a Proxy Correspondent Node for MIPv6 | |||
As discussed in [I-D.lee-v6ops-natpt-mobility], it is not possible to | As discussed in [I-D.lee-v6ops-natpt-mobility], it is not possible to | |||
propagate Mobile IPv6 control messages into the IPv4 domain. | propagate Mobile IPv6 control messages into the IPv4 domain. | |||
According to the IPv6 Node Requirements | According to the IPv6 Node Requirements [I-D.ietf-ipv6-node- | |||
[I-D.ietf-ipv6-node-requirements], IPv6 nodes should normally be | requirements], IPv6 nodes should normally be prepared to support the | |||
prepared to support the route optimization mechanisms needed in a | route optimization mechanisms needed in a correspondent node. If | |||
correspondent node. If communications from an IPv6 mobile node is | communications from an IPv6 mobile node are traversing a NAT-PT, the | |||
traversing a NAT-PT, the destination IPv4 node is not going to | destination IPv4 node will certainly not be able to support the | |||
support the correspondent node features needed for route | correspondent node features needed for route optimization. | |||
optimization. | ||||
This can be resolved in two ways: | This can be resolved in two ways: | |||
o The NAT-PT can discard messages and headers relating to changes of | o The NAT-PT can discard messages and headers relating to changes of | |||
care-of addresses including reverse routing checks. | care-of addresses including reverse routing checks. | |||
Communications with the mobile node will continue through the home | Communications with the mobile node will continue through the home | |||
agent without route optimization. This is clearly sub-optimal but | agent without route optimization. This is clearly sub-optimal but | |||
communication should remain possible. | communication should remain possible. | |||
o Additional functionality could be implemented in the NAT-PT to | o Additional functionality could be implemented in the NAT-PT to | |||
allow it to function as a proxy correspondent node for all IPv4 | allow it to function as a proxy correspondent node for all IPv4 | |||
nodes for which it has bindings. This scheme adds considerably to | nodes for which it has bindings. This scheme adds considerably to | |||
skipping to change at page 11, line 49 | skipping to change at page 12, line 13 | |||
comprehensive approach which includes proxying of the multicast | comprehensive approach which includes proxying of the multicast | |||
routing protocols is described in 'An IPv4 - IPv6 multicast gateway' | routing protocols is described in 'An IPv4 - IPv6 multicast gateway' | |||
[I-D.venaas-mboned-v4v6mcastgw]. Both approaches have several of the | [I-D.venaas-mboned-v4v6mcastgw]. Both approaches have several of the | |||
issues described in this section, notably issues with embedded | issues described in this section, notably issues with embedded | |||
addresses. | addresses. | |||
[I-D.okazaki-v6ops-natpt-security] identifies the possibility of a | [I-D.okazaki-v6ops-natpt-security] identifies the possibility of a | |||
multiplicative reflection attack if the NAT-PT can be spoofed into | multiplicative reflection attack if the NAT-PT can be spoofed into | |||
creating a binding for a multicast address. This attack would be | creating a binding for a multicast address. This attack would be | |||
very hard to mount because routers should not forward packets with | very hard to mount because routers should not forward packets with | |||
muticast addresses in the source address field. However, it points | multicast addresses in the source address field. However, it | |||
up that a naively implemented DNS-ALG could create such bindings from | highlights the possibility that a naively implemented DNS-ALG could | |||
spoofed DNS responses since [RFC2766] does not mention the need for | create such bindings from spoofed DNS responses since [RFC2766] does | |||
checks on the types of addresses in these responses. | not mention the need for checks on the types of addresses in these | |||
responses. | ||||
The issues for NAT-PT and multicast reflect the fact that NAT-PT is | The issues for NAT-PT and multicast reflect the fact that NAT-PT is | |||
at best a partial solution. Completing the translation solution to | at best a partial solution. Completing the translation solution to | |||
cater for multicast traffic is likely to carry a similar set of | cater for multicast traffic is likely to carry a similar set of | |||
issues to the current unicast NAT-PT and may open up significant | issues to the current unicast NAT-PT and may open up significant | |||
additional security risks. | additional security risks. | |||
3. Issues exacerbated by the Use of DNS-ALG | 3. Issues exacerbated by the Use of DNS-ALG | |||
3.1 Network Topology Constraints Implied by NAT-PT | 3.1 Network Topology Constraints Implied by NAT-PT | |||
skipping to change at page 12, line 27 | skipping to change at page 12, line 40 | |||
DNS-ALG in the NAT-PT to provide the mapped address needed to | DNS-ALG in the NAT-PT to provide the mapped address needed to | |||
communicate with the flow destination on the other side of the | communicate with the flow destination on the other side of the | |||
NAT-PT. Whether used for flows initiated in the IPv4 domain or the | NAT-PT. Whether used for flows initiated in the IPv4 domain or the | |||
IPv6 domain, the NAT-PT has to be on the path taken by the DNS query | IPv6 domain, the NAT-PT has to be on the path taken by the DNS query | |||
sent by the flow initiator to the relevant DNS server; otherwise the | sent by the flow initiator to the relevant DNS server; otherwise the | |||
DNS query will not be modified and the response type would not be | DNS query will not be modified and the response type would not be | |||
appropriate. | appropriate. | |||
The implication is that the NAT-PT box also has to be the default | The implication is that the NAT-PT box also has to be the default | |||
IPv6 router for the site in order that the DNS-ALG is able to examine | IPv6 router for the site in order that the DNS-ALG is able to examine | |||
all DNS requests made over IPv6. On sites with both IPv6 and | all DNS requests made over IPv6. On sites with both IPv6 and dual- | |||
dual-stack nodes, this will result in all traffic flowing through the | stack nodes, this will result in all traffic flowing through the | |||
NAT-PT with consequent scalability concerns. | NAT-PT with consequent scalability concerns. | |||
These constraints are described in more detail in | These constraints are described in more detail in [I-D.durand-natpt- | |||
[I-D.durand-natpt-dns-alg-issues]. | dns-alg-issues]. | |||
[I-D.hallin-natpt-dns-alg-solutions] proposes a solution for flows | [I-D.hallin-natpt-dns-alg-solutions] proposes a solution for flows | |||
initiated from the IPv6 domain but it appears that this solution | initiated from the IPv6 domain but it appears that this solution | |||
still has issues. | still has issues. | |||
For IPv6-only clients the solution requires the use of a DNS server | For IPv6-only clients the solution requires the use of a DNS server | |||
in the IPv4 domain accessed via an IPv6 address which uses the NAT-PT | in the IPv4 domain accessed via an IPv6 address which uses the NAT-PT | |||
PREFIX (see [RFC2766]). Queries to this server would necessarily | PREFIX (see [RFC2766]). Queries to this server would necessarily | |||
pass through the NAT-PT. Dual-stack hosts would use a separate DNS | pass through the NAT-PT. Dual-stack hosts would use a separate DNS | |||
server accessed through a normal IPv6 address. This removes the need | server accessed through a normal IPv6 address. This removes the need | |||
skipping to change at page 14, line 8 | skipping to change at page 14, line 22 | |||
and the legitimate modification of packets in the NAT-PT make NAT-PTs | and the legitimate modification of packets in the NAT-PT make NAT-PTs | |||
enticing targets for security attacks. | enticing targets for security attacks. | |||
3.3 Issues with Lack of Address Persistence | 3.3 Issues with Lack of Address Persistence | |||
Using the DNS-ALG to create address bindings requires that the | Using the DNS-ALG to create address bindings requires that the | |||
application uses the translated address returned by the DNS query | application uses the translated address returned by the DNS query | |||
before the NAT-PT binding state is timed out (see Section 2.3). | before the NAT-PT binding state is timed out (see Section 2.3). | |||
Applications will not normally be aware of this constraint, which may | Applications will not normally be aware of this constraint, which may | |||
be different from the existing lifetime of DNS query responses. This | be different from the existing lifetime of DNS query responses. This | |||
could lead to difficult diagnosis problems with applications. | could lead to 'difficult to diagnose' problems with applications. | |||
Additionally, the DNS-ALG needs to determine the initial lifetime of | Additionally, the DNS-ALG needs to determine the initial lifetime of | |||
bindings which it creates. As noted in Section 2.3, this may need to | bindings which it creates. As noted in Section 2.3, this may need to | |||
be determined heuristically. The DNS-ALG does not know which | be determined heuristically. The DNS-ALG does not know which | |||
protocol the mapping is to be used for, and so needs another way to | protocol the mapping is to be used for, and so needs another way to | |||
determine the initial lifetime. This could be tied to the DNS | determine the initial lifetime. This could be tied to the DNS | |||
response lifetime but this might open up additional DOS attack | response lifetime but this might open up additional DOS attack | |||
possibilities if very long validities are allowed. Also the lifetime | possibilities if very long validities are allowed. Also the lifetime | |||
should be adjusted once the NAT-PT determines which protocol is being | should be adjusted once the NAT-PT determines which protocol is being | |||
used with the binding. | used with the binding. | |||
skipping to change at page 14, line 45 | skipping to change at page 15, line 10 | |||
3.4 DOS Attacks on Memory and Address/Port Pools | 3.4 DOS Attacks on Memory and Address/Port Pools | |||
As discussed in Section 2.3 a NAT-PT may create dynamic NAT bindings | As discussed in Section 2.3 a NAT-PT may create dynamic NAT bindings | |||
each of which consumes memory resources as well as an address (or | each of which consumes memory resources as well as an address (or | |||
port if NAPT-PT is used) from an address (or port) pool. A number of | port if NAPT-PT is used) from an address (or port) pool. A number of | |||
documents, including [RFC2766] and [I-D.okazaki-v6ops-natpt-security] | documents, including [RFC2766] and [I-D.okazaki-v6ops-natpt-security] | |||
discuss possible denial of service (DOS) attacks on NA(P)T-PT which | discuss possible denial of service (DOS) attacks on NA(P)T-PT which | |||
result in resource depletion associated with address and port pools. | result in resource depletion associated with address and port pools. | |||
NAT-PT does not specify any authentication mechanisms so that an | NAT-PT does not specify any authentication mechanisms so that an | |||
attacker may be able to create spurious binds by spoofing addresses | attacker may be able to create spurious bindings by spoofing | |||
in packets sent through NAT-PT. The attack is more damaging if the | addresses in packets sent through NAT-PT. The attack is more | |||
attacker is able to spoof protocols with long binding timeouts | damaging if the attacker is able to spoof protocols with long binding | |||
(typically used for TCP). | timeouts (typically used for TCP). | |||
The use of the DNS-ALG in NAT-PT introduces another vulnerability | The use of the DNS-ALG in NAT-PT introduces another vulnerability | |||
which can result in resource depletion. The attack identified in | which can result in resource depletion. The attack identified in | |||
[I-D.durand-natpt-dns-alg-issues] exploits the use of DNS queries | [I-D.durand-natpt-dns-alg-issues] exploits the use of DNS queries | |||
traversing NAT-PT to create dynamic bindings. Every time a DNS query | traversing NAT-PT to create dynamic bindings. Every time a DNS query | |||
is sent through the NAT-PT the NAT-PT may create a new NA(P)T-PT bind | is sent through the NAT-PT the NAT-PT may create a new NA(P)T-PT bind | |||
without any end-host authentication or authorization mechanisms. | without any end-host authentication or authorization mechanisms. | |||
This behavior could lead to a serious DOS attack on both memory and | This behavior could lead to a serious DOS attack on both memory and | |||
address or port pools. Address spoofing is not required for this | address or port pools. Address spoofing is not required for this | |||
attack to be successful. | attack to be successful. | |||
skipping to change at page 15, line 25 | skipping to change at page 15, line 38 | |||
The ideal mitigation solution would be to disallow dynamically | The ideal mitigation solution would be to disallow dynamically | |||
created binds until authentication and authorization of the end-host | created binds until authentication and authorization of the end-host | |||
needing the protocol translation has been carried out. This would | needing the protocol translation has been carried out. This would | |||
require that the proper security infrastructure be in place to | require that the proper security infrastructure be in place to | |||
support the authentication and authorization, which increases the | support the authentication and authorization, which increases the | |||
network operational complexity. | network operational complexity. | |||
4. Issues Directly Related to use of DNS-ALG | 4. Issues Directly Related to use of DNS-ALG | |||
4.1 Address Selection Issues when Communicating with Dual-Stack | 4.1 Address Selection Issues when Communicating with Dual-Stack End- | |||
End-hosts | hosts | |||
[I-D.durand-natpt-dns-alg-issues] discusses NAT-PT DNS-ALG issues | [I-D.durand-natpt-dns-alg-issues] discusses NAT-PT DNS-ALG issues | |||
with regard to address selection. As specified in [RFC2766], the | with regard to address selection. As specified in [RFC2766], the | |||
DNS-ALG returns AAAA RRs from two possible sources to the IPv6 host | DNS-ALG returns AAAA RRs from two possible sources to the IPv6 host | |||
which has made an AAAA DNS query AAAA. | which has made an AAAA DNS query. | |||
If the query relates to a dual-stack host, the query will return both | If the query relates to a dual-stack host, the query will return both | |||
the native IPv6 address(es) and the translated IPv4 address(es) in | the native IPv6 address(es) and the translated IPv4 address(es) in | |||
AAAA RRs. Without additional information, the IPv6 host address | AAAA RRs. Without additional information, the IPv6 host address | |||
selection may pick a translated IPv4 address instead of selecting the | selection may pick a translated IPv4 address instead of selecting the | |||
more appropriate native IPv6 address. Under some circumstances, the | more appropriate native IPv6 address. Under some circumstances, the | |||
address selection algorithms will always prefer the translated | address selection algorithms will always prefer the translated | |||
address over the native IPv6 address which is obviously undesirable. | address over the native IPv6 address which is obviously undesirable. | |||
[I-D.hallin-natpt-dns-alg-solutions] proposes a solution which | [I-D.hallin-natpt-dns-alg-solutions] proposes a solution which | |||
skipping to change at page 16, line 4 | skipping to change at page 16, line 16 | |||
[I-D.hallin-natpt-dns-alg-solutions] proposes a solution which | [I-D.hallin-natpt-dns-alg-solutions] proposes a solution which | |||
involves modification to the NAT-PT specification intended to return | involves modification to the NAT-PT specification intended to return | |||
only the most appropriate address(es) to an IPv6 capable host: | only the most appropriate address(es) to an IPv6 capable host: | |||
o When a DNS AAAA query traverses the NAT-PT DNS-ALG, the NAT-PT | o When a DNS AAAA query traverses the NAT-PT DNS-ALG, the NAT-PT | |||
will forward the query to the DNS server in the IPv4 domain | will forward the query to the DNS server in the IPv4 domain | |||
unchanged but using IPv4 transport: | unchanged but using IPv4 transport: | |||
* If the authoritative DNS server has one or more AAAA records, | * If the authoritative DNS server has one or more AAAA records, | |||
it returns them. The DNS-ALG then forwards this response to | it returns them. The DNS-ALG then forwards this response to | |||
the IPv6 host and does not send an A query as the standard | the IPv6 host and does not send an A query as the standard | |||
NAT-PT would do. | NAT-PT would do. | |||
* Otherwise, if the DNS server does not understand the AAAA query | * Otherwise, if the DNS server does not understand the AAAA query | |||
or has no AAAA entry for the host, it will return an error. | or has no AAAA entry for the host, it will return an error. | |||
The NAT-PT DNS-ALG will intercept the error or empty return and | The NAT-PT DNS-ALG will intercept the error or empty return and | |||
send an A query for the same host. If this query returns an | send an A query for the same host. If this query returns an | |||
IPv4 address, the ALG creates a binding and synthesizes a | IPv4 address, the ALG creates a binding and synthesizes a | |||
corresponding AAAA record which it sends back to the IPv6 host. | corresponding AAAA record which it sends back to the IPv6 host. | |||
o The NAT-PT thus forwards the result of the first successful DNS | o The NAT-PT thus forwards the result of the first successful DNS | |||
response back to the end-host or an error if neither succeeeds. | response back to the end-host or an error if neither succeeds. | |||
Consequently only AAAA RRs from one source will be provided | Consequently only AAAA RRs from one source will be provided | |||
instead of two as specified in [RFC2766] and it will contain the | instead of two as specified in [RFC2766] and it will contain the | |||
most appropriate address for a dual-stack or IPv6-only querier. | most appropriate address for a dual-stack or IPv6-only querier. | |||
There is, however, still an issue with the proposed solution: | There is, however, still an issue with the proposed solution: | |||
o The DNS client may timeout the query if it doesn't receive a | o The DNS client may timeout the query if it doesn't receive a | |||
response in time. This is more likely because the NAT-PT may have | response in time. This is more likely because the NAT-PT may have | |||
to make two separate queries sequentially which the client is not | to make two separate queries sequentially which the client is not | |||
aware of. It may be possible to reduce the response time by | aware of. It may be possible to reduce the response time by | |||
sending the two queries in parallel and ignoring the result of the | sending the two queries in parallel and ignoring the result of the | |||
skipping to change at page 17, line 50 | skipping to change at page 18, line 14 | |||
addresses. The same may be true for multihomed IPv4 nodes. | addresses. The same may be true for multihomed IPv4 nodes. | |||
Responses to DNS queries for these nodes will normally contain all | Responses to DNS queries for these nodes will normally contain all | |||
these addresses. Since the DNS-ALG in the NAT-PT has no knowledge | these addresses. Since the DNS-ALG in the NAT-PT has no knowledge | |||
which of the addresses can or will be used by the application issuing | which of the addresses can or will be used by the application issuing | |||
the query, it is obliged to translate all of them. | the query, it is obliged to translate all of them. | |||
This could be a significant drain on resources in both NAT-PT and | This could be a significant drain on resources in both NAT-PT and | |||
NAPT-PT, as bindings will have to be created for each address. | NAPT-PT, as bindings will have to be created for each address. | |||
When using SCTP in a multihomed network, the problem is exacerbated | When using SCTP in a multihomed network, the problem is exacerbated | |||
if multiple NAT-PTs translate mutiple addresses: also it is not | if multiple NAT-PTs translate multiple addresses: also it is not | |||
clear that SCTP will actually look up all the destination IP | clear that SCTP will actually look up all the destination IP | |||
addresses via DNS so that bindings may not be in place when packets | addresses via DNS so that bindings may not be in place when packets | |||
arrive. | arrive. | |||
4.5 Limitations on Deployment of DNS Security Capabilities | 4.5 Limitations on Deployment of DNS Security Capabilities | |||
Secure DNS (DNSSEC) [I-D.ietf-dnsext-dnssec-intro] uses public key | Secure DNS (DNSSEC) [I-D.ietf-dnsext-dnssec-intro] uses public key | |||
cryptographic signing to authenticate DNS responses. The DNS-ALG | cryptographic signing to authenticate DNS responses. The DNS-ALG | |||
modifies DNS query responses traversing the NAT-PT in both directions | modifies DNS query responses traversing the NAT-PT in both directions | |||
which would invalidate the signatures as (partially) described in | which would invalidate the signatures as (partially) described in | |||
skipping to change at page 19, line 22 | skipping to change at page 19, line 35 | |||
behavior of the application in native IPv6 and NAT-PT environments | behavior of the application in native IPv6 and NAT-PT environments | |||
would be likely to be significantly different. | would be likely to be significantly different. | |||
6. Security Considerations | 6. Security Considerations | |||
This document summarizes security issues related to the NAT-PT | This document summarizes security issues related to the NAT-PT | |||
[RFC2766] specification. Security issues are discussed in various | [RFC2766] specification. Security issues are discussed in various | |||
sections: | sections: | |||
o Section 2.1 discusses how IPsec AH (transport and tunnel mode) and | o Section 2.1 discusses how IPsec AH (transport and tunnel mode) and | |||
IPsec ESP transport mode are broken by NAT-PT (when IPSEC UDP | IPsec ESP transport mode are broken by NAT-PT (when IPSEC UDP | |||
encapsulation is not used [RFC3948]); and authentication and | encapsulation is not used [RFC3498]); and authentication and | |||
encryption are generally incompatible with NAT-PT. | encryption are generally incompatible with NAT-PT. | |||
o Section 2.5 discusses possible fragmentation related security | o Section 2.5 discusses possible fragmentation related security | |||
attacks on NAT-PT. | attacks on NAT-PT. | |||
o Section 2.8 discusses security issues related to multicast | o Section 2.8 discusses security issues related to multicast | |||
addresses and NAT-PT. | addresses and NAT-PT. | |||
o Section 3.3 highlights that NAT-PT is an enticing nexus for | o Section 3.3 highlights that NAT-PT is an enticing nexus for | |||
security attacks. | security attacks. | |||
o Section 3.4 discusses possible NAT-PT DOS attacks on both memory | o Section 3.4 discusses possible NAT-PT DOS attacks on both memory | |||
and address/port pools. | and address/port pools. | |||
o Section 4.5 discusses why NAT-PT is incompatible with DNSSEC | o Section 4.5 discusses why NAT-PT is incompatible with DNSSEC | |||
skipping to change at page 19, line 44 | skipping to change at page 20, line 9 | |||
DNSSEC. | DNSSEC. | |||
7. IANA Considerations | 7. IANA Considerations | |||
There are no IANA considerations defined in this document. | There are no IANA considerations defined in this document. | |||
8. Conclusion | 8. Conclusion | |||
This document has discussed a number of significant issues with | This document has discussed a number of significant issues with | |||
NAT-PT as defined in [RFC2766]. From a deployment perspective 3GPP | NAT-PT as defined in [RFC2766]. From a deployment perspective 3GPP | |||
networks are currently the only 'standardised' scenario where an IPv6 | networks are currently the only 'standardized' scenario where an IPv6 | |||
only host communicates with an IPv4 only host using NAT-PT as | only host communicates with an IPv4 only host using NAT-PT as | |||
described in the 3GPP IPv6 transition analysis | described in the 3GPP IPv6 transition analysis [I-D.ietf-v6ops-3gpp- | |||
[I-D.ietf-v6ops-3gpp-analysis] but NAT-PT has seen some limited usage | analysis] but NAT-PT has seen some limited usage for other purposes. | |||
for other purposes. | ||||
Although some of issues identified with NAT-PT appear to have | Although some of issues identified with NAT-PT appear to have | |||
solutions, many of the solutions required significant alterations to | solutions, many of the solutions required significant alterations to | |||
the existing specification and would be likely to increase | the existing specification and would be likely to increase | |||
operational complexity. Even if these solutions were applied, we | operational complexity. Even if these solutions were applied, we | |||
have shown that NAT-PT still has significant irresolvable issues and | have shown that NAT-PT still has significant irresolvable issues and | |||
appears to have limited applicability. The potential constraints on | appears to have limited applicability. The potential constraints on | |||
the development of IPv6 applications described in Section 5 are | the development of IPv6 applications described in Section 5 are | |||
particularly un desirable. It appears that alternatives to NAT-PT | particularly un desirable. It appears that alternatives to NAT-PT | |||
exist to cover the circumstances where NAT-PT has been suggested as a | exist to cover the circumstances where NAT-PT has been suggested as a | |||
skipping to change at page 20, line 22 | skipping to change at page 20, line 34 | |||
scenarios. | scenarios. | |||
However it is clear that in some circumstances a IPv6/IPv4 protocol | However it is clear that in some circumstances a IPv6/IPv4 protocol | |||
translation solution may be a useful transitional solution, | translation solution may be a useful transitional solution, | |||
particularly in more constrained situations where the translator is | particularly in more constrained situations where the translator is | |||
not required to deal with traffic for a wide variety of protocols | not required to deal with traffic for a wide variety of protocols | |||
which are not determined in advance. It is therefore possible that a | which are not determined in advance. It is therefore possible that a | |||
more limited form of NAT-PT could be defined for use in specific | more limited form of NAT-PT could be defined for use in specific | |||
situations. | situations. | |||
Accordingly the IETF no longer recommends its usage as a general | Accordingly we recommend that the IETF no longer suggest its usage as | |||
purpose IPv4/IPv6 transition mechanisms but NAT-PT will be retained | a general IPv4/IPv6 transition mechanism in the Internet but retain | |||
as an experimental mechanisms while further experience is gained and | it as an experimental mechanism while further experience is gained | |||
any future replacement is defined and deployed. Consequently, we | and any future replacement is defined and deployed. Consequently we | |||
request that RFC2766 is reclassified from Standards Track to | recommend moving RFC2766 to experimental status. | |||
Experimental status. | ||||
9. Acknowledgments | 9. Acknowledgments | |||
This work builds on a large body of existing work examining the | This work builds on a large body of existing work examining the | |||
issues and applicability of NAT-PT: the work of the authors of the | issues and applicability of NAT-PT: the work of the authors of the | |||
documents referred in Section 1 has been extremely useful in creating | documents referred in Section 1 has been extremely useful in creating | |||
this document. Particular thanks are due to Pekka Savola for rapid | this document. Particular thanks are due to Pekka Savola for rapid | |||
and thorough review of the document. | and thorough review of the document. | |||
10. References | 10. References | |||
skipping to change at page 21, line 8 | skipping to change at page 21, line 22 | |||
February 2000. | February 2000. | |||
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", | [RFC2535] Eastlake, D., "Domain Name System Security Extensions", | |||
RFC 2535, March 1999. | RFC 2535, March 1999. | |||
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address | [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address | |||
Translator (NAT) Terminology and Considerations", | Translator (NAT) Terminology and Considerations", | |||
RFC 2663, August 1999. | RFC 2663, August 1999. | |||
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications | [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications | |||
with the IP Network Address Translator", RFC 3027, January | with the IP Network Address Translator", RFC 3027, | |||
2001. | January 2001. | |||
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., | [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., | |||
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, | Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, | |||
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., | K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., | |||
Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header | Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header | |||
Compression (ROHC): Framework and four profiles: RTP, UDP, | Compression (ROHC): Framework and four profiles: RTP, UDP, | |||
ESP, and uncompressed", RFC 3095, July 2001. | ESP, and uncompressed", RFC 3095, July 2001. | |||
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third | [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third | |||
Generation Partnership Project (3GPP) Standards", | Generation Partnership Project (3GPP) Standards", | |||
RFC 3314, September 2002. | RFC 3314, September 2002. | |||
[RFC3484] Draves, R., "Default Address Selection for Internet | [RFC3484] Draves, R., "Default Address Selection for Internet | |||
Protocol version 6 (IPv6)", RFC 3484, February 2003. | Protocol version 6 (IPv6)", RFC 3484, February 2003. | |||
skipping to change at page 21, line 42 | skipping to change at page 22, line 7 | |||
Loughney, J., "IPv6 Node Requirements", | Loughney, J., "IPv6 Node Requirements", | |||
draft-ietf-ipv6-node-requirements-11 (work in progress), | draft-ietf-ipv6-node-requirements-11 (work in progress), | |||
August 2004. | August 2004. | |||
[I-D.ietf-v6ops-3gpp-analysis] | [I-D.ietf-v6ops-3gpp-analysis] | |||
Wiljakka, J., "Analysis on IPv6 Transition in 3GPP | Wiljakka, J., "Analysis on IPv6 Transition in 3GPP | |||
Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in | Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in | |||
progress), October 2004. | progress), October 2004. | |||
[I-D.ietf-dnsext-dnssec-intro] | [I-D.ietf-dnsext-dnssec-intro] | |||
Arends, R., Austein, R., Massey, D., Larson, M. and S. | Arends, R., Austein, R., Massey, D., Larson, M., and S. | |||
Rose, "DNS Security Introduction and Requirements", | Rose, "DNS Security Introduction and Requirements", | |||
draft-ietf-dnsext-dnssec-intro-13 (work in progress), | draft-ietf-dnsext-dnssec-intro-13 (work in progress), | |||
October 2004. | October 2004. | |||
10.2 Informative References | 10.2 Informative References | |||
[RFC1858] Ziemba, G., Reed, D. and P. Traina, "Security | [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security | |||
Considerations for IP Fragment Filtering", RFC 1858, | Considerations for IP Fragment Filtering", RFC 1858, | |||
October 1995. | October 1995. | |||
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny | [RFC3128] Miller, I., "Protection Against a Variant of the Tiny | |||
Fragment Attack (RFC 1858)", RFC 3128, June 2001. | Fragment Attack (RFC 1858)", RFC 3128, June 2001. | |||
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., | [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., | |||
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., | Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., | |||
Zhang, L. and V. Paxson, "Stream Control Transmission | Zhang, L., and V. Paxson, "Stream Control Transmission | |||
Protocol", RFC 2960, October 2000. | Protocol", RFC 2960, October 2000. | |||
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. | [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of | |||
Stenberg, "UDP Encapsulation of IPsec ESP Packets", | Managed Objects for Synchronous Optical Network (SONET) | |||
RFC 3948, January 2005. | Linear Automatic Protection Switching (APS) | |||
Architectures", RFC 3498, March 2003. | ||||
[I-D.satapati-v6ops-natpt-applicability] | [I-D.satapati-v6ops-natpt-applicability] | |||
Satapati, S., "NAT-PT Applicability", | Satapati, S., "NAT-PT Applicability", | |||
draft-satapati-v6ops-natpt-applicability-00 (work in | draft-satapati-v6ops-natpt-applicability-00 (work in | |||
progress), October 2003. | progress), October 2003. | |||
[I-D.durand-natpt-dns-alg-issues] | [I-D.durand-natpt-dns-alg-issues] | |||
Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", | Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", | |||
draft-durand-natpt-dns-alg-issues-00 (work in progress), | draft-durand-natpt-dns-alg-issues-00 (work in progress), | |||
February 2002. | February 2002. | |||
skipping to change at page 22, line 48 | skipping to change at page 23, line 14 | |||
Shin, M. and J. Lee, "Considerations for Mobility Support | Shin, M. and J. Lee, "Considerations for Mobility Support | |||
in NAT-PT", draft-lee-v6ops-natpt-mobility-00 (work in | in NAT-PT", draft-lee-v6ops-natpt-mobility-00 (work in | |||
progress), June 2003. | progress), June 2003. | |||
[I-D.okazaki-v6ops-natpt-security] | [I-D.okazaki-v6ops-natpt-security] | |||
Okazaki, S. and A. Desai, "NAT-PT Security | Okazaki, S. and A. Desai, "NAT-PT Security | |||
Considerations", draft-okazaki-v6ops-natpt-security-00 | Considerations", draft-okazaki-v6ops-natpt-security-00 | |||
(work in progress), June 2003. | (work in progress), June 2003. | |||
[I-D.vanderpol-v6ops-translation-issues] | [I-D.vanderpol-v6ops-translation-issues] | |||
Pol, R., Satapati, S. and S. Sivakumar, "Issues when | Pol, R., Satapati, S., and S. Sivakumar, "Issues when | |||
translating between IPv4 and IPv6", | translating between IPv4 and IPv6", | |||
draft-vanderpol-v6ops-translation-issues-00 (work in | draft-vanderpol-v6ops-translation-issues-00 (work in | |||
progress), January 2003. | progress), January 2003. | |||
[I-D.elmalki-sipping-3gpp-translator] | [I-D.elmalki-sipping-3gpp-translator] | |||
Malki, K., "IPv6-IPv4 Translation mechanism for SIP-based | Malki, K., "IPv6-IPv4 Translation mechanism for SIP-based | |||
services in Third Generation Partnership Project (3GPP) | services in Third Generation Partnership Project (3GPP) | |||
Networks", draft-elmalki-sipping-3gpp-translator-00 (work | Networks", draft-elmalki-sipping-3gpp-translator-00 (work | |||
in progress), December 2003. | in progress), December 2003. | |||
[I-D.tsuchiya-mtp] | [I-D.tsuchiya-mtp] | |||
Tsuchiya, K., Higuchi, H., Sawada, S. and S. Nozaki, "An | Tsuchiya, K., Higuchi, H., Sawada, S., and S. Nozaki, "An | |||
IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying | IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying | |||
(mtp)", draft-tsuchiya-mtp-01 (work in progress), February | (mtp)", draft-tsuchiya-mtp-01 (work in progress), | |||
2003. | February 2003. | |||
[I-D.venaas-mboned-v4v6mcastgw] | [I-D.venaas-mboned-v4v6mcastgw] | |||
Venaas, S., "An IPv4 - IPv6 multicast gateway", | Venaas, S., "An IPv4 - IPv6 multicast gateway", | |||
draft-venaas-mboned-v4v6mcastgw-00 (work in progress), | draft-venaas-mboned-v4v6mcastgw-00 (work in progress), | |||
February 2003. | February 2003. | |||
[I-D.park-scalable-multi-natpt] | [I-D.park-scalable-multi-natpt] | |||
Park, S., "Scalable mNAT-PT Solution", | Park, S., "Scalable mNAT-PT Solution", | |||
draft-park-scalable-multi-natpt-00 (work in progress), May | draft-park-scalable-multi-natpt-00 (work in progress), | |||
2003. | May 2003. | |||
Authors' Addresses | Authors' Addresses | |||
Cedric Aoun | Cedric Aoun | |||
Nortel Networks/ENST Paris | ENST | |||
Paris | ||||
France | France | |||
Email: cedric.aoun@nortel.com | Email: cedric@caoun.net | |||
Elwyn B. Davies | Elwyn B. Davies | |||
Consultant | Consultant | |||
Soham, Cambs | Soham, Cambs | |||
UK | UK | |||
Phone: +44 7889 488 335 | Phone: +44 7889 488 335 | |||
Email: elwynd@dial.pipex.com | Email: elwynd@dial.pipex.com | |||
Intellectual Property Statement | Intellectual Property Statement | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |