Behavior Engineering for Hindrance R. Penno
Avoidance T. Saxena
Internet-Draft Juniper Networks
Intended status: Informational D. Wing
Expires: June 18, 2010 Cisco Systems
December 15, 2009
Analysis of 64 Translation
draft-penno-behave-64-analysis-00
Abstract
Due to specific problems, NAT-PT was deprecated by the IETF as a
mechanism to perform IPv6/IPv4 translation. Since then, new work has
commenced which standardizes new mechanisms to perform IPv6/IPv4
translation. This document evaluates how the new translation
mechanisms avoid the problems that caused the IETF to deprecate
NAT-PT.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 18, 2010.
Penno, et al. Expires June 18, 2010 [Page 1]
Internet-Draft analysis-64-translation December 2009
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Analysis of RFC 4966 . . . . . . . . . . . . . . . . . . . . . 4
2.1. Problems Not Addressed by 64 . . . . . . . . . . . . . . . 4
2.2. Problems Addressed by 64 . . . . . . . . . . . . . . . . . 5
2.3. Problems Addressed by other BEHAVE documents . . . . . . . 6
3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Penno, et al. Expires June 18, 2010 [Page 2]
Internet-Draft analysis-64-translation December 2009
1. Introduction
The 64 proposal is widely seen as the next step in the evolution of
interconnection equipment enabling communication between IPv6 and
IPv4 only networks. One fo the building blocks of this proposal is
decoupling the DNS functionality from protocol NAT.
This approach is pragmatic in the sense that there is no dependency
on DNS implementation for the successful functionality of NAT. As
long as there is a function (possibly DNS64) that can construct an
IPv6 address with a fixed prefix and IPv4 address as the suffix,
NAT64 will work just fine.
To understand the proposal, we must keep in mind that the focus of
this proposal is on the deployment and not the implementation
details. As long as a NAT64 box confirms to the externally
behaviour, as desired in the deployment scenario, the details are not
very important. "..... A NAT64 MAY perform the steps in a different
order, or MAY perform different steps, as long as the externally
visible outcome in the same."
1.1. Scope
This document provides an analysis of how the proposed set of
documents that standardize stateful IPv6 to IPv4 translation and
replace NAT-PT [RFC2766] address the issues raised in the document
"Reasons to Move the Network Address Translator - Protocol Translator
(NAT-PT) to Historic Status" [RFC4966]. These documents, henceforth
referred as 64, comprise of the following:
o NAT64: Network Address and Protocol Translation from IPv6 Clients
to IPv4 Servers [I-D.ietf-behave-v6v4-xlate-stateful]
o DNS64: DNS extensions for Network Address Translation from IPv6
Clients to IPv4 Servers [I-D.ietf-behave-dns64]
o IPv6 Addressing of IPv4/IPv6 TranslatorsFramework for IPv4/IPv6
Translation [I-D.ietf-behave-address-format]
o Framework for IPv4/IPv6 Translation
[I-D.ietf-behave-v6v4-framework]
This draft is limited in the sense that hosts from IPv6 network can
initiate a connection to IPv4 network, but not vice-versa. This
corresponds to scenarios 1 and 5 of the document Framework for
[I-D.ietf-behave-v6v4-framework]. Hence, the scenario of servers
moving to IPv6 while clients remaining IPv4 remains unaddressed.
Penno, et al. Expires June 18, 2010 [Page 3]
Internet-Draft analysis-64-translation December 2009
The 64 proposal, just like any other technology under development,
has some positives and some drawbacks. The ups and downs of the
proposal must be clearly understood while going forward with its
future development.
2. Analysis of RFC 4966
Of the set of problems pointed out in RFC4966, the 64 proposal
addresses some problems, whereas leaves others unaddressed.
Following is a point by point analysis of the problems.
2.1. Problems Not Addressed by 64
Problems discussed in RFC4966, which are not addressed by the 64
proposal:
1. Disruption of all protocols that embed IP addresses (and/or
ports) in packet payloads or apply integrity mechanisms using IP
addresses (and ports).
Discussion: In the case of FTP [RFC0959] this problem is
addressed by the use of a FTP64 ALG
[I-D.van-beijnum-behave-ftp64] which is a workaround solution.
The functioning of other protocols is left unaddressed.
2. Inability to redirect traffic for protocols that lack
demultiplexing capabilities or are not built on top of specific
transport-layer protocols for transport address translations.
3. Loss of information due to incompatible semantics between IPv4
and IPv6 versions of headers and protocols.
4. Need for additional state and/or packet reconstruction in
dealing with packet fragmentation. Otherwise, implement no
support for fragments.
5. Interaction with SCTP and multihoming.
6. Need for the NAT box to act as proxy for correspondent node when
IPv6 node is mobile, with consequent restrictions on mobility.
7. Inability to handle multicast traffic.
Penno, et al. Expires June 18, 2010 [Page 4]
Internet-Draft analysis-64-translation December 2009
Discussion: efforts are underway to support translation of
multicast traffic [I-D.venaas-behave-v4v6mc-framework].
8. Scalability concerns together with introduction of a single
point of failure and a security attack nexus.
Discussion: There is still a single point of failure for the NAT
connections.
9. Creation of a DoS (Denial of Service) threat relating to
exhaustion of memory and address/port pool resources on the
translator.
Discussion: This can be considered as partially mitigated as DNS
queries do not result in state creation over NAT. However a DoS
can still be mounted by address/port pool resource exhaustion.
10. Restricted validity of translated DNS records: a translated
record may be forwarded to an application that cannot use it.
Discussion: If a node on the v4 side forwards the address of the
other endpoint to a node which cannot contact the NAT box or is
not covered under the endpoint-dependent contraints of NAT, then
the new node will not be able to initiate contact.
11. IPSec
Discussion: RFC4966 states that " Unless UDP encapsulation is
used for IPsec [RFC3498], traffic using IPsec AH (Authentication
Header), in transport and tunnel mode, and IPsec ESP
(Encapsulating Security Payload), in transport mode, is unable
to be carried through NAT-PT without terminating the security
associations on the NAT-PT, due to their usage of cryptographic
integrity protection.". This is still true for 64.
2.2. Problems Addressed by 64
The problems that the 64 proposal adequately addresses:
Penno, et al. Expires June 18, 2010 [Page 5]
Internet-Draft analysis-64-translation December 2009
1. Constraints on network topology.
Discussion: This issue has mitigated severity as the DNS is
separate from the NAT box
2. Address selection issues when either the internal or external
hosts implement both IPv4 and IPv6.
Discussion: This is totally under the control of DNS. So the NAT
is free of any of these considerations.
3. Inappropriate translation of responses to A queries from IPv6
nodes.
Discussion: Since DNS is not a NAT responsibility anymore, this
is no more a cause of concern.
4. Address selection issues and resource consumption in a DNS-ALG
with multi-addressed nodes
Discussion: Since the DNS-ALG is not there and new connection
initiation is not supported from IPv4 side, their is no need to
maintain temporary states in anticipation of connections.
5. Limitations on DNS security capabilities when using a DNS-ALG.
Discussion: DNSSEC is now supported, so this issue is resolved.
6.
2.3. Problems Addressed by other BEHAVE documents
Some issues mentioned in RFC4966 were solved by RFC 4787 [RFC4787],
RFC 5382 [RFC5382] and RFC 5508 [RFC5508]. At the time when NAT-PT
was published these recommendations were not in place but they are
ortoghonal to the translation algorithm per se, therefore they could
be implemented with NAT-PT. On the other hand, NAT64 explicitly
mentions that these recommendations need to be followed and thus
Penno, et al. Expires June 18, 2010 [Page 6]
Internet-Draft analysis-64-translation December 2009
should be seen as a complete specification.
1. Requirement for applications to use keepalive mechanisms to
workaround connectivity issues caused by premature timeout for
session table and BIB entries.
Discussion: Since NAT64 follows RFC4787, RFC5382 and RFC5508
requirements, there is lower bound (which is pretty is high) for
the lifetime of the sessions. In NAT-PT this was unknown and
applications needed to assume the worst case. For instance, in
NAT64, the lifetime for a TCP session is 2 hours, so not much
keep-alive signalling overhead is needed.
2. Lack of address mapping persistence: Some applications require
address retention between sessions. The user traffic will be
disrupted if a different mapping is used. The use of the DNS-
ALG to create address mappings with limited lifetimes means that
applications must start using the address shortly after the
mapping is created, as well as keep it alive once they start
using it.
Discussion: Since RFC4787 recommends the use of endpoint
independent mapping and NAT64 follows such recomendation
depending on how many other sessions are for the same endpoint,
it may be the case that in many cases this is solved. Having
said that, the same network and port allcoation scheme could be
used in NAT-PT which would make it a non-issue.
3. Conclusions
The above analysis of the solutions provided by the 64 proposal shows
that the majority of the problems that are not directly related to
the decoupling of NAT and DNS remain unaddressed.
This points to several shortcomings of 64 proposal which must be
addressed if the future network deployments have to move reliably
towards 64 as a solution to IPv6 - IPv4 connectivity.
Some of the issues, as pointed out in RFC 4966, have possible
solutions. However these solutions will require significant updates
to the 64 proposal, increasing its complexity.
Penno, et al. Expires June 18, 2010 [Page 7]
Internet-Draft analysis-64-translation December 2009
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
None
6. Acknowledgements
Marcelo Bagnulo for his comments.
7. References
7.1. Normative References
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508,
April 2009.
Penno, et al. Expires June 18, 2010 [Page 8]
Internet-Draft analysis-64-translation December 2009
7.2. Informative References
[I-D.ietf-behave-address-format]
Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-02 (work in progress),
December 2009.
[I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-02 (work in progress),
October 2009.
[I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation",
draft-ietf-behave-v6v4-framework-03 (work in progress),
October 2009.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4
Servers", draft-ietf-behave-v6v4-xlate-stateful-04 (work
in progress), December 2009.
[I-D.van-beijnum-behave-ftp64]
Beijnum, I., "IPv6-to-IPv4 translation FTP
considerations", draft-van-beijnum-behave-ftp64-06 (work
in progress), October 2009.
[I-D.venaas-behave-v4v6mc-framework]
Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6
Multicast Translation",
draft-venaas-behave-v4v6mc-framework-01 (work in
progress), October 2009.
Penno, et al. Expires June 18, 2010 [Page 9]
Internet-Draft analysis-64-translation December 2009
Authors' Addresses
Reinaldo Penno
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, California 94089
USA
Email: rpenno@juniper.net
Tarun Saxena
Juniper Networks
Email: tsaxena@juniper.net
Dan Wing
Cisco Systems
170 West Tasman Drive
San Jose, California 95134
USA
Email: dwing@cisco.com
Penno, et al. Expires June 18, 2010 [Page 10]