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]
