Behavior Engineering for Hindrance Avoidance R. Penno
Internet-Draft Juniper Networks
Intended status: Informational T. Saxena
Expires: August 22, 2012 Cisco Systems
M. Boucadair
France Telecom
S. Sivakumar
Cisco Systems
February 21, 2012

Analysis of Stateful 64 Translation
draft-ietf-behave-64-analysis-06

Abstract

Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document evaluates how the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on August 22, 2012.

Copyright Notice

Copyright (c) 2012 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 Simplified BSD License.


Table of Contents

1. Introduction

1.1. Definition

This document uses stateful 64 (or 64 for short) to refer to the mechanisms defined in the following documents:

1.2. Context

Stateful 64 is widely seen as a major interconnection technique designed to enable communications between IPv6-only and IPv4-only networks. One of the building blocks of the stateful 64 is decoupling the DNS functionality from the protocol translation itself.

This approach is pragmatic in the sense that there is no dependency on DNS implementation for the successful NAT handling. As long as there is a function (e.g., DNS64 [RFC6147] or other means) that can construct an IPv6-embedded IPv4 address with a pre-configured IPv6 prefix, an IPv4 address and a suffix (refer to [RFC6052]), NAT64 will work just fine.

The focus of the stateful 64 is on the deployment and not the implementation details. As long as a NAT64 implementation conforms to the expected behavior, as desired in the deployment scenario, the details are not very important as mentioned in this excerpt from [RFC6146]:

1.3. Scope

This document provides an analysis of how the proposed set of documents that specify stateful IPv6-only to IPv4-only translation and replace NAT-PT [RFC2766] address the issues raised in [RFC4966].

As a reminder, it is worth mentioning the analysis is limited in the sense that hosts from IPv6 networks can initiate a communication to IPv4 network/Internet, but not vice-versa. This corresponds to Scenario 1 and Scenario 5 described in [RFC6144]. Hence, the scenario of servers moving to IPv6 while clients remaining IPv4 remains unaddressed. Of course, IPv6 to IPv4 communications can also be supported if static or explicit bindings (e.g., [I-D.ietf-pcp-base]) are configured on the stateful NAT64.

Stateful 64, just like any other technique 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.

The scope of this document does not include stateless translation.

2. 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].

3. Analysis of 64 Translation Against Concerns of RFC4966

Of the set of problems pointed out in [RFC4966], the stateful 64 addresses some of them, whereas leaves others unaddressed.

Some issues mentioned in [RFC4966] were solved by [RFC4787], [RFC5382] and [RFC5508]. At the time when NAT-PT was published these recommendations were not in place but they are orthogonal to the translation algorithm per se, therefore they could be implemented with NAT-PT. On the other hand, NAT64 [RFC6146] explicitly mentions that these recommendations need to be followed and thus should be seen as a complete specification.

It is also worth pointing out that the scope of the stateful 64 is reduced when compared to NAT-PT. Following is a point by point analysis of the problems. Issues listed in [RFC4966] are classified into three categories:

  1. Problems impossible to solve;
  2. Problems which can be solved.
  3. Problems solved.

3.1. Problems Impossible to Solve

Problems discussed in [RFC4966], which are impossible to solve:

  1. Inability to redirect traffic for protocols that lack de-multiplexing capabilities or are not built on top of specific transport-layer protocols for transport address translations (Section 2.2 of [RFC4966]).
  2. Loss of information due to incompatible semantics between IPv4 and IPv6 versions of headers and protocols (Section 2.4 of [RFC4966]).
  3. Need for the NAT64-capable device to act as proxy for correspondent node when IPv6 node is mobile, with consequent restrictions on mobility (Section 2.7 of [RFC4966]).

3.2. Problems Which Can be Solved

Problems discussed in [RFC4966], which can be solved:

  1. Disruption of all protocols that embed IP addresses (and/or ports) in packet payloads or apply integrity mechanisms using IP addresses (and ports) (Section 2.1 of [RFC4966]).
  2. Interaction with SCTP [RFC4960] and multihoming (Section 2.6 of [RFC4966]).
  3. Inability to handle multicast traffic (Section 2.8 of [RFC4966]).
  4. Scalability concerns together with introduction of a single point of failure and a security attack nexus (Section 3.2 of [RFC4966]).
  5. Restricted validity of translated DNS records: a translated record may be forwarded to an application that cannot use it (Section 4.2 of [RFC4966]).
  6. Unless UDP encapsulation is used for IPsec [RFC3948], 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 (Section 4.5 of [RFC4966]).
  7. Address selection issues when either the internal or external hosts implement both IPv4 and IPv6 (Section 4.1 of [RFC4966]).

3.3. Problems Solved

Problems, identified in [RFC4966], which are solved:

  1. Constraints on network topology (as it relates to DNS-ALG; see Section 3.1 of [RFC4966]).
  2. Need for additional state and/or packet reconstruction in dealing with packet fragmentation. Otherwise, implement no support for fragments. (Section 2.5 of [RFC4966])
  3. Inappropriate translation of responses to A queries from IPv6 nodes (Section 4.3 of [RFC4966]).
  4. Address selection issues and resource consumption in a DNS-ALG with multi-addressed nodes (Section 4.4 of [RFC4966]).
  5. Limitations on DNS security capabilities when using a DNS-ALG (Section 2.5 of [RFC4966]).
  6. Creation of a Denial of Service (DoS) threat relating to exhaustion of memory and address/port pool resources on the translator (Section 3.4 of [RFC4966]).
  7. Requirement for applications to use keepalive mechanisms to workaround connectivity issues caused by premature timeout for session table and BIB entries (Section 2.3 of [RFC4966]).
  8. 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. (Section 3.3 of [RFC4966])

4. Conclusions

The above analysis of the solutions provided by the stateful 64 shows that the majority of the problems that are not directly related to the decoupling of NAT and DNS remain unaddressed. Some of these problems are not specific to 64 but are generic to all NAT-based solutions.

This points to several shortcomings of stateful 64 which must be addressed if the future network deployments have to move reliably towards 64 as a solution to IPv6-IPv4 interconnection.

Some of the issues, as pointed out in [RFC4966], have possible solutions. However these solutions will require significant updates to the stateful 64, increasing its complexity.

The following table summarizes the conclusions based on the analysis of stateful 64.

Summary of NAT64 analysis
Issue NAT-PT Specific Exists in NAT64 DNS ALG Specific Generic NAT Can be solved?
Protocols embedding addresses No Yes No Yes Yes
Protocols without demux capability No Yes No Yes No
Binding state decay No Yes No Yes Yes
Loss of information No Yes No No No
Fragmentation No No No Yes Yes
SCTP and Multihoming interaction No Yes No Yes Yes
Proxy correspondent node for MIPv6 No Yes No No No
Multicast No Yes No Yes Yes
Topology constraints with DNS-ALG Yes No Yes No Yes
Scale and Single point of failure No Yes No Yes Yes
Lack of address persistence No Yes No Yes Yes
DoS attacks No Yes No Yes Yes
Address selection issues with Dual stack hosts Yes No Yes No Yes
Non-global validity of Translated RR records Yes No Yes No Yes
Incorrect translation of A responses Yes No Yes No Yes
DNS-ALG and Multi- addressed nodes No Yes No Yes Yes
DNSSEC limitations No Yes No Yes Yes

5. IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

6. Security Considerations

This document does not specify any new protocol or architecture. It only analyzes how BEHAVE WG 64 documents mitigate concerns raised in [RFC4966] and which ones are still unaddressed.

7. Acknowledgements

Many thanks to M. Bagnulo, D. Wing, X. Li, D. Anipko and S. Moonesamy for their review and comments.

8. References

8.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.
[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.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M. and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6145] Li, X., Bao, C. and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6146] Bagnulo, M., Matthews, P. and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P. and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC6144] Baker, F., Li, X., Bao, C. and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.

8.2. Informative References

[I-D.ietf-pcp-base] Wing, D, Cheshire, S, Boucadair, M, Penno, R and P Selkirk, "Port Control Protocol (PCP)", Internet-Draft draft-ietf-pcp-base-13, July 2011.
[RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[I-D.wing-behave-dns64-config] Wing, D, "IPv6-only and Dual Stack Hosts on the Same Network with DNS64", Internet-Draft draft-wing-behave-dns64-config-03, February 2011.
[I-D.ietf-ftpext2-ftp64] Liu, D, Beijnum, I and Z Cao, "FTP extension for IPv4/IPv6 transition", Internet-Draft draft-ietf-ftpext2-ftp64-01, July 2011.
[I-D.ietf-6man-addr-select-opt] Matsumoto, A, Fujisaki, T, Kato, J and T Chown, "Distributing Address Selection Policy using DHCPv6", Internet-Draft draft-ietf-6man-addr-select-opt-01, June 2011.
[I-D.ietf-behave-lsn-requirements] Perreault, S, Yamagata, I, Miyakawa, S, Nakagawa, A and H Ashida, "Common requirements for Carrier Grade NAT (CGN)", Internet-Draft draft-ietf-behave-lsn-requirements-03, August 2011.
[RFC6157] Camarillo, G., El Malki, K. and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A. and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[I-D.haddad-mext-nat64-mobility-harmful] Haddad, W and C Perkins, "A Note on NAT64 Interaction with Mobile IPv6", Internet-Draft draft-haddad-mext-nat64-mobility-harmful-02, March 2011.
[I-D.ietf-mmusic-media-path-middleboxes] Stucker, B and H Tschofenig, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Internet-Draft draft-ietf-mmusic-media-path-middleboxes-03, July 2010.
[I-D.carpenter-behave-referral-object] Carpenter, B, Boucadair, M, Halpern, J, Jiang, S and K Moore, "A Generic Referral Object for Internet Entities", Internet-Draft draft-carpenter-behave-referral-object-01, October 2009.

Authors' Addresses

Reinaldo Penno Juniper Networks 1194 N Mathilda Avenue Sunnyvale, California 94089 USA EMail: rpenno@juniper.net
Tarun Saxena Cisco Systems EMail: tasaxena@cisco.com
Mohamed Boucadair France Telecom Rennes, 35000 France EMail: mohamed.boucadair@orange.com
Senthil Sivakumar Cisco Systems 7100-8 Kit Creek Road Research Triangle Park, North Carolina 27709 USA EMail: ssenthil@cisco.com