| Network Working Group | R. Van Rein |
| Internet-Draft | OpenFortress B.V. |
| Intended status: Informational | February 27, 2017 |
| Expires: August 31, 2017 |
6bed4: Peer-to-Peer IPv6 on Any Internetwork
draft-vanrein-6bed4-03
The purpose of 6bed4 is to support IPv6-only applications, even on IPv4-only networks. A specific and new [RFC7059] area of concern is that of peer-to-peer protocols such as SIP or file sharing during a chat session. Applications for such protocols are designed to run in arbitrary environments, which means that they can neither rely on native IPv6 for themselves, nor for their peers. The 6bed4 tunnel mechanism ensures that IPv6 can be assumed on all peers. This has a positive impact on the ability to initiate direct exchanges between such peers.
The 6bed4 mechanism is meant as a fallback mechanism for IPv6 connectivity on networks that do not support it natively, by running a tunnel over UDP and IPv4. The IPv4 address is used to support traceability of the traffic originator, which means that no user account or other configuration is needed.
The tunnel mechanism encapsulates IPv6 in UDP/IPv4 and builds on the existing IPv6 discovery mechanisms of Stateless Address Autoconfiguration [RFC4862] to setup an IPv6 address on a 6bed4 Peer, and of Neighbor Discovery [RFC4861] to verify if a direct route to a remote 6bed4 Peer is achievable.
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 August 31, 2017.
Copyright (c) 2017 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 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.
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 RFC 2119 [RFC2119].
A 6bed4 Frame is constructed from an IPv6 frame by embedding it into UDP and IPv4. In that form, it is transmitted over the Internet. The source IPv4 address and source UDP port together are referred to as the frame's Source 6bed4 Address; the destination IPv4 address and destination UDP port together are referred to as the frame's Destination 6bed4 Address.
This specification uses only two types of content for a 6bed4 Frame, namely an IPv6 frame and an RoHC packet. The distinction between these two content types can be made based on the first nibble of the content, which is 6 for IPv6 and either 14 or 15 for an RoHC packet. The purpose of an RoHC packet is either to update state information, or to convey a header-compressed IPv6 packet. The stream of 6bed4 Frames arriving at a destination filters through an RoHC decompressor and results in a stream of 6bed4 Frames containing IPv6 frames. A wide range of RoHC implementation complexity is supported, including trivial implementations. A surprising result of using RoHC is that RTP frames over 6bed4 are smaller than RTP frames over IPv4.
After the RoHC decompressor, the content of a 6bed4 Frame is always an IPv6 frame. Its source IPv6 address encodes the Source 6bed4 Address, and the destination IPv6 address encodes the Destination 6bed4 Address. In fact, there are two variants of each Destination 6bed4 Address depending on how the destination is reached, namely a Direct 6bed4 Address and a Fallback 6bed4 Address; both are included in the IPv6 addresses.
Since 6bed4 embedding supports general IPv6 traffic, it provides a well-defined form for carrying around ICMPv6 messages, including Neighbor Discovery messages. These are actively used to negotiate with 6bed4 Peers. Router Solicitation and Advertisement are used to determine a Public IPv6 Address; Neighbor Solicitation and Advertisement are used to test and confirm if a remote 6bed4 Peer can be reached at the Direct 6bed4 Address.
Router Advertisements in 6bed4 Frames announce /114 prefixes. This leaves 14 bits that can be used locally to distinguish hosts under the same prefix, possibly managed through static assignment and/or DHCPv6. Note that the completion with all zero bits indicates the router [RFC4291], or more precisely, the 6bed4 Server that is the sender of the Router Advertisement.
A 6bed4 Address is a concept that does not occur directly on the wire; it is a pair of an IPv4 address and a UDP port. This information may be binary represented as drawn below, showing the address followed by the port, each in network byte order.
Conceptual Representation of a 6bed4 Address:
+--------+--------+--------+--------+--------+--------+
| IPv4.H | IPv4.h | IPv4.l | IPv4.L | UDP.H | UDP.L |
+--------+--------+--------+--------+--------+--------+
8 8 8 8 8 8
In contrast with this pair, 6bed4-Prefixed Address actually occur on the wire. They contain at least a Fallback 6bed4 Address; furthermore, somewhat dependent on a few flags discussed below, this on-wire address usually holds a Direct 6bed4 Address as well.
In places where link-scoped addresses [RFC4291] are used, they look like a standard fe80::/10 prefix followed by zero-bit padding and ending in the six bytes IPv4.H, IPv4.h, IPv4.l, IPv4.L, UDP.H and UDP.L.
The representation of the Fallback 6bed4 Address relies on the knowledge that 6bed4 Servers run on the standard UDP port TBD2. This information is not mentioned in the 6bed4-Prefixed Address, but the IPv4 address is completely shown in the top 64 bits of the 6bed4-Prefixed Address. The part "Fallback 6bed4" in the figure below is filled with:
Assuming it is there, the representation of the Direct 6bed4 Address it goes into the lower half of the 6bed4-Prefixed Address, but it must respect the two bits of the EUI-64 interface identifier (Section 2.5.1 of [RFC4291]). The bits from the Direct 6bed4 Address that would otherwise be put in those bit positions are placed behind the rest of the Direct 6bed4 Address. The resulting bit sequence named "Direct 6bed4 Address" in the figure below is:
The last part of the 6bed4-Prefixed Address concerns the 14 bits that follow after the /114 prefix from the Router Advertisement. This part is left to the local 6bed4 endpoint to fill. As is standardised, the continuation with all zero bits is reserved (Section 2.6.1 of [RFC4291]) for the on-link address of the router that sent the prefix. This part is named "lanip" in the figure below.
Combining these fragments, the general format of a 6bed4-Prefixed address that can be embedded as 6bed4 is as follows:
6bed4-Prefixed IPv6 address format:
0 32 64 114 128 +-------+-------+-------+-------+-------+-------+-------+-------+ | TBD1 | Fallback 6bed4| Direct 6bed4 Address | lanip| +-------+-------+-------+-------+-------+-------+-------+-------+ <--------------------- /114 prefix ---------------------->
The well-known TBD1::/32 prefix is important; it enables routing software to recognise this format in IPv6 addresses, and suffices to support global routing to the 6bed4 endpoint specified in this format of IPv6 destination address. More on global routing follows in Section 7; for now, note how it takes a /32+32 Prefix to describe the route to a particular 6bed4 Server; however, when the IPv4 address of this server is contained in a /16 prefix it is possible to publish a /32+16 Prefix, which is rather common.
The prefix TBD1::/32 and port TBD2 are only reserved for a period of ten years, starting at the date of publication of this specification. Implementations that are aware of time MUST NOT implement 6bed4 after the final date; an extension of the final date is only possible through an updating RFC that at least passes through Expert Review for both allocated resources. The ten-year period was selected to support five years for new applications to roll out IPv6 and even IPv6-only applications to be built on top of 6bed4, and another five years for the use of 6bed4 to cease to exist and omnipresent, native IPv6 to replace it.
One special condition in a 6bed4-Prefixed Address can be treated as an invitation for Direct 6bed4 Connections, namely when the Fallback and Direct 6bed4 Address are the same. In terms of the address format, this means that the IPv4 addresses are the same, and that the UDP port in the Direct 6bed4 Address is the 6bed4 standard port TBD2.
6bed4 Peers can announce this form of IPv6 Address when they are able to receive 6bed4 Frames from anyone on their Direct 6bed4 Address; for this reason, this special format can be used to cause Direct 6bed4 Connections to this 6bed4-Prefixed Address; details are given in Section 8.4.
The 6bed4-Prefixed address format specifies that the Universal/Local bit is set to Local, and that the Individual/Group bit is set to Inidividual [IEEE-EUI64]. In the lower half of IPv6 addresses [RFC2372], both of these choices are represented with bit value 0.
Should a 6bed4-Prefixed Address set either or both these bits to 1, then this specification treats the entire bottom half of such remote peer addresses as an opaque bit array; local extensions to this specification are possible, but no interpretation is defined herein. If the bottom half is treated as an opaque bit array, a Direct 6bed4 Address MUST NOT be retrieved from the 6bed-Prefixed Address.
What remains in such situations is to address the Fallback 6bed4 Address when sending traffic. Effectively, this leaves the local interpretation of the bottom half of the 6bed4-Prefixed Address to the Fallback 6bed4 Server. This leaves room for various interpretations and (local) extensions without impairing routability.
One suggested extension is to support Stateless Address Autoconfiguration [RFC4862] on a local network segment, based on a 6bed4 Server that handles port TBD2 for a Public IPv4 address. Such extensions MUST suppress Public IPv6 Addresses specified as Local and Individual, which could arise from manually specified addresses or from privacy extensions [RFC4941]. Permitting such addresses to occur as Public IPv6 Addresses would be misinterpreted to contain a Direct 6bed4 Address, and would therefore lead to routing problems.
Another suggested extension is to support multicast destinations with a 6bed4-Prefixed Address that has the Individual/Group bit set to 1. The Fallback 6bed4 Server mentioned in the top half can forward traffic over sparse or dense multicast networks, based on local policy; one example local policy would route to all nodes on a locally connected network; another example local policy would route to all nodes that have explicitly subscribed to a particular multicast channel.
This specification does not refer to parts of the 6bed4 Infrastructure as tunnel clients and tunnel servers, but rather as 6bed4 Peers and 6bed4 Servers. This reflects the intention of making the endpoints, or peers, use Direct UDP/IPv4 Streams as their preferred transport for 6bed4 Connections.
The purposes of a 6bed4 Server are to provide information about the Public IPv6 Address to 6bed4 Peers, and to permit fallback to Fallback 6bed4 Streams as a transport mechanism between 6bed4 Peers for which Direct UDP/IPv4 Streams are not feasible. Finally, the 6bed4 Server is needed to connect a host that can only do 6bed4 to one that can only do Native IPv6 Addresses; precautions to avoid that situation wherever possible follow.
Every 6bed4 Peer is configured with the address of a Fallback 6bed4 Server. Given the strong pressure towards Direct UDP/IPv4 Streams, the traffic to a Fallback 6bed4 Server is very limited, and so offering this kind of service is considered very scalable.
To be reachable to the outside world on a Public IPv6 Address, a 6bed4 Peer sends a Router Solicitation to a 6bed4 Server, and receives a Router Advertisement with a /114 prefix in response. As shown in Section 2, the returned prefix includes both the Fallback and Direct 6bed4 Addresses, and leaves some room for local address assignment to serve a potential desire to route to a local network. It is then the local 6bed4 Peer's task to keep open the UDP/IPv4 Stream to the 6bed4 Server, so as to ensure that the IPv6 address remains constant. If it were to change, then the server would respond to sent traffic with a new Router Advertisement, offering a new /114 prefix and retracting the previous one. This leads to an address change, which is usually avoided by sending regular keepalive messages.
When initiating a new 6bed4 Connection, in other words when first contacting a remote 6bed4 Peer, it is also possible to send a Router Solicitation to the Fallback 6bed4 Address found in the remote 6bed4 Address. This results in an alternate 6bed4-Prefixed Address that can be setup locally for that contact attempt, avoiding trapezium-shaped routing between 6bed4 Peers. This specification ensures that this mechanism will always work, but a similar responsibility to keep this link to the remote 6bed4 Server open falls upon the local system.
Finally, for the most agressive approach towards peer-to-peer connections, it is even possible to send the Router Solicitation to the Direct 6bed4 Address of the targeted peer. Peers who intend to invite this method can ensure that the external port TBD1 leads directly to them, and then copy their Direct 6bed4 Address in the Fallback 6bed4 Address. This would bypass a Fallback 6bed4 Server and lead to true peer-to-peer connectivity. It should be noted that it is not safe in the most general case to only try the Direct 6bed4 Address if certainty of the connection is required; the Fallback 6bed4 Address is a necessary ingredient to achieve certainty. Using the same Direct and Fallback 6bed4 Adress in a 6bed4-Prefixed address indicates that the certainty exists that no separate Fallback server is needed.
At any time before or during communication with a 6bed4 Peer through a 6bed4 Server, it is possible to try using a Direct UDP/IPv4 Stream by sending a Neighbor Solicitation from a local Direct 6bed4 Address to the peer's Direct 6bed4 Address, and observing if it is matched by a Neighbor Advertisement over the opposite path. In this, "matched" means that it MUST be certain that the Neighbor Advertisement was not sent in response to a Neighbor Solicition that went out over another channel. Section 8 presents a few alternatives to this standard method.
When such direct requests lead to matching direct responses, then it is safe to assume that a Direct UDP/IPv4 Stream is possible between the 6bed4 Peers, at least for some time following. This is because UDP/IPv4 has worked in both directions, and the fact that it contained ICMPv6 cannot be inferred by the intermediate NAT routers or firewalls because the UDP header does not tag its contents. To ensure that this assumption continues to hold, firewalls and NAT routers MUST NOT interpret frames from and to the standard 6bed4 port TBD2 as 6bed4 Frames, but simply treat them as any other UDP traffic.
The knowledge that a remote 6bed4 Address can be reached over a certain UDP/IPv4 Stream MUST NOT be assumed to also apply to communication with any other IPv6 Address. This is vital, as it evades the trap of making inductive assumptions about the behaviour of NAT or firewalls. See Section 5 for details of the deductive approach of 6bed4 regarding regarding NAT and firewalls.
It is common for IPv6 hosts to have multiple IPv6 addresses, and so the question arises which local and remote addresses to use. This has been answered in [RFC6724]. In relation to 6bed4, native-to-native traffic MUST precede 6bed4-to-6bed4. In addition, 6bed4-to-6bed4 SHOULD be preferred over either native-to-6bed4 and 6bed4-to-native, because it is more desirable to use a Direct UDP/IPv4 Stream than a Fallback UDP/IPv4 Stream through a 6bed4 Server. Every 6bed4 Server is ultimately a shared resource and thereby a potential bottle neck for routing efficiency. This choice helps to offload 6bed4 Servers, and to improve their scalability.
In addition to this optimisation, higher-layer applications MAY also incorporate knowledge of 6bed4; for instance, a SIP endpoint [RFC3261] could observe a remote peer's 6bed4-Prefixed Address and offer media exchange over a 6bed4-Prefixed Address instead of a Native IPv6 Address, once more with the intention to offload the shared resource of a 6bed4 Server, as well as to lower roundtrip delays and jitter. Such a clever SIP server could even aim to construct a more optimal 6bed4-Prefixed Address for the connection using the techniques mentioned in Section 8.7.
There is a wide variety of NAT router implementations, usually with subtly different characteristics. A similar thing applies to firewalls. This means that any approach to peering through NAT and firewalls that is to work everywhere must be founded on deductive reasoning-from-facts, and not induce information from an incomplete survey of NAT routers and firewalls. Specifically, STUN [RFC3489] used to make such inductions which were later relativated (Section 14.3 [RFC5389]). An IPv6 tunneling mechanism based on this work [RFC4380] has indeed shown to not work in general [POTAROO].
Network components that alter the contents of UDP frames have been reported [RFC4380] but are downright broken. They may need to be replaced before 6bed4 can function.
This specification assumes that outgoing UDP is supported. There are places where dramatically constrained Internet connectivity is offered, but this is not what constitutes Internet according to the IETF. To mend such hacked networks, equally hacked approaches may be built in extension to this specification, such as a fallback to TCP, or perhaps even WebSockets [RFC6455]. This specification does not detail such alternatives.
Except for local keepalive timing, nothing in 6bed4 makes assumptions about the behaviour of NAT beyond basic support for UDP in general. Specifically, there is no dependency on a behavioural classification of NAT routers or firewalls. Instead, 6bed4 simply tries if IPv6 traffic between peers is possible by sending a frame directly to a peer and matching it with a return frame. In case of success, it is assumed that bidirectional direct peering is possible.
6bed4 Connections are carried over an UDP/IPv4 stream, and UDP has no content tagging, so a NAT router cannot treat this test exchange in any way different from "normal" UDP traffic.
When sending UDP out through a NAT router, it will usually substitute the source IPv4 address and UDP port with an external IPv4 address and UDP port. For UDP protocols to behave normally in the presence of this translation, the NAT implementation is held to apply the same substitution when future frames are sent over the same UDP/IPv4 Stream, so a sustained mapping between internal and external IPv4 address and UDP port can safely be assumed.
To find an entry in this mapping, the NAT router can select values from the source and destination IPv4 addresses and UDP ports, but as long as all these values match, the same UDP/IPv4 stream is recognised and the same mapping must be applied. There is no implementation freedom here; the opposite substitution is the only way to support UDP in general.
Firewalls have a similar mapping, albeit not for substituting an address and port, but to recognise if traffic has been sent out over a UDP/IPv4 stream. Other than this difference, it generally behaves under the same constraints as a mapping in a NAT router.
To handle all mappings that are possible, 6bed4 makes no assumption about sharing the same mapping for different UDP/IPv4 Streams; a Public IPv4 Address and UDP Port may be the same for two remote peers, or they may differ. As far as 6bed4 concerns, they may be separately administered mappings. And if they happen to overlap then it is still safe to treat them separately, as the protocol components are idempotent.
UDP has no formal end marker for a UDP/IPv4 Stream, and it is not common in middle boxes to poll locally if the connection is still open, so the common approach in routers is to guess when a stream has ended. It is assumed by this specification that a mapping is kept active for a minimum time, and revived at least when traffic is sent out along the stream, as that is the only thing on which an implementation can base such revivals without making UDP insecure. To overcome timeouts on such mappings, a keepalive mechanism is needed in a number of places, and the timer triggering that mechanism must be a setting that the end user can influence. Experiments [RFC4380] have shown that a default setting of 30 seconds is quite likely to work. To avoid being presumptious, implementations SHOULD permit user configuration of this timeout value.
Timeouts are related to the local network infrastructure, so the local 6bed4 Peer is the proper place for making such settings. It is also possible for these local settings to include a TTL for the keepalive messages; there is no need for keepalives to reach the remote endpoint, but rather these messages should get past all the local middle boxes and out on the public Internet, in order to keep an UDP/IPv4 Stream open.
Any tunnel should guard against being abused for claims on addresses "inside" the tunnel based on "outside" clients that should not be able to make such claims. In the case of 6bed4, this means that the 6bed4 Address from which a 6bed4 Frame arrives must match with the Sender IPv6 Address.
When a filter rejects a 6bed4 Frame on account of a mismatch between the Source 6bed4 Address and the suggested IPv6 address, it should respond with a Router Advertisement that retracts the /114 prefix used in the IPv6 address, and offers a new /114 prefix that would have matched to replace it.
Both 6bed4 Servers and 6bed4 Peers MUST silently discard any 6bed4-embedded frame that is neither a proper IPv6 message nor an RoHC-compressed packet; example conditions to implement that would be:
If the recipient is a 6bed4 Server, then the Source 6bed4 Address of an acceptable 6bed4 Frame MUST match one of the following:
Note that 6bed4 Frames may occasionally travel through a router announced for TBD1::/32 but not when they are sent from a 6bed4-Prefixed Address, in which case it would have been forwarded to a 6bed4 Address.
If the recipient is a 6bed4 Peer, then the Source 6bed4 Address of an acceptable 6bed4 Frame MUST match one of the following:
In addition, the Destination 6bed4 Address of an acceptable 6bed4 Frame MUST match the following:
Finally, the destination IPv6 address SHOULD be assigned by the 6bed4 Server set as the Fallback 6bed4 Address as part of the destination IPv6 address.
The situations in which a Direct 6bed4 Address cannot be retrieved are specified in Section 3.2.
A 6bed4 Server MAY apply additional filtering to limit its use to a particular subset of 6bed4 Peers; for instance, the users of an ISP or a commercial 6bed4 service. To this end, it would ensure that 6bed4 Frames are passed either from or to a Direct 6bed4 Address that is accepted. This MUST NOT be done on a 6bed4 Server that announces routability for the TBD1::/32 prefix.
The only messages exempted from all aforementioned filtering are Router Solicitation frames targeting a link-local IPv6 address, and having their IPv6 Hop Limit set to 255. Those messages receive a Router Advertisement frame in reply, containing the /114 prefix that matches the 6bed4 Address of the originator of the solicitation. Even a limited-access 6bed4 Server MUST welcome Router Solicitation from unaffiliated peers that intend to avoid trapezium-shaped routing.
In backbone networks, IPv6 connectivity providers exchange routes through the Border Gateway Protocol (BGP). There is no standard for prefix lengths to support in BGP, so everyone makes their own filtering rules. In practice [TODO:xref target="https://labs.ripe.net/Members/dbayer/visibility-of-prefix-lengths"] however, a /48 is a widely supported length, unlike anything that is longer. The small percentage that does not support the /48 is usually capable of routing through a covering /32 IPv6 prefix. The prudent approach to global routeability appears to be the combination of a /32+16 with a covering /32+0 prefix.
To advertise routing over an IPv4 range one MUST own it, so the announcement of a /32+16 Prefix is only possible for a 6bed4 Address that falls in a /16 prefix that is owned by the autonomous system that runs (or otherwise supports) the 6bed4 Server. An exception is made for the /32+0 Prefix, which serves as a fallback routing facility. This fallback range can be used as anycast, so this MAY be announced by any party implementing a 6bed4 Server. What this means is that control over return traffic is only possible through announcement of the /32+16 Prefix, with a minute portion of the Internet still routing it through the /32+0 Prefix announcement.
Anyone announcing a /32+16 Prefix MAY also announce the /32+0 Prefix, which is TBD1::/32 itself. Anyone announcing the /32+0 Prefix MUST respond to all 6bed4 traffic targeted at 6bed4 Server addresses outside locally administered IPv4 ranges by relaying such traffic to a suitable IPv6 router; to that end, it MUST endeavour to collect all routing announcements for /32+16 Prefixes.
Announced /32+16 Prefixes SHOULD be retracted during downtime of the 6bed4 service; announced /32 Prefixes MUST be retracted during downtime of the 6bed4 service. It is advised to relay routing messages that establish these routes through the 6bed4 service, to the effect that service downtime implies route announcement retraction. This would not normally interfere with intentions to setup redundant 6bed4 service.
Given the availability of /32+0 announcements, as an anycast service, it is possible for any node with a single IPv4 address and access to the 6bed4 port TBD2 to offer 6bed4 service. The quality level of this service may be lower due to the dependency on the anycast range for more than just fallback routing. Having said that, it does enable a model where an endpoint can run a 6bed4 service to cover a local network. In this case it is possible to use the local numbering scheme, as long as the respective bit in the EUI-64 address are set appropriately.
An explicit design goal of 6bed4 is to exploit Direct UDP/IPv4 Streams between 6bed4 Peers. This is achieved by simply trying an exchange over UDP/IPv4 and relying on the uninterpreted transport of UDP payloads to infer that the entire UDP/IPv4 stream must be possible if a single exchange works bidirectionally.
It is vital for this mechanism that UDP/IPv4 Streams follow the same path in both directions, at least inasfar as it passes through local middle boxes. In practice, this is a fair assumption to make, because it is generally safe to assume that outgoing traffic in a UDP/IPv4 Stream keeps NAT router and firewalls open for return traffic. To ensure this, a 6bed4 Peer that receives direct traffic from a remote peer that it would address through a 6bed4 Server MUST start one of the following methods to attempt to setup direct peering. In such cases, it SHOULD not give up before it has tried the Neighbor Discovery method, which is the only obliged method, but it MAY try other methods as well.
The one thing left to specify is how peering is initiated. This is done by one of the following methods to setup direct peering, applied opportunistically. This can basically be done at any time deemed fitting, but it is suggested to employ some form of rate limiting for opportunistic peering attempts. A few useful places to do this would be to send a Router Advertisement to a direct 6bed4 Address before sending it to its general 6bed4 Address; or to send Neighbor Discovery sometime during the normal exchange; or to do it during the setup of a TCP/IPv6 stream.
The following subsections introduce a general framework for trying to setup direct peering. It continues with a few concrete examples, some of which must be implemented with 6bed4. There are certainly opportunities for other specific implementations of the general opportunistic mechanism.
The abstract concept of direct peering rests on sending a message directly to a Direct 6bed4 Peer, in an attempt to establish bidirectional contact. The "official" version is to create a dedicated message exchange for this purpose, but many protocols could support the "trick" of trying a first message towards the Direct 6bed4 Address and, if this fails and higher-layer protocols decide to resend, to continue the exchange through the Fallback 6bed4 Address. The latter approach is a slight abuse of the known-lossy nature of networks.
The abstract framework must be able to relate an incoming direct reply to a previously sent direct request, and distinguish it from requests sent through the Fallback 6bed4 Address. This can be established with a nonce if a frame is generated specifically for the purposes of 6bed4 Peer detection; or if a higher protocol layer generates the message, then the time between the first send and a later re-send is the window during which the direct response is considered a reliable sign of bidirectional traffic.
One mechanism that MUST be implemented in all 6bed4 Peers is that of peering setup through Neighbor Discovery. This involves a Neighbor Solictation generated by the 6bed4 Peer over a Direct UDP/IPv4 Stream, and receiving a reply in the form of a Neighbor Advertisement. This is the standard reachability detection mechanism for IPv6. The usual ICMPv6 requirement of a Hop Limit equal to 255 applies here, and is not invalidated by the multiple hops made in the underlying UDP/IPv4 transport.
In order to ensure that a response matches a request sent directly, as well as to thwart attemts to overtake traffic, a nonce following [RFC6496] MUST be sent as part of the Neighbor Solicitation. A 6bed4 Peer MUST respond to Neighbor Solicitation with Hop Limit 255 and its own address information as destination with a Neighbor Advertisement with Hop Limit 255, and it MUST include any nonce it found in the Neighbor Solicitation.
A 6bed4 Peer wanting to initiate a Direct 6bed4 Connection may use this mechanism at any time; it is safe because it does not interfere with the actual data stream between the peers. These internally generated Neighbor Discovery messages SHOULD NOT be sent via the 6bed4 Server. Only when a direct Neighbor Solicitation results in a Neighbor Advertisement with the same nonce may the originator of the exchange conclude that a Direct 6bed4 Connection can be used. The remote peer MUST NOT draw that conclusion from the same exchange, as it cannot be sure if the direct Neighbor Advertisement arrived. Also in the interest of security, it should initiate its own exchange because it sees the presumably successful exchange as a hint that a Direct UDP/IPv4 is feasible.
Another mechanism that SHOULD be implemented in 6bed4 Peers, and that MUST be implemented in 6bed4 Servers, is responding to Router Discovery messages with the Hop Limit set to 255. The response must be a Router Solicitation composed of the /114 prefix formed as defined in Section 3; the Fallback 6bed4 Address refers to the 6bed4 Server for the address, the Direct 6bed4 Address holds to the observed UDP port and IPv4 address of the sender of the Router Discovery message. Any nonces included in the Router Discovery MUST be replicated in the Router Solicitation. Furthermore, a 6bed4 Peer MUST include a nonce if it sends out a Router Discovery message.
The simplest possible form of opportunistic direct routing is when the 6bed4-Prefixed address of a remote peer has the same values set as its Fallback and Direct 6bed4 Address. This means that the opportunistic route can be tried immediately, as the 6bed4 Server function requires accessibility over the standard UDP port TBD2 that is apparently also in use for Direct 6bed4 Connections.
Note that it is usually necessary to obtain a 6bed4-Prefixed Address to use for communication with such a party, so if no local IPv6 address with the same /64 as the remote peer's IPv6 address exists, then one should be requested from the remote peer through Router Solicitation. This will inform the local peer how its public address looks to the inviting peer.
This mechanism MAY be incorporated into 6bed4 implementations that run TCP over 6bed4. It piggy-backs on the SYN and ACK flags exchanged while setting up a TCP connection to a remote 6bed4 Peer, and introduces peering opportunistically and, quite possibly, without any exchanges with a 6bed4 Server for setting it up.
TCP-based peering is based on the SYN flag sent initially by a new TCP connection being setup, and the ACK flag sent to acknowledge it. Furthermore, it assumes that the TCP stack wil resend a failed first SYN attempt.
Under this opportunistic scheme for direct route discovery, the first SYN sent to a remote 6bed4 Peer would be sent to the Direct 6bed4 Address of the remote peer; if it reports back with the ACK flag set, then a direct connection was clearly possible. If this response does not arrive before the TCP-stack re-sends the SYN fame, then this and further attempts are sent to the Fallback 6bed4 Address, until further inspiration triggers another attempt at direct peering.
The endpoint information in TCP as well as window offsets are used to recognise the SYN attempt, and later pairing the ACK to it. This means that the conditions are available to establish with certainty that a direct request has been answered with a direct response.
Note that this mechanism works in both directions; as the passive side sends an ACK responds to a SYN request, it usually sends its own SYN flag in hope of an ACK back from the active side. This second exchange can follow the same rules to detect bidirectional connectivity from the other side. Sending that first ACK along with the second SYN also means that a first attempt is made from the passive side to establish direct peering. Receiving the second ACK on the passive side over a direct connection before resending the second SYN through the Fallback 6bed4 Address indicates to the passive side that it can use a Direct UDP/IPv4 Stream.
This facility is useful for servers that have configured their NAT and Firewalls to open a UDP port, so any direct contact attempts are certain to succeed. This can then be used to construct a fixed 6bed4 Address, which would be suitable for publication in DNS, perhaps as an alternative to a Native IPv6 Address.
The Opportunistic Peering method for SCTP [RFC4960] is a variation on the method for TCP. Note that SCTP does not have its usual acceptance problems when used between 6bed4 Peers, because 6bed4 traffic is largely unfiltered and tunnels through the NAT routers that currently tend to block this protocol.
SCTP follows an association initiation protocol with four frames instead of the three of TCP. The last two may carry data chunks, but this would be stored in a separate chunk, giving the network layer some freedom to manipulate the frames if desired.
The advantage of four messages over three is that the first chunk (INIT) can be sent first to the Direct 6bed4 Address, then to the Fallback 6bed4 Address of the remote peer, which can then assume that outgoing UDP traffic has opened a hole in NAT and Firewalls. This means that the chances of entry for a reply message are optimal. Therefore, the opportunistic method for SCTP relies not on the first, but on the second to fourth messages for association initiation.
The INIT-ACK chunk counts as an opportunistic attempt from the remote to the local peer when it arrives over the Direct UDP/IPv4 Stream; the COOKIE chunk sent over the Direct UDP/IPv4 stream signals acceptance to the remote peer and is at the same time an opportunistic attempt from the local peer to the remote; the COOKIE ECHO chunk sent over the Direct UDP/IPv4 Stream signals acceptance to the local peer.
In short, new SCTP associations can send the first attempt of each of the chunks for association initiation to the Direct 6bed4 Address of a peer. With the exception of INIT, the arrival of a chunk over the Fallback UDP/IPv4 Stream indicates that the SCTP association must continue through the 6bed4 Server.
Another example of opportunistic peering that can be advantageous for a specific application is SIP [RFC3261]. A SIP exchange consists of a request and one or more responses. The application software is well aware of the distinction between those, and can prove useful to facilitate 6bed4 peering if it integrates with the network layers.
SIP messages, when sent over UDP, are prone to resends if a response is not received for some time. As a result, it is possible to first attempt sending to the remote peer's Direct 6bed4 Address, and send later retries to the Fallback 6bed4 Address. As with TCP, it is possible to treat as proof of direct peering any incoming direct responses between the intial request and its re-sends through the Fallback 6bed4 Address.
The link between a SIP request and its response is easily made with the identifying parts of the message; these are embedded in text and would thus work best when the application integrates 6bed4 and this opportunistic method for direct peering. The message-identifying parts are contained in the Call-ID header, the From header tag and optional To header tag. In addition, the top Via header contains a branch parameter that identifies the exchange. All this is the knowledge domain of the application, and embedding it into 6bed4 tunneling code would undermine the separation of network layers. What this indicates however, is that an API between the 6bed4 stack and the application layer can provide new benefits.
The RoHC framework [RFC3095] makes use of repetitive and predictable patterns in headers to achieve header compression, and defines a robust protocol to agree on the possibilities for doing so. At least two possible applications of 6bed4 make this compression desirable, namely a peer-to-peer carrier for RTP flows and a tunneling mechanism to gain access to IPv6 over mobile networks. In support of these and other applications, 6bed4 incorporates support for RoHC between peers. It does however acknowledge the possibility of a minimal implementation that understands just enough of RoHC to reliably reject it. Requiring at least this minimal implementations means that negotiation of RoHC can be attempted between peers without loss of robustness.
The RoHC specification allows a number of predefined values for various settings. These will not be negotiated by 6bed4, but are defined here for the general tunneling application. Specific applications that embed the logic of 6bed4 for their own purposes have full control over both endpoints of a 6bed4 Connection and MAY therefore override these default choices.
RoHC can be very useful between 6bed4 Peers. On a 6bed4 Server, the use of RoHC on the encapsulated IPv6 header would imply keeping state, which counters the stateless design intentions of the 6bed4 Server. For this reason, this specification only allows sending RoHC traffic to a 6bed4 Peer, and permits a 6bed4 Server to drop all RoHC traffic without further notice.
The constraints on 6bed4 Peers and 6bed4 Servers for RoHC handling are detailed in Section Section 10; their definition is such that traffic to a 6bed4 Peer may be compressed with RoHC, but when a new profile is introduced the receiving side may reject it through negative feedback. This is interpreted as lack of support for that profile, and (robustly) avoids compression according to that particular profile.
Future specifications, as well as local uses of this specification may choose to overrule any of these definitions as long as it does not impair the robustness of RoHC; it is for example possible to use large CIDs or to equip a 6bed4 Server with RoHC capabilities; to name just one special use case, changes like these might prove useful on cellular links and other dedicated service channels.
This section describes minimum requirements for 6bed4 Servers and 6bed4 Peers.
A 6bed4 Server MUST respond to well-formed Router Solicitations from any 6bed4 Peer, including non-local and non-member requests, by advertising the /114 prefix that starts with the well-known prefix TBD1::/32, followed by its own 6bed4 Address in the position of the Fallback 6bed4 Address, and the requesting 6bed4 Address as the Direct 6bed4 Address. The 6bed4 Server MUST know its own 6bed4 Address as a combination of a configured public IPv4 address and the UDP port TBD2 and it MUST be reachable for anyone at the resulting 6bed4 Address.
A 6bed4 Server MUST filter incoming 6bed4 Frames as specified in Section 6. When a 6bed4 Frame is rejected on account of its Source 6bed4 Address, then the same Router Advertisement MUST be sent in response, with the added requirement that the falsely assumed /114 prefix from the source IPv6 address is retracted.
When responding to Neighbor Solicitation or Router Solicitation, a 6bed4 Server MUST copy any nonce and timing information from the request into the response.
A 6bed4 Server MAY publish Prefixes of its IPv6 address with lengths between /32+0 and /32+16 through the Border Gateway Protocol (BGP) with at least the 6bed4 Address that it assigns in Router Advertisements as the Fallback 6bed4 Address, and MAY be published in BGP with a larger prefix. The 6bed4 Server MUST receive all native IPv6 traffic sent to this published prefix.
A 6bed4 Server SHOULD forward IPv6 frames sent over native IPv6 routing to 6bed4-Prefixed Addresses after embedding them in a 6bed4 Frame; the Destination 6bed4 Address is the Direct 6bed4 Address if the Fallback 6bed4 Address matches the server's 6bed4 Address, or otherwise the Destination 6bed4 Address is the Fallback 6bed4 Address.
A 6bed4 Server SHOULD forward 6bed4 Frames destined for IPv6 Addresses that do not fall under the TBD1::/32 prefix. This is done by unpacking the 6bed4 Frames, or in other words, by removing the UDP and IPv4 headers, and using native IPv6 routing for the submission of the unpacked frame.
A 6bed4 Server SHOULD forward 6bed4 Frames destined for a 6bed4-Prefixed Address to the next hop 6bed4 Address. If the destination IPv6 Address holds the 6bed4 Server's address as the Fallback 6bed4 Address, then the next hop is the Direct 6bed4 Address found in the destination IPv6 address. Otherwise, the next hop is the Fallback 6bed4 Address found in the destination IPv6 address.
The "SHOULD" conformance level in the last three paragraphs is a conscious limitation of the service, in support for commercial 6bed4 offerings that may want to limit their service offering to customers. However, if the 6bed4 Server announces router one or more prefixes of at least 32 bits valued TBD1, then any IPv6 Frames whois source or destination IPv6 Address matches any of these announced prefixes MUST be forwarded as described by the last three paragraphs.
A 6bed4 Server MAY discard 6bed4-embedded RoHC packets, which can be recognised by their first nibble value being 14 or 15, instead of 6 for a plain IPv6 frame. When dropping RoHC packets, a 6bed4 Server MUST NOT send 6bed4-embedded RoHC packets either. When processing RoHC packets, the 6bed4 Server MUST behave in the same way as a 6bed4 Peer, and respect the rules of Section Section 9.
A 6bed4 Peer SHOULD respond to well-formed Router Solicitations from any 6bed4 Peer, and to invalid incoming 6bed4 Frames from any source with a Router Advertisement, by advertising the /114 prefix that starts with the well-known prefix TBD1::/32, followed by its own 6bed4 Address in the position of the Fallback 6bed4 Address, and the requesting 6bed4 Address as the Direct 6bed4 Address. The 6bed4 Peer may obtain its own 6bed4 Address from the Destination 6bed4 Address of the incoming 6bed4 Frame.
A 6bed4 Peer MUST filter incoming 6bed4 Frames as specified in Section 6. When a 6bed4 Frame is rejected on account of its Source 6bed4 Address, then the same Router Advertisement MUST be sent in response, with the added requirement that the falsely assumed /114 prefix from the source IPv6 address is retracted.
When setting up a 6bed4 Connection to a remote 6bed4 Address, a 6bed4 Peer SHOULD prefer any address for the local side of the 6bed4 Connection that starts with the same /64 prefix as the remote 6bed4 Peer's. If no such address is available locally, it is RECOMMENDED to acquire one by sending a Router Solicitation to the remote peer's Fallback and/or Direct 6bed4 Address.
When communicating over a 6bed4 Connection, it is RECOMMENDED that a 6bed4 Peer attempts to setup a Direct 6bed4 Connection according to the Opportunistic Peering procedures described in Section 8. The minimum implementation required is based on Neighbor Solicitation, as specified in Section 8.2.
A 6bed4 Peer MUST respond to received Neighbor Solicitation messages with Neighbor Discovery messages, to implement Opportunistic Peering as specified in Section 8.2. It MAY also respond to other mechanisms for Opportunistic Peering as specified in the other sub-sections of Section 8.
When receiving 6bed4 Frames over a Direct 6bed4 Connection while not being setup to perform direct 6bed4 Peering to the Source 6bed4 Address, a 6bed4 Peer MUST work towards Opportunistic Peering, and Neighbor Solicitation MUST be one of the opportunistic mechanisms tried before considering failure. If attempts towards Opportunistic Peering are already in motion for the same remote 6bed4 Peer, then its result may be awaited first. If attempts towards Opportunistic Peering have recently been shown to fail, then the attempt MAY be foregone.
A 6bed4 Peer SHOULD send a nonce and timing information [RFC6496] in any sent Neighbor Solicitation and Router Solicitation.
When responding to Neighbor Solicitation or Router Solicitation, a 6bed4 Peer MUST copy any nonce and timing information from the request into the response.
A 6bed4 Peer SHOULD send keepalive frames to keep the UDP/IPv4 Stream open for active 6bed4 Connections. A keepalive frame MAY be a valid IPv6 frame, or it may be an empty message embedded in UDP and IPv4 as would have been done for an IPv6 frame. It MAY be sent with an IPv4 Time To Live that is so low that the keepalive frame just makes it to the public Internet, after having crossed local NAT routers and firewalls. The timing interval of a keepalive frame SHOULD be a user setting, and it MAY by default be set to a safe low value of 30 seconds.
When received over a Direct 6bed4 Connection, a 6bed4 Peer MUST accept 6bed4 Frames with initial nibble values 14 and 15. It must process them as RoHC packets, adhering to the rules in Section Section 9. In case of an IR packet that mentions an unsupported profile number, it MUST respond with a STATIC-NACK; note that it is permitted for an implementation to support no profile numbers at all, and send a STATIC-NACK in response to all IR packets. Compressed RoHC packets that arrive under supported profiles are reconstructed into 6bed4 Frames and are then treated like freshly arrived 6bed4 Frames that had not been compressed.
A 6bed4 Peer MAY attempt RoHC compression over Direct 6bed4 Connections. It may introduce any profile number that it wants, but should be prepared to deal with (repeated) STATIC-NACK on an IR packet to indicate that the recipient is not able to engage in that profile. If this happens, the sender SHOULD back off temporarily or definately for the given 6bed4 Connection and/or the remote 6bed4 Address. To limit loss of 6bed4 Frames caused by IR packet rejections, a 6bed4 Peers SHOULD NOT include a payload with an IR packet.
A 6bed4 Peer SHOULD deliver any 6bed4 Frame by unwrapping it (meaning, removing the IPv4 and UDP headers) and locally process the contained IPv6 frame, and it should accept local IPv6 frames originating at one of its local 6bed4-Prefixed Addresses, and wrap it into UDP and IPv4 to send to the destination, either to the Direct or Fallback 6bed4 Address contained in the IPv6 destination address.
One potential implementation of a 6bed4 tunnel interface would exploit the Neighbor Cache in an IPv6 host to facilitate storage and timing of the various neighboring relationships. Indeed, the timeouts of such relations are generally shorter than NAT mapping timeouts. It should however be noted that not all Neighbor Caches are designed for large-scale operation, and that an active host could choke on that. Furthermore, there is no keepalive mechanism built into such neighbor caches, which means that one or more peering relations could loose their address when no traffic is exchanged for some time.
For ISPs that do not provide 6bed4, there is no problem to reach out to more distant 6bed4 service providers. It is even thinkable that such a third-party service would be offered on a commercial basis, and that payload traffic through the service would only be handled when it either passes to or from a customer's registered address (range). Such a service provider obviously should not announce that it can route the TBD1::/32 prefix.
Although this specification speaks only of UDP as a transport for 6bed4, it is possible to add TCP as a fallback protocol if the code of the 6bed4 Peer and 6bed4 Server agree to that. Although SCTP would be more suitable, it would be uncommon to find a situation where that is present and UDP is not. What is common is that UDP is banned while TCP is not. Such cases could benefit from a fallback to TCP. The format of the messages exchanged would be precisely the same, except that the transmission happens to be ordered and guaranteed. As one more option to cator to failed Internet installations, one could even consider supporting TCP over port 80 or 443 instead of the standard port. In all cases, the 6bed4 Server may now need be hold state for all connected 6bed4 Peers, and choose whether to contact them over TCP or over UDP. This can be remedied in various ways, including differentiation between different kinds of 6bed4 Peers through the 6bed4 Address of the server. This specification does not prescribe how non-UDP transports could be used and generally leaves it to local protocol extensions.
Another option based on protocol extensions to which 6bed4 Server and 6bed4 Peer could agree, is to apply encryption to the information exchanged. Such facilities are not part of this specification.
A few situations call for coordination between 6bed4 Infrastructure components. This will take place under the domain name 6bed4.net for as long as the TBD1::/32 prefix and the TBD2 port are allocated for 6bed4. The precise methods are not detailed here because it does not concern the core communication protocols of the 6bed4 tunneling mechanism. One thing coordinated under 6bed4.net is an service where Autonomous Systems that announce TBD1::/32 routing must register all IPv4 addresses of 6bed4 Servers that could pass on 6bed4 traffic to a machine with a longer prefix that did not make it through to all parts of the Internet.
This specification reserves a 32-bit address prefix TBD1::/32 in the IPv6 address space assigned to the IANA IPv6 Special-Purpose Address Registry. The prefix will be exclusively used for 6bed4 addresses, and further assigned as defined in Section 3. Addresses under this prefix can be used as source and destination addresses, as they are globally routable. The termination date for the allocation falls ten years after the publication date of this specification in the Request For Comments series; future standardisation work could modify the end date if this is considered useful.
This specification also reserves Port TBD2 from the pool of UDP ports and from the pool of TCP ports for the same period of ten years, starting from the date of publication of this specification, also subject to possible updates by future specifications.
The port TBD2 will be the port on which 6bed4 Servers provide their services. These servers form a public resource, and remote peers have no mechanism other than the standardised port to know how to contact an arbitrary 6bed4 Server of which only the Fallback IPv4 Address was found in an IPv6 destination address falling under the 6bed4 Prefix TBD1::/32.
Tunneling mechanisms must always be on their guard for wrapped packets containing false origins [RFC6169]. To shield against this, 6bed4 ensures that the source IPv4 address and UDP port of the together match either the Direct or Fallback 6bed4 Address contained in the source IPv6 address.
Note that this facility works best when address filtering [BCP38] is applied. In lieu of authentication facilities for frame source, the best that the 6bed4 tunnel can do is to avoid worsening the problems of incomplete address filtering.
One exception arises with the possibility that a target 6bed4-Prefixed Address publishes a /32+16 Prefix which is not seen everywhere on the Internet; or that such a prefix is not actually published at all. In such situations, a 6bed4 Frame may be routed to a TBD1::/32 route, which passes it on to the Fallback 6bed4 Address contained in the IPv6 destination address. The list of routers that can pass on such traffic will generally be limited, and will be maintained externally to this specification, but documented on 6bed4.net. Routes announced to larger IP space than owned by the publishing Anonymous System MUST be registered on 6bed4.net so as to distinguish them from abuse. The domain will publish processible information that helps 6bed4 Servers to recognise this distinction too.
It is important to realise that 6bed4 bypasses NAT and Firewalls. This is a feature inasfar as it enables peer-to-peer connectivity, but it also implies a responsibility to not lightly attach services to a 6bed4-Prefixed Address. There is no protection, other than what is being added. Specifically noteworthy is that the operator of the 6bed4 Server cannot implement filtering on behalf of their customers; the ability to use Direct 6bed4 Connections would bypass this, and since this could happen at any time such filtering could not even be realiably made connection-aware.
This work has evolved from a simple, and perhaps simplistic protocol to its current form. I owe gratitude to many who contributed.
Special thanks go to SURFnet, for generally supporting the idea of 6bed4 and providing long-term support for the first public 6bed4 Server, as well as supporting the expansion of the initial tunnel investigation work into a generally useful publication [RFC7059].
Thanks for financial support in developing phases of the specification and coding of 6bed4 are due towards NLnet Foundation, as well as SURFnet and SIDNfonds.
I owe gratitude to the NLUUG, ISOC NL and RIPE communities for discussing prior tunnel designs and pointing out scaling and routing problems; although the protocol has become more complex it also has become more reliable and, I think, more generally acceptable.
Finally, the work in this tunnel design called for a creative mind set in which technical concepts were highly fluid and changing. Although it would be difficult to point out a direct link or assign an economic figure, the ability to think in such a mode has clearly been influenced by independent, thought-provoking, boundary-breaking expression by the many artists whose work I have been able to enjoy. I cherish art in all its forms for its incredible power to help us be imaginative and innovative in the pragmatic field of technology.