Internet DRAFT - draft-rosenau-anycast-teredo
draft-rosenau-anycast-teredo
Network Working Group M. Rosenau
Internet-Draft February 3, 2018
Intended status: Experimental
Expires: August 7, 2018
Anycast-based replacement for Teredo
draft-rosenau-anycast-teredo-00
Abstract
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 [RFC4380]. However this protocol is based on
anycast addressing and should also work with symmetric NATs.
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 August 7, 2018.
Copyright Notice
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
Rosenau Expires August 7, 2018 [Page 1]
Internet-Draft AnycastTeredo February 2018
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.
1. Introduction
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 [RFC4380] but which has some advantages.
2. Definitions
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] [RFC2119].
2.1. IPv4 client
A node having access to the IPv4 internet intending to transfer IPv6
datagrams using the translation mechanism described here
2.2. IPv6 node
A node having access to the IPv6 internet but no access to the IPv4
internet
2.3. router
A node whose purpose is to forward IP (IPv4 or IPv6) datagrams from
one node to another node
Rosenau Expires August 7, 2018 [Page 2]
Internet-Draft AnycastTeredo February 2018
2.4. translation router
A router understanding the translation mechanism described in this
document providing the actual translation between the IPv4 internet
and the IPv6 internet
2.5. translation server
A translation router not using anycast addresses but fixed addresses
3. Principle of operation
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.
4. Details of operation
4.1. IPv6 address of an IPv4 client
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
Prefix: 64 bits
The IPv6 address prefix used for the mechanism described here.
If the IPv4 client uses an translation server this is the IPv6
prefix (unicast) of the translation server.
However normally this is the anycast IPv6 prefix to the next
translation router.
IPv4 address: 32 bits
Rosenau Expires August 7, 2018 [Page 3]
Internet-Draft AnycastTeredo February 2018
This field is the IPv4 address of the IPv4 node.
If the IPv4 node is behind a NAT this is the "global" address of
the node. (The address seen from the internet, not the address
the node knows of itself.)
Port: 16 bits
The UDP port number used by the IPv4 node.
If the IPv4 node is behind a NAT this is the "global" port number
of the node.
Zero: 16 bits
MUST be zero when using an anycast IPv6 address; MAY be used by
translation servers.
4.2. Link-local IPv6 address
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.
4.3. Datagram formats
4.3.1. IPv6 datagrams
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.
4.3.2. "Too long" reply
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.
4.3.3. Address query
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).
Rosenau Expires August 7, 2018 [Page 4]
Internet-Draft AnycastTeredo February 2018
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.
4.3.4. Echo
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.
4.4. Translation router behaviour
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
Rosenau Expires August 7, 2018 [Page 5]
Internet-Draft AnycastTeredo February 2018
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" (Section 4.3.3).
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.
4.5. IPv4 client behaviour
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
Rosenau Expires August 7, 2018 [Page 6]
Internet-Draft AnycastTeredo February 2018
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.
4.6. Hairpinning
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!
5. IANA considerations
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.
6. Appendix: About the necessity of a translation method
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
[RFC6540]) related to the transition from IPv4 to IPv6. Some
internet service providers even stated that they will "never"
introduce IPv6 but use IPv4 "forever".
Rosenau Expires August 7, 2018 [Page 7]
Internet-Draft AnycastTeredo February 2018
The result is a vicious circle:
- Service providers (such as operators of web servers) cannot
provide IPv6-only services because most internet users do not have
access to IPv6-only services.
- Internet service providers do not introduce IPv6 because all
services (e.g. web servers) are accessible using IPv4.
- Service providers will not switch from IPv4-only to dual stack
because the customer's internet accesses are IPv4-only.
- Internet service providers have no reason to provide IPv6 to
their customers.
- ...
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:
- Introduction of some translation mechanism ...
* ... that is reliable
* ... that works behind NATs, CGNATs and symmetric NATs
* ... allowing nearly all "IPv4-only" internet users to ...
* ... access IPv6-only services
* ... without exchanging hardware like WLAN routers
* ... without any changes on the provider side
(The author is not sure if the protocol described here meets these
requirements.)
- Service providers (such as web server operators) can operate
their services IPv6-only because IPv4 is not needed to be
reachable from each client.
- Internet service providers will see a benefit in introducing
IPv6 because there is a noteworthy number of IPv6-only web servers
Rosenau Expires August 7, 2018 [Page 8]
Internet-Draft AnycastTeredo February 2018
and at least in the case of providers using CGNAT routing IPv4
packets (translation method) will be more complex (and expensive)
than routing IPv6 packets.
- As soon as most internet service providers support IPv6 the
support for routing of native IPv4 packets may be dropped on
larger internet exchange points and the translation mechanism may
be switched off.
7. References
7.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[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>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
7.2. Informational References
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<https://www.rfc-editor.org/info/rfc4380>.
[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,
<https://www.rfc-editor.org/info/rfc6540>.
Rosenau Expires August 7, 2018 [Page 9]
Internet-Draft AnycastTeredo February 2018
Author's Address
Martin D. J. Rosenau
Email: martin@rosenau-ka.de
Rosenau Expires August 7, 2018 [Page 10]
