Internet DRAFT - draft-dupont-6man-nat64tp

draft-dupont-6man-nat64tp







Network Working Group                                          K. Dupont
Internet-Draft                                         November 29, 2020
Intended status: Standards Track
Expires: June 2, 2021


                         NAT64 Tunnel Protocol
                      draft-dupont-6man-nat64tp-02

Abstract

   This document describes a stateless NAT64 extension which allows for
   creation of reliable tunnels between islands of IPv6 deployment.

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 https://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 June 2, 2021.

Copyright Notice

   Copyright (c) 2020 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
   (https://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.






Dupont                    Expires June 2, 2021                  [Page 1]

Internet-Draft                   NAT64TP                   November 2020


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Communication model . . . . . . . . . . . . . . . . . . . . .   3
   4.  Protocol operation  . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  NAT64 outgoing operation  . . . . . . . . . . . . . . . .   4
     4.2.  NAT64 incoming operation  . . . . . . . . . . . . . . . .   5
     4.3.  NAT64TP endpoint operation  . . . . . . . . . . . . . . .   5
     4.4.  Intermediate network node operation . . . . . . . . . . .   7
   5.  Deployability . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Sunsetting IPv4 . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Prior protocols for connecting islands of IPv6 through tunnels over
   IPv4 exist including [RFC3056].  However since the introduction of
   those protocols NAT has gained widespread use and a majority of ISPs
   still have not started deploying IPv6.  For those reasons there is a
   need for a new way of connecting islands of IPv6.

   NAT64 as defined in [RFC6146] is a method for translating between
   IPv6 and IPv4.  This is intended to allow IPv6-only clients to reach
   IPv4-only services.  NAT64 also happens to be very useful for
   connecting islands of IPv6 to an IPv4-only ISP.  Moreover high
   availability can easily be achieved by connecting an island of IPv6
   through redundant NAT64 gateways to multiple ISPs.

   Many prior tunnel protocols fail to work reliably when one endpoint
   of the tunnel is behind NAT.  And none of them work reliably when
   both endpoints are behind NAT64.

   [RFC6146] specifies support for use of UDP, TCP, and ICMP.  Of those
   only UDP is suitable for building a tunnel protocol.  But when both
   endpoints are connecting through NAT the use of hole punching will be
   necessary.  And in many NAT setups, especially those using multiple
   layers of NAT, the use of hole punching is unreliable.  Even when
   these work they rely on state in each NAT device in order to maintain
   a connection.

   This document defines NAT64TP (the NAT64 Tunnel Protocol).  NAT64TP
   is a simple stateless NAT64 extension which allows tunnel protocols



Dupont                    Expires June 2, 2021                  [Page 2]

Internet-Draft                   NAT64TP                   November 2020


   to reliably establish connections between islands of IPv6.  NAT64TP
   achieves this by using UDP packets in which each packet carries
   enough information in their UDP payload to route them to their
   destination with no state being maintained.

   NAT64TP only differs from [RFC6146] in very minor ways such that it
   can easily be added to existing NAT64 implementations.  This also
   allows NAT64TP to achieve reliability when only a subset of the
   involved NAT64 gateways implement NAT64TP.

2.  Terminology

   NAT64: A dual-stack node translating TCP and UDP according to
   [RFC6146] and optionally implementing the NAT64TP protocol as
   specified in this document.

   NAT64TP: The NAT64 Tunnel Protocol is the extension for NAT64 defined
   in this document.

   Endpoint: An IPv6-only or dual-stack node which implements a higher
   level protocol on top of the NAT64TP protocol as specified in this
   document.

   Outer IP header: The IP header in front of the UDP header which gets
   translated from IPv6 to IPv4 and back during transmission.

   Inner IPv6 header: The IP header at the start of the UDP payload.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
   as shown here.

3.  Communication model

   NAT64TP packets are IPv6 packets encapsulated in UDP.  The UDP
   packets are translated by NAT64 gateways according to slightly
   different rules than [RFC6146].












Dupont                    Expires June 2, 2021                  [Page 3]

Internet-Draft                   NAT64TP                   November 2020


    +---------------------------------------------------+
    |                   IPv4 backbone                   |
    +---------------------------------------------------+
         |            |               |            |
         |            |               |            |
    +---------+  +---------+     +---------+  +---------+
    |  NAT64  |  |  NAT64  |     |  NAT64  |  |  NAT64  |
    +---------+  +---------+     +---------+  +---------+
         |            |               |            |
         |            |               |            |
    +----------------------+     +----------------------+
    |       Endpoint       |     |       Endpoint       |
    +----------------------+     +----------------------+
              Figure 1: The communication model

   Each endpoint has access to one or more NAT64 gateways which allow
   for communication through the IPv4 backbone.  For redundancy the
   NAT64 gateways can connect to different IPv4 providers.  At least one
   of the NAT64 gateways SHOULD support the NAT64TP protocol as
   specified in this document.

4.  Protocol operation

4.1.  NAT64 outgoing operation

   Upon receiving an UDPv6 packet with source port TBD the NAT64 MUST
   validate that the packet is a valid NAT64TP packet.

      The UDP payload length MUST be at least 40 octets.

      The inner IP version field MUST contain the value 6.

      The inner source IP MUST be identical to the outer source IP.

   The NAT64 MAY additionally validate the following fields.

      The UDP length field MUST have the same value as the payload
      length field in the outer IPv6 header.

      The UDP length field MUST be exactly 48 octets plus the payload
      length specified in the inner IPv6 header.

      The inner hop limit MUST be in the range 43 to 255.

   A UDPv6 packet with source port TBD which fails any of the
   validations performed MUST be either dropped or translated as regular
   stateful NAT64.  If the packet is dropped the NAT64 MAY generate an
   ICMPv6 error message.



Dupont                    Expires June 2, 2021                  [Page 4]

Internet-Draft                   NAT64TP                   November 2020


   A packet which matches all of the validations performed MUST be
   translated statelessly.  The outer source IP and destionation IP are
   translated as in [RFC6146].  The UDP source and destination port MUST
   remain unchanged after translation.  If the inner hop limit was
   validated it SHOULD be reduced to 42.

   If the UDP header has a checksum it MUST be adjusted to reflect all
   of the changes made to the packet.

4.2.  NAT64 incoming operation

   Upon receiving an UDPv4 packet with destination port TBD the NAT64
   MUST validate that the packet is a valid NAT64TP packet.

      The UDP payload length MUST be at least 40 octets.

      The inner IP version field MUST contain the value 6.

      The inner hop limit MUST be in the range 22 to 255.

   The NAT64 MAY additionally validate the following field.

      The IPv4 total length field MUST be equal to the sum of the IPv4
      header length and the UDP length.

      The UDP length field MUST be exactly 48 octets plus the payload
      length specified in the inner IPv6 header.

   A UDPv4 packet with destination port TBD which fails any of the
   validations performed MUST be dropped.  The NAT64 MAY generate an
   ICMP error message.

   A packet which matches all of the validations performed MUST be
   translated statelessly.  The outer source IP is translated as in
   [RFC6146].  The inner destination IP is copied to the outer
   destination IP.  The UDP source and destination port MUST remain
   unchanged after translation.  The inner hop limit MUST be reduced to
   21.

   If the UDP header has a checksum it must be adjusted to reflect all
   of the changes made to the packet.  If the UDP packet has no checksum
   a checksum must be computed over the resulting packet.

4.3.  NAT64TP endpoint operation

   NAT64TP is a layer of the networking stack.  Like IP and UDP this
   layer is intended as basis on which to build higher layer protocols.
   The higher layer protocols to be used over NAT64TP are generally



Dupont                    Expires June 2, 2021                  [Page 5]

Internet-Draft                   NAT64TP                   November 2020


   expected to be a VPN or something resembling it.  The full
   specification of the higher layer protocol is outside the scope of
   this document.

   The intermediate NAT64 gateways only need to implement the NAT64TP
   layer as specified in this document and need no knowledge of the
   higher layer.  Inspection of the higher layer protocols won't even be
   possible for the NAT64 gateways due to the encryption used by the VPN
   layer.

   NAT64TP endpoints MUST comply with both the sepcification in this
   document and the specification of the higher layer protocol which
   they implement.

   When originating a NAT64TP packet the endpoint MUST construct a
   header chain consisting of at least three headers: Outer IPv6 header,
   UDP header, and inner IPv6 header.  The headers MUST satisfy the
   following requirements:

      All three headers MUST have consistent length information which
      agrees on which octet is the last of the packet.

      Inner and outer IPv6 headers MUST have identical source address.

      Outer IPv6 header MUST have next header 17 (UDP).

      The UDP header MUST have source port TBD.

      The UDP header MUST have a valid checksum.

      Inner IPv6 header MUST have a hop limit in the range 63 to 255.

   Packets originated from a NAT64TP endpoint SHOULD be at most 1280
   octets including the outer IPv6 header.  When larger payloads are
   needed the NAT64TP endpoint SHOULD either use a fragment header
   following the inner IPv6 header or implement fragmentation at a
   higher protocol layer.

   When receiving a NAT64TP paket the endpoint MUST accept packets with
   any outer source IP and any UDP source port.  The higher layer
   protocol MUST validate the authenticity and integrity of the packet
   based on the payload of the inner IPv6 packet.

   When receiving a valid NAT64TP packet from an unknown outer source IP
   and UDP source port combination the endpoint SHOULD learn this source
   address as a possible network path for return traffic.  If the outer
   source IP is within a known NAT64 prefix, the endpoint SHOULD attempt




Dupont                    Expires June 2, 2021                  [Page 6]

Internet-Draft                   NAT64TP                   November 2020


   recombining the embedded IPv4 address with other known NAT64 prefixes
   to learn alternative network paths.

   When sending packets over a learned network path the higher layer
   protocol MUST take steps to guard against hijacking of traffic.
   These steps MAY include: preference for paths with lowest latency and
   encryption and digital signatures applied to payload data.

   When choosing between possible network paths for sending a packet an
   endpoint SHOULD include the inner destination IP and port TBD as one
   of the possible options for filling in outer destination IP and
   destination UDP port.

   The configuration of an endpoint SHOULD allow for at least the
   following two ways of configuring available network paths to a peer:

      A list of NAT64 prefixes available to the local endpoint and a
      list of IPv4 addresses of NAT64TP gateways available to the remote
      endpoint.  All combinations of these combined with destination
      port TBD should be considered possible network paths.

      A list of full IPv6 address and port number combinations for
      network paths which doesn't follow the above scheme or where the
      length of the NAT64 prefix being used isn't known.

   An endpoint implementation SHOULD have the ability to send periodic
   probe packets across its prefered network paths.  If probe packets
   are lost the endpoint SHOULD try alternative paths known to the same
   destination.  These probes additionally serve the purpose of keeping
   alive state in case either NAT64 is stateful and doesn't implement
   NAT64TP.

4.4.  Intermediate network node operation

   Routers on the network path between the endpoints only need to
   consider the outer IP header in their routing decisions.  Routers MAY
   include the following fields from the UDP header and inner IPv6
   header in ECMP hashes:

      Source and destination port

      Flow label

      Source and destination IP

   Routers MUST NOT modify the UDP header or payload in transit.





Dupont                    Expires June 2, 2021                  [Page 7]

Internet-Draft                   NAT64TP                   November 2020


   NAT64 gateways MUST update inner hop limit as well as UDP Port
   numbers and checksum as specified in this document.  Other than that
   no part of the UDP header or payload may be modified in transit.

   The minimum hop limit of originated packets was chosen as 63 to allow
   the default value of most currently deployed implementations to work
   without changes.  The values in the range 1 to 63 has been split
   evenly between the three legs of communication separated by the NAT64
   gateways.  This is done to ensure that packets reach their
   destination even if a small number of intermediate network nodes
   erroneously decrement the inner hop limit when they shouldn't.

5.  Deployability

   NAT64TP endpoints will in some cases work even if neither NAT64
   gateway supports NAT64TP.  If and endpoint combines NAT64TP with
   traditional hole punching techniques it can achieve similar
   reliability even if none of the NAT64 gateways support NAT64TP.
   Those properties make it worthwhile for endpoints to support NAT64TP
   even when only a minority of NAT64 gateways support NAT64TP.

   Due to the similarity between NAT64TP and [RFC6146] it only takes
   minimal effort to extend existing NAT64 implementations to support
   NAT64TP.  Because NAT64TP needs no state there is an incentive to
   deploy it in order to save on state tracking.  NAT64TP needs just a
   single port which cannot be used for stateful connections.  Thus it
   only takes two NAT64TP users before NAT64TP support uses fewer ports
   than stateful NAT64.  And since NAT64TP can achieve reliability when
   supported by just one side of the communication, there is an
   incentive to deploy it even if other NAT64 gateways haven't deployed
   it yet.

5.1.  Sunsetting IPv4

   If a reliable native IPv6 path exists between a pair of endpoints the
   traffic between those endpoints SHOULD prefer that network path over
   those network paths involving NAT64 gateways translating the outer
   header from IPv6 to IPv4 and back.

   This allows for NAT64 gateways to be turned down when they are no
   longer needed for reaching IPv4-only networks/services.

6.  Security Considerations

   This document specifies the NAT64TP layer.  Endpoints MUST implement
   a higher layer on top of NAT64TP.  Any protocol which can run on IPv6
   could be used but for security it MUST be one which takes proper
   steps to protect confidentiality and integrity.



Dupont                    Expires June 2, 2021                  [Page 8]

Internet-Draft                   NAT64TP                   November 2020


   To protect against DoS attacks by looping packets through a pair of
   NAT64 gateways it is important for gateways implementing NAT64TP to
   handle hop limit on the incoming path exactly as defined in this
   document.

   This protocol is not intending to hide the origin of packets.  The
   source IP which a packet had before translation can always be deduced
   by the contents of the packet after translation.

7.  IANA Considerations

   One UDP port number for the NAT64TP protocol needs to be allocated by
   IANA.

      Service Name: NAT64TP
      Transport Protocol(s): UDP
      Description: NAT64 Tunnel Protocol
      Reference: This document.
      Port Number: TBD -- To be assigned by IANA.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
              April 2011, <https://www.rfc-editor.org/info/rfc6146>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
              2001, <https://www.rfc-editor.org/info/rfc3056>.








Dupont                    Expires June 2, 2021                  [Page 9]

Internet-Draft                   NAT64TP                   November 2020


Author's Address

   Kasper Dupont
   Ellemosevaenget 31
   Tranbjerg J.  8310
   Denmark

   Email: kasperd@ntstm.30.mar.2019.kasperd.dk











































Dupont                    Expires June 2, 2021                 [Page 10]