| Network Working Group | M. Rosenau |
| Internet-Draft | February 4, 2018 |
| Intended status: Experimental | |
| Expires: August 8, 2018 |
Anycast-based replacement for Teredo
draft-rosenau-anycast-teredo-00
Because of the shortage of remaining IPv4 addresses you have to expect that in a near time there will be IPv6-only services in the internet (such as web servers).
Because many internet service providers do not support IPv6, yet, there is the need of a reliable translation mechanism so customers only having access to IPv4 only can access IPv6 services.
This document describes a translation mechanism which is similar to the Teredo protocol. However this protocol is based on anycast addressing and should also work with symmetric NATs.
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 August 8, 2018.
Copyright (c) 2018 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.
Because of the IPv4 address shortage and of the fact that many ISPs do not or even cannot support IPv6 now there is the risk of the situation that some internet users will only have access to the IPv4 internet while a larger number of web servers and similar services is IPv6 only.
To work around this situation there should be a reliable translation mechanism for a transition period allowing IPv4 customers to access IPv6 services.
Unfortunately most translation mechanisms do not work for the majority of internet customers or they are either slow or unreliable.
This document describes a translation mechanism which is similar to the Teredo protocol but which has some advantages.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
A node having access to the IPv4 internet intending to transfer IPv6 datagrams using the translation mechanism described here
A node having access to the IPv6 internet but no access to the IPv4 internet
A node whose purpose is to forward IP (IPv4 or IPv6) datagrams from one node to another node
A router understanding the translation mechanism described in this document providing the actual translation between the IPv4 internet and the IPv6 internet
A translation router not using anycast addresses but fixed addresses
IPv6 datagrams are sent as payload of UDP datagrams.
IPv4 clients send these UDP datagrams to the next translation router which extracts the IPv6 datagram from the UDP datagram and forwards it to the next router.
The IPv6 address of the IPv4 clients is an anycast address; the IPv6 datagrams an IPv6 node sends to an IPv4 client will be sent to the next translation router. The translation router will encapsulate the IPv6 datagram into an UDP datagram.
Because the source address of the IPv4 datagrams sent to the IPv4 client is equal to the destination address of the IPv4 datagrams sent by the IPv4 client this method should also work with symmetric NATs.
The IPv6 address of an IPv4 client has the following format:
| 64 bits | 32 bits | 16 bits | 16 bits |
+---------------------------+-----------------+---------+---------+
| Prefix (anycast) | IPv4 address | Port | Zero |
+---------------------------+-----------------+---------+---------+
Figure 1: IPv6 address of a client
Because the link-local address is never used in any datagram using this translation method the IPv4 node can use any link-local address or even don't use a link-local address at all if the IPv6 implementation of the IPv4 node allows this.
IPv6 datagrams are simply transmitted as payload of the UDP datagram.
If the first 4 bits of the UDP payload are 0110 it is assumed that the UDP payload is an IPv6 datagram.
If the first bit (the highest bit of the first octet) of the UDP payload is 1 a "too long" answer is assumed.
A translation router sets this bit in a response to the IPv4 client to indicate that a UDP datagram was too long to be processed by the router.
If the first octet of the UDP payload sent by the IPv4 client is 1 an address query request is assumed.
Currently the UDP payload MUST not contain any other data (the payload must be exactly one octet long).
The translation router MUST ignore other data if the payload is longer than one octet.
The translation router will send an answer of 17 octets length: The first octet is 33 (decimal), the following 16 octets are the IPv6 address of the IPv4 client.
If the first octet of the UDP payload sent by the IPv4 client is 2 an echo request is assumed.
If the datagram is fragmented or if it is longer than the maximum supported length of an IPv6 datagram the translation router will send a "too long" reply.
If the size of the datagram is not too long the translation router will replace the first octet by the value 34 (decimal) and echo the resulting datagram back to the IPv4 client.
A translation router MAY accept fragmented IPv4 datagrams.
However for performance issues and because multiple fragments of the same datagram may be received by different routers (because of anycast addressing) a typical translation router will only accept unfragmented datagrams.
Such translation routers will discard all IPv4 datagrams not having the "fragment offset" field set to 0.
If an incomplete IPv4 datagram ("fragment offset" is 0 but the "more fragments" bit is set) is received the translation router will discard this datagram if the fragment payload is shorter than 12 octets (UDP header plus 4 bytes of UDP payload) or if the first bit of the UDP payload (uppermost bit of the first octet) is set.
Otherwise the router sets the first bit of the UDP payload, clears the "more fragments" bit, updates the "length" field in the UDP header and echoes the shortened UDP datagram back to the IPv4 client. The IPv4 client will then know the maximum datagram length which can be transmitted without fragmentation. The UDP packet sent to the IPv4 client may be fragmented if necessary.
If the UDP payload contains an IPv6 datagram the translation router SHOULD check if the source address of that datagram matches the real IPv6 address of the IPv4 client and if yes it sends that datagram to the IPv6 internet.
If the first octet of the UDP payload is 1 the translation router answers with the IPv6 address of the IPv4 client as described in the section "Address query".
If the first octet of the UDP payload is 2 the translation router replaces that first octet by the value 34 and echoes the datagram back to the IPv4 client
If the first octet of the UDP payload is neither 1 nor 2 and the payload does also not begin with 0110 (IPv6 datagram) the translation router behaves as if the datagram is too long: It sets the first bit and echoes the datagram to the IPv4 client.
If an IPv6 datagram is received the translation router encapsulates the IPv6 datagram into a UDP datagram and sends it to the IPv4 client. The UDP datagram may be fragmented if necessary.
The IPv4 client sends an "address query" request to to the anycast address.
It receives the answer from the translation router and knows its own IPv6 address.
Then the IPv4 client sends an "echo request" datagram (first octet of the UDP payload is 2) to the translation router whose size is as long as the maximum IPv6 datagram size allowed by the IPv6 implementation of the IPv4 client.
If the IPv4 client receives a response with the first octet of the UDP payload being 34 it knows that IPv6 datagrams of this length can be transmitted.
If the IPv4 client receives a shortened response with the first octet of the UDP payload being 130 it knows the maximum size of IPv6 datagrams it can transmit: The length of the response.
The IPv6 implementation of the IPv4 client MUST be able to deal with the fact that the maximum size of IPv6 datagrams that can be transmitted is much less than 1280. (In the case of TCP as upper-level protocol this can be done by limiting the TCP window size.)
To ensure that the NAT will not change the UDP port the IPv4 client will send "address query" datagrams in short time intervals to show the NAT that the "connection" is still alive. If no IPv6 connectivity is needed the IPv4 client does not send such datagrams; in this case it MUST send such a datagram before sending the next IPv6 packet again because the UDP port (and therefore the IPv6 address) has probably changed.
If an IPv4 client sends a datagram to another IPv4 client it will send the datagram the same way as if it is sent to an IPv6 node.
A translation router MUST detect this and encapsulate the payload of the UDP message received into another UDP message which is sent to the destination IPv4 client (instead of transmitting the IPv6 datagram as "real" IPv6 datagram).
The criteria for this case is that the destination address in the IPv6 datagram in the UDP payload matches the IPv6 address space the translation router will receive.
Note: This may be ignored if the translation router is able to send the IPv6 datagram extracted to itself!
This protocol requires one IPv4 anycast address. Because anycast addresses are only possible when using a /24 prefix a /24 prefix is required.
This protocol requires one /64 IPv6 anycast prefix. Because anycast prefixes are only possible when using a /48 prefix a /48 prefix is required.
The UDP port number should not be the same as used by Teredo because today many firewalls block Teredo.
In the IETF 95 meeting there was the discussion if IPv4 should be declared a "historic" protocol. This would mean that the IETF will not continue developing the IPv4 protocol.
Unfortunately reality shows that both internet service providers and device manufactures simply ignore IETF documents (such as RFC 6540) related to the transition from IPv4 to IPv6. Some internet service providers even stated that they will "never" introduce IPv6 but use IPv4 "forever".
The result is a vicious circle:
Unfortunately simply not switching from IPv4 to IPv6 in the internet is not a solution: In the RIPE 75 meeting it was reported that companies even did criminal offences (forging of documents) to get the IPv4 addresses needed.
To solve this problem the author of the document thinks that the following procedure would be successful:
(The author is not sure if the protocol described here meets these requirements.)
| [RFC0768] | Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980. |
| [RFC0791] | Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC2460] | Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998. |
| [RFC4291] | Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006. |
| [RFC4380] | Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006. |
| [RFC6540] | George, W., Donley, C., Liljenstolpe, C. and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, DOI 10.17487/RFC6540, April 2012. |