Internet DRAFT - draft-rosenau-global-nat64
draft-rosenau-global-nat64
Network Working Group M. Rosenau
Internet-Draft December 29, 2015
Intended status: Experimental
Expires: July 1, 2016
Global NAT64 translation system (GlobalNAT64)
draft-rosenau-global-nat64-00
Abstract
This document describes an idea of a IPv6-to-IPv4 translation method.
The advantage of the method is that the required public IPv4
addresses are shared between the internet providers (and even between
the RIRs) so there are less IPv4 addresses required for IPv6-to-IPv4
translation mechanisms (NAT64, DS-Lite, 464XLAT).
The main disadvantage is that an IPv4 address range would have to be
reserved for this method.
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 July 1, 2016.
Copyright Notice
Copyright (c) 2015 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
Rosenau Expires July 1, 2016 [Page 1]
Internet-Draft GlobalNAT64 December 2015
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.
1. Introduction
Because of the IPv4 address shortage the IPv6 protocol has been
developed. Unfortunately most servers in the web are still IPv4-only
but the IPv4 addresses already ran out for most RIRs so new network
operators and internet providers can only provide IPv6 to their
customers
To enable IPv6-only hosts to access IPv4-only services there the
NAT64 method can be used which is described in RFC 6146 [RFC6146].
However this method requires the operator of NAT64 servers to have an
own IPv4 address range and IPv4 address space is short so the number
of new NAT64 servers is limited.
This document describes a method that would allow all NAT64 servers
to share the same IPv4 address range so IPv4 addresses required for
IPv6-to-IPv4 are saved and network operators and internet access
providers who only provide support for "outgoing" IPv4 TCP
connections would not even need an own IPv4 address range.
The method assumes that an IPv4 packet sent by a certain host to
another host will always be routed to the same destination host even
if multiple destination hosts (accidentally or intentionally) have
the same IPv4 address.
2. Terminology
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 BCP
14, RFC 2119 [RFC2119] and indicate requirement levels for compliant
implementations.
3. Theory of operation
3.1. Route discovery
The IPv6-only host establishing a TCP connection first sends a TCP-
SYN packet to the NAT64 to establish a TCP connection.
Because multiple NAT64 servers have the same IPv4 address it is not
predictable which NAT64 server will receive an IPv4 packet with the
NAT64 server's address as destination address.
Rosenau Expires July 1, 2016 [Page 2]
Internet-Draft GlobalNAT64 December 2015
The NAT64 will send a ping request to the IPv4-only host which is
listening for a TCP connection. The data of the ping request
contains the IPv6 address of the NAT64. It is assumed that the host
which will receive the ping response will also receive all IPv4
packets sent by the listening host to the given IPv4 address.
Two cases have to be distinguished:
- The ping response is received by the NAT64 which has sent the ping
request
- The ping response is received by another NAT64
3.2. Direct routing
If the ping response arrives at the NAT64 which has sent the ping
request the NAT64 can directly establish a TCP/IPv4 connection to the
destination host.
The packet sequence looks like this:
TCP Client (IPv6 or NAT64 TCP Server
private IPv4 address) (or CGNAT) (IPv4)
| | |
+-------- TCP-SYN --------->| |
| +------ Ping (IPv4) ------->|
| | |
| |<------ Ping resp. --------+
| | |
| +--------- TCP-SYN -------->|
| | |
| |<-------- TCP-ACK ---------+
|<-------- TCP-ACK ---------+ |
| | |
... ...
| | |
| |<----- TCP-DATA (A) -------+
|<----- TCP-DATA (A) -------+ |
| | |
+------ TCP-DATA (B) ------>| |
| +------ TCP-DATA (B) ------>|
| | |
... ...
Figure 1: Sequence: Direct routing
Rosenau Expires July 1, 2016 [Page 3]
Internet-Draft GlobalNAT64 December 2015
3.3. Indirect routing
If the ping response arrives at another NAT64 the first NAT64 cannot
establish a direct IPv4 connection to the TCP server. Instead the
IPv4 connection must be established using the NAT64 which received
the ping response.
NAT64 servers which are capable to use the shared addresses MUST be
capable to evaluate the content of the data in the ping response and
notify the other NAT64 about the indirect route to be taken using a
special data packet.
The packet sequence looks like this:
TCP Client NAT64 A NAT64 B TCP Server
| | | |
+---- TCP-SYN ----->| |
| +------------- Ping (IPv4) ------------>|
| | |
| | | |
| | |<--- Ping resp. ---+
| |<--- Route info ---+ |
| | | |
| +----- TCP-SYN ---->| |
| | (IPv6) +----- TCP-SYN ---->|
| | | (IPv4) |
| | | |
| | |<---- TCP-ACK -----+
| |<---- TCP-ACK -----+ (IPv4) |
|<---- TCP-ACK -----+ (IPv6) | |
| | | |
... ... ...
+-- TCP DATA (A) -->| | |
| +-- TCP DATA (A) -->| |
| | +-- TCP DATA (A) -->|
| | | |
| | |<-- TCP DATA (B) --+
| |<-- TCP DATA (B) --+ |
|<-- TCP DATA (B) --+ | |
| | | |
... ... ...
Figure 2: Sequence: Indirect routing
Rosenau Expires July 1, 2016 [Page 4]
Internet-Draft GlobalNAT64 December 2015
4. Packet definitions
4.1. Ping request
The ping request packet sent by a NAT64 has the following form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv4 header, Packet type = 1 (ICMP) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0/8) | Code (0) | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic value (ASCII "NT64") |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address of the first NAT64 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information for use by the first NAT64 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Ping request packet
Type: 8 bits
This field MUST have the value 8 in the packet sent to the IPv4
host and in the reply from the IPv4 host this field will be set to
0 according to RFC 792 [RFC0792].
Code: 8 bits
This field MUST have the value 0 according to RFC 792.
Checksum: 16 bits
Data check sum as described in RFC 792
Identifier and sequence number: 2x16 bits
According to RFC 792 these two fields are used to aid in matching
a ping response to a ping reply. The first NAT64 SHOULD put
individual, random numbers into these fields so the receiving
Rosenau Expires July 1, 2016 [Page 5]
Internet-Draft GlobalNAT64 December 2015
IPv4-only host does not drop the packet as "duplicate packet" when
receiving multiple ping requests.
Magic value: 32 bits
This field MUST contain the ASCII characters 'N', 'T', '6', '4'
(hexadecimal value 4E543634 in network byte order) so the second
NAT64 will detect an incoming ping reply as reply to a ping
request sent by another NAT64.
IPv6 address of the first NAT64: 128 bits
The IPv6 address of the NAT64 that has sent the ping request.
Information for use by the first NAT64: 64 bits
Information used by the first NAT64 to match the "ping response"
or the "route info" packet to a TCP connection. The meaning is
depending on the implementation of the first NAT64.
Options: variable
Information for the second NAT64. Currently no options are
defined. Therefore the field MUST be left empty (it must not be
present) and the second NAT64 MUST ignore the field if it is
present.
4.2. Route info
The route info packet is sent by the second NAT64 to the first NAT64
upon reception of a ping response packet and it has the following
form:
Rosenau Expires July 1, 2016 [Page 6]
Internet-Draft GlobalNAT64 December 2015
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 header and optionally other headers |
| Next header = 58 (ICMPv6) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic value (ASCII "NT64") |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address of the destination when routed |
| through the second NAT64 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address of the IPv4 host |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information for use by the first NAT64 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Route info packet
Type and Code: 2x8 bits
Type of the ICMPv6 message: "Route info" - to be defined.
Checksum: 16 bits
Data check sum as described in RFC 4443 [RFC4443]
Magic value: 32 bits
This field MUST contain the ASCII characters "NT64".
IPv6 address of the destination: 128 bits
The IPv6 address of the second NAT64 which is used to connect to
the IPv4 host. If the second NAT64 has the prefix
2001:db8:1:2::/64 and the IPv4 host has the address 10.3.4.5 the
IPv6 address is 2001:db8:1:2::10.3.4.5.
Address of the IPv4 host: 32 bits
Copy of the "source address" field in the IPv4 header of the ping
response packet.
Information for use by the first NAT64: 64 bits
Copy of the corresponding field in the ping response packet.
Rosenau Expires July 1, 2016 [Page 7]
Internet-Draft GlobalNAT64 December 2015
Options: variable
Information for the first NAT64. Currently no options are
defined. Therefore the field MUST be left empty (it must not be
present) and the first NAT64 MUST ignore the field if it is
present.
4.3. Route info error
The route info error packet is sent by the second NAT64 to the first
NAT64 on various kinds of errors and it has the following form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 header and optionally other headers |
| Next header = 58 (ICMPv6) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic value (ASCII "NT64") |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address from the pool |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address of the IPv4 host |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information for use by the first NAT64 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Route info error packet
Type and Code: 2x8 bits
Type of the ICMPv6 message; the following codes have to be
defined:
- IPv4 server not reachable
- NAT64 is busy - try again later
- Pool address is busy - take another pool address
Checksum: 16 bits
Data check sum as described in RFC 4443
Magic value: 32 bits
This field MUST contain the ASCII characters "NT64".
Rosenau Expires July 1, 2016 [Page 8]
Internet-Draft GlobalNAT64 December 2015
IPv4 address from the pool: 32 bits
Copy of the "destination address" field in the IPv4 header of the
ping response message.
Address of the IPv4 host: 32 bits
Copy of the "source address" field in the IPv4 header of the ping
response message.
Information for use by the first NAT64: 64 bits
Copy of the corresponding field in the ping response message.
Options: variable
Information for the first NAT64. Currently no options are
defined. Therefore the field MUST be left empty (it must not be
present) and the first NAT64 MUST ignore the field if it is
present.
The "IPv4 server not reachable" message is sent if the second NAT64
is not able to establish a TCP connection to the IPv4-only host at
all.
The "NAT64 is busy" message is sent if the second NAT64 does
currently have no free resources to establish a TCP connection; the
first NAT64 may try another IPv4 address to reach another NAT64
server.
The "Pool address is busy" message is sent if the second NAT64 can
establish a TCP connection but the source IPv4 address cannot be
used. In this case the first NAT64 may try another IPv4 address from
the address pool. This is necessary if the method described in
section "Address change and bad routing" (Section 5.1) is used.
5. Special scenarios
5.1. Address change and bad routing
Scenario:
A more powerful NAT will use a pool of multiple IPv4 addresses to
establish an IPv4 connection.
Let's say the address range XX.XX.0.0/16 is reserved for global
NAT64 routing. Packets from the IPv4 host will be routed to NAT64
B when the destination address is in the range XX.XX.1.0/8 and to
NAT64 C if the destination address is in the range XX.XX.2.0/8.
The NAT64 A (first NAT64) selects address XX.XX.1.1 as source
address of the ping message.
Rosenau Expires July 1, 2016 [Page 9]
Internet-Draft GlobalNAT64 December 2015
NAT64 B receives the response and tells NAT64 A that it is able to
route the TCP connection.
NAT64 A will now establish a TCP connection using NAT64 B and
NAT64 B selects one available IPv4 address from the address pool:
XX.XX.2.1.
The TCP connection will fail because address XX.XX.2.1 is routed
to NAT64 C instead of NAT64 B.
A solution would be to encode the address selected by NAT64 A into
the IPv6 address of NAT64 B: The NAT64 does not use a /96 prefix but
an /80 prefix - let's say 2001:db8:1:2::/80.
If a ping response is received with the destination address
XX.XX.nn.mm and the source address pp.qq.rr.ss the IPv6 address sent
to the NAT64 A will be 2001:db8:1:2::nnmm:ppqq:rrss.
When NAT64 B received a TCP-SYN packet to IPv6 address
2001:db8:1:2::nnmm:ppqq:rrss this means that NAT64 B should create a
TCP connection to address pp.qq.rr.ss using the address XX.XX.nn.mm
as source address.
When there are not enough TCP ports available on address XX.XX.nn.mm
then NAT64 B will send a "Pool address is busy" (Route info error)
message instead of a "Route info" message to NAT64 A as soon as the
ping response is received. In this case NAT64 A will select another
IPv4 source address from the pool XX.XX.0.0/16 and send a new ping
request.
5.2. Dual-stack host ICMP echo implementation
When the address range used for this method is well-known and the
IPv4 TCP server also supports IPv6 the destination host may answer
ping requests coming from NAT64s by "route info" packets instead of
ping replies. The "IPv6" field of the "route info" message is filled
with the IPv6 address of the TCP server.
Rosenau Expires July 1, 2016 [Page 10]
Internet-Draft GlobalNAT64 December 2015
TCP Client NAT64 A GlobalNAT64-capable NAT64 B
| | TCP Server |
| | | |
+--- TCP-SYN ---->| | |
| +--- Ping (IPv4) ---->| (Ping resp. |
| | +------- X ------>|
| |<---- Route info ----+ is not sent!) |
| | | |
| +-- TCP-SYN (IPv6) -->| |
| | | |
| |<-- TCP-ACK (IPv6) --+ |
| | |
|<--- TCP-ACK ----+ |
| | |
... ...
Figure 6: Sequence: Direct support by the server
5.3. Router caching
IPv4 and IPv6 packets are routed over the internet through routers.
A router detecting a ping request from a NAT64 router might directly
answer with a "routing info" packet when the corresponding second
NAT64 is known instead of routing the ping request to the receiver.
However there is the danger that this will work unstably beacause the
IPv4 routes may change. It would also not allow the
"GlobalNAT64-capable server" approach (Section 5.2).
5.4. Other protocols
This method may also work with UDP.
Port-less protocols such as GRP will probably not work.
Translating ICMP messages over NAT64 makes no sense.
6. References
6.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,
<http://www.rfc-editor.org/info/rfc2119>.
Rosenau Expires July 1, 2016 [Page 11]
Internet-Draft GlobalNAT64 December 2015
[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, <http://www.rfc-editor.org/info/rfc6146>.
6.2. Informational References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<http://www.rfc-editor.org/info/rfc792>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
Author's Address
Martin D. J. Rosenau
Email: martin@rosenau-ka.de
Rosenau Expires July 1, 2016 [Page 12]
