Internet DRAFT - draft-dupont-6man-nat64handoff
draft-dupont-6man-nat64handoff
Network Working Group K. Dupont
Internet-Draft April 4, 2019
Intended status: Standards Track
Expires: October 6, 2019
NAT64 Handoff
draft-dupont-6man-nat64handoff-00
Abstract
This document describes a NAT64 extension which allows IPv4 hosts to
learn the real IP address of hosts which they are communicating with
and assume responsibility to maintain the authoritative connection
tracking table.
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 October 6, 2019.
Copyright Notice
Copyright (c) 2019 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 October 6, 2019 [Page 1]
Internet-Draft NAT64 Handoff April 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Communication model . . . . . . . . . . . . . . . . . . . . . 3
4. Packet formats . . . . . . . . . . . . . . . . . . . . . . . 4
5. Packet formats from NAT64 to server . . . . . . . . . . . . . 7
6. Packet formats from server to NAT64 . . . . . . . . . . . . . 7
7. Multiple connection tracking entry format . . . . . . . . . . 7
8. NAT64 operation . . . . . . . . . . . . . . . . . . . . . . . 8
9. Token validation . . . . . . . . . . . . . . . . . . . . . . 10
10. Server operation . . . . . . . . . . . . . . . . . . . . . . 11
11. Server side NAT . . . . . . . . . . . . . . . . . . . . . . . 12
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14. Normative References . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Due to shortage of IPv4 addresses various models of NAT are seeing
widespread usage as a way to reach IPv4-only services. The use of
NAT has some drawbacks. This document aims to address two of those
drawbacks by providing an extension for NAT64.
Connection tracking entries on the NAT can be expired due to
idleness. When doing such expiry the NAT has no way of knowing if
the entry was still in use and may cause connections between client
and server to be interrupted.
The server doesn't know the real IP address of the client. For the
purpose of debugging software bugs and investigating abuse all
clients using the same NAT device will appear indistinguishable to
the server.
This document provides a NAT64 extension which aims to solve these
two drawbacks by allowing the server to assume responsibility to
maintain the authoritative version of the connection tracking table
and allowing the NAT64 to only maintain a cache in which entries can
be purged without causing connections to be interrupted.
2. Terminology
NAT64: A dual-stack host translating TCP and UDP according to
[RFC6146] and implementing the NAT64 handoff protocol as specified in
this document.
Server: An IPv4 host implementing the server component of
Dupont Expires October 6, 2019 [Page 2]
Internet-Draft NAT64 Handoff April 2019
Client: An IPv6 host which initiates communication through a NAT64
capable NAT64.
NAT64 handoff: The UDP based protocol specified in this document to
exchange connection tracking between NAT64 and server.
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
The communication model involves a many-to-many relation between
clients and NAT64 devices as well as a many-to-many relation between
NAT64 devices and servers.
Application data is transmitted and translated according to
[RFC6146]. This document adds a control channel between NAT64 and
server. There is a separate control channel per NAT64 and server
pair. The control channel is uniquely identified by the pair of IPv4
addresses of the NAT64 and server.
+--------+ +--------+ +--------+ +--------+
| Client | | Client | | Client | | Client |
+--------+ +--------+ +--------+ +--------+
| | | |
+-----------+-----+------+-------------+
|
+------------V-----------+
| NAT64 |
+------------------------+
| |
Application | | Control
| |
+----------V---V---------+
| Server |
+------------------------+
Figure 1: The communication model
This protocol aims to move as much state as possible from the NAT64
to the server and change the remaining state still needed on NAT64 to
serve as a cache which can be purged as needed and repopulated from
the server.
Protection against IP spoofing is done through the use of tokens in
the control channel messages. These tokens are chosen by the NAT64
Dupont Expires October 6, 2019 [Page 3]
Internet-Draft NAT64 Handoff April 2019
in order to allow the NAT64 to use a stateless algorithm to generate
tokens.
4. Packet formats
The NAT64 handoff packets are UDPv4 packets exchanged between a port
on the IPv4 address of the NAT64 and the NAT64 handoff server port
(TBD) on the IPv4 address of the server. The UDP payload consist of
a sequence of messages.
Message formats are determined by the first nibble of the message.
Following message formats are defined:
0 - Reserved to avoid ambiguity in message parsing if NAT64
handoff and Teredo are ever accidentally or deliberately mixed
on the same port.
1 - Reserved for future extensions.
2 - Reserved for future extensions.
3 - NAT64 handoff messages.
4 - IPv4 packet.
5 - Reserved for future extensions.
6 - IPv6 packet.
7-15 - Reserved for future extensions.
An implementation of NAT64 handoff MUST support packet formats 3, 4,
and 6. A packet containing a message of an unknown format MUST be
silently dropped.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 3 | Type | Msg Data Len | Message Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Type 4-bit identifier of the type of message.
Msg Data Len 8-bit unsigned integer. Length of the Message Data
field of this message, in 16 bit units.
Message Data Variable-length field. Message-Type-specific data.
0 - Reserved for future extensions
Dupont Expires October 6, 2019 [Page 4]
Internet-Draft NAT64 Handoff April 2019
1 - Protocol identifier
2 - No-op
3 - Invalid
4 - Token
5 - Token rotation
6 - Remote IPv6 address authenticator
7 - Connection tracking entry
8 - Mapped port hint
9-15 - Reserved for future extensions
An implementation of the NAT64 handoff server component MUST
understand messsage types 4, 5, 6, and 7 and SHOULD understand
message types 1 and 8. An implementation of NAT64 with handoff
extension MUST understand message types 4, 6, and 7.
An implementation of either component MUST ignore messages of unknown
types.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 3 | 1 | 72 | Message Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Message data must be the 144 octet string
"[[ This is the NAT64 handoff protocol. The client is using "
"IPv6. To know their real IP address you need to use this "
"protocol or support IPv6. ]]"
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 3 | 4/5/6 | Msg Data Len | Message Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
For message types 4, 5, and 6 the NAT64 choose the contents of
message data and its length. The length of message data MUST be an
even number of octets and at most 510 octets. The message data
SHOULD be generated as a Message Authentication Code of at least 16
octets using a secret key known only to the NAT64 itself. The server
MUST accept message data of any length from 0 to 510 octets.
Dupont Expires October 6, 2019 [Page 5]
Internet-Draft NAT64 Handoff April 2019
For message type 4 message data SHOULD be a MAC of the server IPv4
address computed using a key known only to the NAT64.
For message type 5 message data MUST be computed the same way as
message type 4 but using the most recently expired key.
For message type 6 message data should be a MAC of the server IPv4
address and client IPv6 address computed using a key known only to
the NAT64.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 7 | 16 | Mapped port number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| NAT64 /96 prefix |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Client IPv6 address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client port number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 8 | 1 | Suggested port number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Not every concatenation of messages form a valid packet. With the
exception of the multi-connection-tracking-entry format explained
below a packet MUST NOT contain more than one message of each type.
When a receiver parses a message containing multiple messages of same
type it MAY pick one message of each type to process and ignore the
rest. The sender MAY put the messages in a packet in any order.
Any IPv4 or IPv6 packet included in a control channel packet MUST be
the last message in the packet. The receiver MAY stop parsing once
it sees an IPv4 or IPv6 packet. This also means that a sender is not
allowed to include both an IPv4 and an IPv6 packet in the same
control channel message.
Dupont Expires October 6, 2019 [Page 6]
Internet-Draft NAT64 Handoff April 2019
5. Packet formats from NAT64 to server
All control channel packets from NAT64 to server MUST include a token
message (message type 4). And they MUST include at least one of
connection tracking entry (message type 7), IPv4 packet, IPv6 packet.
Any IPv4 or IPv6 packet sent from NAT64 to server must be the before
translation version of the packet.
A packet with a connection tracking entry (messsage type 7), must
include a protocol identifier (message type 1) and remote IPv6
address authenticator (message type 6).
A packet with an IPv6 packet must include a remote IPv6 address
authenticator (message type 6). It MAY include a mapped port hint
(message type 8).
6. Packet formats from server to NAT64
All control channel packets from server to NAT64 MUST satisfy at
least one of the following three requirements.
Include a token message (message type 4) and an IPv4 packet before
or after translation.
Include a remote IPv6 address authenticator (message type 6) and a
post-translation IPv6 packet.
Include a remote IPv6 address authenticator (message type 6) and a
connection tracking entry (messsage type 7). Packets of this
format MAY include any IPv4 or IPv6 packet before or after
translation.
7. Multiple connection tracking entry format
Packets sent from NAT64 to server may follow the format in this
section. This is the only packet format which permits multiple
messages of the same type.
The packet must contain a protocol identifier (message type 1) and a
token (message type 4).
The packet must contain one or more groups of messages in which each
group consists of exactly one remote IPv6 address authenticator
(message type 6) followed by one or more connection tracking entries
(messsage type 7). The remote IPv6 address authenticator must be
valid for all connection tracking entries in the group.
The UDP payload MUST NOT exceed 1232 octets.
Dupont Expires October 6, 2019 [Page 7]
Internet-Draft NAT64 Handoff April 2019
The packet must not contain an IPv4 or IPv6 packet.
8. NAT64 operation
Upon receiving a packet the NAT64 must first classify the packet as
one of the following:
Packet subject to NAT
Control plane packet
ICMP packet
Packet with invalid destination IP
IPv4 packets are classified as follows:
Incoming packets with destination address different from the NAT64
public IPv4 address are considered as invalid destination.
Packets with protocol number 1 are ICMP.
Packets sent from UDP port (TBD) to the client side port (chosen
by NAT64) are control packets.
Packets with destination port 80 may be treated as HTTP.
All other packets are subject to NAT.
IPv6 packets are classified as follows:
If destination address is within one of the NAT64 prefixes
configured on this NAT64 and the first octet of the embedded IPv4
address is not 0 or 127 the packet is subject to NAT.
Any other destination address is considered as invalid
destination.
IPv4 packets subject to NAT are handled as follows:
If it is neither TCP nor UDP forward it over the control
connection to the server.
If it matches a cached connection tracking entry from the server
perform translation.
If it matches a NAT64 generated connection which has previously
been used with this IPv4 address perform translation.
Dupont Expires October 6, 2019 [Page 8]
Internet-Draft NAT64 Handoff April 2019
If it matches a NAT64 generated connection which has not been used
with this IPv4 address and no valid control packets have ever been
received from that server IPv4 address the NAT64 can choose
between performing translation and sending the packet over the
control channel to the server.
Otherwise send the packet over the control channel to the server.
IPv6 packets subject to NAT are handled as follows:
If it is neither TCP nor UDP forward it over the control
connection to the server.
If it matches a cached connection tracking entry from the server
perform translation.
If it matches a NAT64 generated connection entry which has
previously been used with this IPv4 address perform translation.
If a valid control packet has previously been received from this
server IPv4 address forward it over the control connection to the
server.
If no NAT64 generated connection tracking entry exists for this
source IPv6/port create an entry. Record that the entry (new or
existing) has been used with this server IPv4 address. Perform
translation.
ICMP error messages containing a (truncated) IPv4 error are handled
as follows:
If the ICMP packet has invalid checksum it is silently dropped.
If the embedded packet source address does not match the NAT64
public IPv4 address, the ICMP error is silently dropped.
If the embedded IP payload is an ICMP packet, handle the packet
according to [RFC0792] considering the NAT64 itself to be the
final destination of the packet.
If the embedded packet is a UDP packet from the client side port
(chosen by NAT64) to the server side port (TBD) it's considered to
be an undelivered control packet and is silently dropped. If the
origin IP of the ICMP error matches the destination IP of the
inner IP packet, and the ICMP error has type 3 and code 3, and the
payload contains a valid token, the NAT64 must consider the
handoff server to be down. The NAT64 must switch back to
generating connection entries as if that server IPv4 address never
Dupont Expires October 6, 2019 [Page 9]
Internet-Draft NAT64 Handoff April 2019
supported handoff in the first place. Any previously cached
connection entries from that server must be kept in cache and
expired as if the server was still responding. Once the server is
confirmed to be responding again the still cached connection
entries must be sent to the server.
If the embedded IP payload is not TCP or UDP forward the packet
over the control connection to the source IP of the embedded IP
payload.
If the embedded IP payload matches a cached connection from the
server perform translation.
If the embedded IP payload matches a NAT64 generated connection
previously used with the destination IP of the embedded IP packet
perform translation.
Otherwise forward the packet over the control connection to the
source IP of the embedded IP payload.
9. Token validation
When the NAT64 server component receives a packet with an unknown
combination of token, NAT64 IPv4 address and port number, the server
MUST validate it according to the following algorithm which requires
no per-NAT64 state until validation succeeds.
Compute a Message Authentication Code calculated over token, client
IPv4 address, and client port. The server may rotate the MAC key 30
seconds after it was last used to send a validation packet. If the
control channel packet contains an IPv4 packet and the MAC is found
inside of that IPv4 packet the client is authenticated and the IPv4
address, port number, and token are stored by the server. Then
proceed with processing the packet as an authenticated packet.
Apply attenuation which is recommended to be implemented as follows:
At server start time initialize a counter of packets to process to as
two. On recepit of a packet if the counter is zero silently drop the
packet and set the counter to 1 or 2 with a 50% probability each.
Otherwise decrease the counter and continue processing. The server
MAY use a per NAT64 counter if it has previously communicated with
that NAT64 but the token is unknown.
Generate an IPv4 validation packet to the NAT64 which will not match
any connection tracking entry. That packet MUST include a Message
Authentication Code calculated by server over token, client IPv4
address, and client port. The server may rotate the MAC key 30
seconds after it was last used to send a validation packet.
Dupont Expires October 6, 2019 [Page 10]
Internet-Draft NAT64 Handoff April 2019
The IPv4 validation packet MAY be formatted as a UDP packet from the
NAT64 handoff server port (TBD) to UDP port 9 (discard) formatted as
a control channel message containing remote IPv6 address
authenticator and a no-next-header IPv6 packet using the previously
computed MAC as IPv6 payload.
The NAT64 must treat this as a packet not matching a known connection
tracking entry and encapsulate the entire packet in a UDP packet sent
back to the server. If the NAT64 implements attenuation against
reflection attacks it must parse the received packet as a control
channel packet and look for a valid token or remote IPv6 address
authenticator, if either of those is found it must not drop the
packet.
10. Server operation
When the the server receives a packet with a valid token it is
handled according to this section.
When the server receives an IPv6 packet over the control connection
it must look for a matching connection tracking entry and if none
exists it must create one. When using the public IPv4 address of the
NAT64 for the connection entry it must use a port number in the range
1024-65535 avoiding the following port numbers:
3544
NAT64 handoff server port (TBD)
The source port of the current control channel packet.
The server must then either:
Translate the packet to IPv4 and deliver it directly
Translate the packet to IPv4 and return it to the NAT64
Return the connection tracking entry and IPv6 packet to the NAT64
When the server receives an IPv4 packet over the control connection
it must look for a matching connection tracking entry. If no
matching connection tracking entry is found the server should return
the packet to the NAT64 if it is a TCP or UDP packet and otherwise
construct an appropriate ICMP error message which it can either
deliver directly or send back over the control connection to the
NAT64.
If a match is found the server must then either:
Dupont Expires October 6, 2019 [Page 11]
Internet-Draft NAT64 Handoff April 2019
Translate the packet to IPv6 and deliver it directly
Translate the packet to IPv6 and return it to the NAT64
Return the connection tracking entry and IPv4 packet to the NAT64
11. Server side NAT
When the server creates new connection tracking entries it can choose
between using the public IPv4 address of the NAT64 or an address from
the ranges specified in [RFC1918] or [RFC6598].
A minimal server side implementation will always use the public IPv4
address of the NAT64 and never perform NAT itself. This will be
limited to TCP and UDP support and will cost an extra roundtrip each
time the NAT64 cache needs to be populated. It will be subject to
the limitations in choice of port number for connection tracking
entries outlined in this protocol. But it still allows a larger
number of connections than relying entirely on the NAT64 as it won't
be competing against servers on other IPv4 addresses for the same
pool of port numbers.
Using a local IP range on the server side has several advantages.
But it requires server side NAT which also requires the server to run
with the additional privileges needed to create a virtual network
interface for this purpose.
Advantages of server side NAT is that there is access to more IPv4
addresses thus a larger pool of available ports. And it is not
subject to the requirements that the same port number be used for
mappings towards all TCP and UDP ports server side. It also allows
translation of all protocols needed by the server, not just TCP and
UDP. It also completely avoids the use of cache entries on the NAT64
and the roundtrips needed to populate the cache.
A mixed mode operation is also possible where the public IPv4 address
of the NAT64 is used even with protocols not supported by the NAT64
and connections absent from the NAT64 cache. In this mode the NAT64
will tunnel IPv6 packets to the server. The server performs NAT and
can either deliver the IPv4 packets directly or tunnel them back to
the NAT64.
IPv4 packets from the server are sent to the NAT64 which tunnels them
to the server for translation. Once packets have been translated to
IPv6 the server can either deliver them directly or tunnel them back
to the NAT64.
Dupont Expires October 6, 2019 [Page 12]
Internet-Draft NAT64 Handoff April 2019
The extra roundtrip due to all the IPv4 packets needing to go from
server to NAT64 and back to the server makes this mode less
desirable. The extra roundtrip can be avoided at the cost of very
complicated routing rules on the server. Whether to use this
operation mode is choice made server side and the complexity of
supporting it lies server side. The NAT64 is required to support
this operation mode in case any server it communicates with makes use
of it. The NAT64 side just needs to support the tunneling required
for this.
12. Security Considerations
This protocol addresses one security concern around NAT64 by making
it harder for attacks to go through a NAT64 as a way to hide their IP
address. Other security considerations regarding NAT64 still apply.
The control channel introudced by this document operates over UDP and
as such it needs to protect against reflection attacks. Control
channel packets received by the NAT64 all contain either a token or a
remote IPv6 address authenticator which can validate their
authenticity and spoofed packets can be silently dropped. Control
channel packets received by the server are required to be attenuated
before processing if they do not contain a known valid token. If
attenuation is implemented using the algorithm suggested by this
document the attenuation factor will be 60%. That means if packets
with spoofed source IP are sent to the server component only 40% of
them will generate a response.
The tokens and remote IPv6 address authenticators specified in this
document not only serves as protection against reflections but also
protect against:
Connection cache poisoning
Using control channel for injecting spoofed packets
IPv4 hosts using the NAT64 to send traffic to IPv6 hosts which did
not themselves initiate communication through the NAT64.
Application layer security mechanisms such as those implemented by
SSH and TLS will work the same with and without NAT64 handoff.
13. IANA Considerations
One UDP port number for the NAT64 handoff server component needs to
be allocated by IANA.
Dupont Expires October 6, 2019 [Page 13]
Internet-Draft NAT64 Handoff April 2019
Service Name: NAT64 handoff
Transport Protocol(s): UDP
Description: NAT64 handoff
Reference: This document.
Port Number: TBD -- To be assigned by IANA.
14. Normative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>.
[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>.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
2012, <https://www.rfc-editor.org/info/rfc6598>.
[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>.
Author's Address
Kasper Dupont
Ellemosevaenget 31
Tranbjerg J. 8310
Denmark
Email: kasperd@ntstm.30.mar.2019.kasperd.dk
Dupont Expires October 6, 2019 [Page 14]
