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, . 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, . 6.2. Informational References [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [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, . Author's Address Martin D. J. Rosenau Email: martin@rosenau-ka.de Rosenau Expires July 1, 2016 [Page 12]