Behavior Engineering for Hindrance                              R. Penno
Avoidance                                                      T. Saxena
Internet-Draft                                          Juniper Networks
Intended status: Informational                                   D. Wing
Expires: July 12, 2010                                     Cisco Systems
                                                         January 8, 2010


                       Analysis of 64 Translation
                   draft-penno-behave-64-analysis-02

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 July 12, 2010.



Penno, et al.             Expires July 12, 2010                 [Page 1]


Internet-Draft           analysis-64-translation            January 2010


Copyright Notice

   Copyright (c) 2010 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 64 Translation Against Concerns of RFC4966 . . . .  4
     2.1.  Problems Not Addressed by 64 . . . . . . . . . . . . . . .  4
     2.2.  Problems Addressed by 64 . . . . . . . . . . . . . . . . .  6
     2.3.  Problems Addressed by NAT44 Translation 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 . . . . . . . . . . . . . . . . . . . . . . . . 10



















Penno, et al.             Expires July 12, 2010                 [Page 2]


Internet-Draft           analysis-64-translation            January 2010


1.  Introduction

   The current 64 proposal is widely seen as the next step in the
   evolution of interconnection equipment enabling communication between
   IPv6-only and IPv4-only networks.  One of the building blocks of this
   proposal is decoupling the DNS functionality from the NAT protocol
   translation itself.

   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 64 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-only to IPv4-only
   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 64 proposal analyzed 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 described in 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 July 12, 2010                 [Page 3]


Internet-Draft           analysis-64-translation            January 2010


   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.

   The scope of this document does not include stateless translation.

      Open Issue: should we include stateless translation in the scope?


2.  Analysis of 64 Translation Against Concerns of RFC4966

   Of the set of problems pointed out in RFC4966, the 64 proposal
   addresses some problems, whereas leaves others unaddressed.  It is
   also worth pointing out that the scope of the 64 proposal is redeuced
   when compared to NAT-PT.  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).

           Analysis: In the case of FTP [RFC0959] this problem is
           addressed by the use of a FTP64 ALG [I-D.ietf-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.




Penno, et al.             Expires July 12, 2010                 [Page 4]


Internet-Draft           analysis-64-translation            January 2010


   7.   Inability to handle multicast traffic.

           Analysis: 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.

           Analysis: 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.

           Analysis: This specific DoS concern on Page 6 of [RFC4966] is
           under a DNS-ALG heading in that document, and refers to NAT-
           PT's creation of NAT mapping state when a DNS query occurred.
           With the new IPv6/IPv4 translation mechanisms, DNS queries do
           not create mapping state.  Thus, this concern is fully
           eliminated with the new IPv6/IPv4 translation mechanisms.

   10.  Restricted validity of translated DNS records: a translated
        record may be forwarded to an application that cannot use it.

           Analysis: If a node on the IPv4 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 contraint of
           NAT, then the new node will not be able to initiate contact.

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

           Analysis: This is still true for 64.

   12.  Address selection issues when either the internal or external
        hosts implement both IPv4 and IPv6

           Analysis: This is not fully resolved and mitigation
           techniques outisde the 64 protocols need to be used.







Penno, et al.             Expires July 12, 2010                 [Page 5]


Internet-Draft           analysis-64-translation            January 2010


2.2.  Problems Addressed by 64

   Problems, identified in RFC4966, which are adequately addressed by
   the 64 proposal::

   1.  Constraints on network topology (as it relates to DNS-ALG; see
       Section 3.1 of [RFC4966])

          Analysis: This issue has mitigated severity as the DNS is
          separate from the NAT box

   2.  Inappropriate translation of responses to A queries from IPv6
       nodes.

          Analysis: DNS64 does not translate A queries, so this concern
          has been resolved.

   3.  Address selection issues and resource consumption in a DNS-ALG
       with multi-addressed nodes

          Analysis: 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.

   4.  Limitations on DNS security capabilities when using a DNS-ALG.

          Analysis: A DNSSEC validating stub resolver behind a DNS64 in
          server mode is not supported.  Therefore if a host wants to do
          its own DNSSEC validation, and it wants to use a NAT64, the
          host has to also perform its own DNS64 synthesis.

   5.  Creation of a DoS (Denial of Service) threat relating to
       exhaustion of memory and address/port pool resources on the
       translator.

          Analysis: This specific DoS concern on Page 6 of [RFC4966] is
          under a DNS-ALG heading in that document, and refers to NAT-
          PT's creation of NAT mapping state when a DNS query occurred.
          With the new IPv6/IPv4 translation mechanisms, DNS queries do
          not create mapping state.  Thus, this concern is fully
          eliminated with the new IPv6/IPv4 translation mechanisms.

2.3.  Problems Addressed by NAT44 Translation 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
   orthogonal to the translation algorithm per se, therefore they could



Penno, et al.             Expires July 12, 2010                 [Page 6]


Internet-Draft           analysis-64-translation            January 2010


   be implemented with NAT-PT.  On the other hand, NAT64 explicitly
   mentions that these recommendations need to be followed and thus
   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.

          Analysis: Since NAT64 follows some of the RFC4787, RFC5382 and
          RFC5508 requirements, there is a high lower bound for the
          lifetime of 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 approximately 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.

          Analysis: It is not clear if address persistence should be
          maintained only between sessions that overlap across time.
          Moreover, it is not clear if addresses persistence should be
          maintained between static and dynamic bindings.

          In the simpler case of address persistence between dynamic
          sessions that overlap in time, since NAT64 recommends the use
          of endpoint independent mapping, depending on how many other
          sessions established for the same endpoint, it may be the case
          that in many situations 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 interconnection.

   Some of the issues, as pointed out in RFC 4966, have possible



Penno, et al.             Expires July 12, 2010                 [Page 7]


Internet-Draft           analysis-64-translation            January 2010


   solutions.  However these solutions will require significant updates
   to the 64 proposal, increasing its complexity.


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 and Mohamed Boucadair for their 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.




Penno, et al.             Expires July 12, 2010                 [Page 8]


Internet-Draft           analysis-64-translation            January 2010


   [RFC5508]  Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
              Behavioral Requirements for ICMP", BCP 148, RFC 5508,
              April 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-03 (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-05 (work in progress),
              December 2009.

   [I-D.ietf-behave-ftp64]
              Beijnum, I., "IPv6-to-IPv4 translation FTP
              considerations", draft-ietf-behave-ftp64-00 (work in
              progress), December 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-04 (work in progress),
              December 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-07 (work
              in progress), December 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.

   [I-D.wing-behave-dns64-config]
              Wing, D., "DNS64 Resolvers and Dual-Stack Hosts",
              draft-wing-behave-dns64-config-00 (work in progress),
              January 2010.





Penno, et al.             Expires July 12, 2010                 [Page 9]


Internet-Draft           analysis-64-translation            January 2010


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 July 12, 2010                [Page 10]