Internet DRAFT - draft-vanrein-6bed4

draft-vanrein-6bed4







Network Working Group                                        R. Van Rein
Internet-Draft                                         OpenFortress B.V.
Intended status: Informational                              July 9, 2020
Expires: January 10, 2021


          6bed4: IPv6 Anywhere in support of Reliable Peering
                         draft-vanrein-6bed4-04

Abstract

   The purpose of 6bed4 is to support IPv6-only networks, hosts and
   applications.  It passes IPv6 frames over UDP between IPv4 sites.
   Peers connected over 6bed4 can switch to direct routes over UDP/IPv4
   after deducing that this will be reliable.

   6bed4 lets peer-to-peer applications benefit from transparant
   addressing in IPv6 and delegates NAPT concerns to 6bed4.  It is
   possible to use 6bed4 as a fallback for IPv6, or as an additional
   route.  Servers can be setup as IPv6-only servers with NAT64 for
   IPv4-only customers who only need client-server facilities, and add a
   6bed4router to also facilitate reliable peer-to-peer protocols.

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 January 10, 2021.

Copyright Notice

   Copyright (c) 2020 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



Van Rein                Expires January 10, 2021                [Page 1]

Internet-Draft                    6bed4                        July 2020


   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.

Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Address Format  . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Protocol Description  . . . . . . . . . . . . . . . . . .   4
     2.3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  6bed4 Network Components  . . . . . . . . . . . . . . . . . .   6
     3.1.  IPv6 Address Validation . . . . . . . . . . . . . . . . .   6
     3.2.  Router Solicitation and Advertisement . . . . . . . . . .   6
     3.3.  Network Prefixes  . . . . . . . . . . . . . . . . . . . .   7
       3.3.1.  Native /64 Prefixes . . . . . . . . . . . . . . . . .   8
       3.3.2.  Locally Routed fc00::/7 Prefixes  . . . . . . . . . .   8
       3.3.3.  The 6bed4 fc64::/16 and TBD1::/32 Prefixes  . . . . .   9
   4.  The 6bed4peer Component . . . . . . . . . . . . . . . . . . .  10
     4.1.  6bed4peer Forwarding  . . . . . . . . . . . . . . . . . .  10
     4.2.  6bed4peer Filtering . . . . . . . . . . . . . . . . . . .  12
   5.  The 6bed4router Component . . . . . . . . . . . . . . . . . .  13
     5.1.  6bed4router Filtering . . . . . . . . . . . . . . . . . .  14
     5.2.  6bed4router Forwarding  . . . . . . . . . . . . . . . . .  15
     5.3.  Combining 6bed4peer and 6bed4router Functions . . . . . .  16
   6.  Peering Policies  . . . . . . . . . . . . . . . . . . . . . .  16
   7.  Reliable Peering  . . . . . . . . . . . . . . . . . . . . . .  19
     7.1.  Reliable 6bed4router Uplinks  . . . . . . . . . . . . . .  19
     7.2.  Probing for Direct Peering  . . . . . . . . . . . . . . .  20
     7.3.  Sending and Receiving the Seen Flag . . . . . . . . . . .  20
     7.4.  Peer NAPT State . . . . . . . . . . . . . . . . . . . . .  21
     7.5.  State/Timer Diagram . . . . . . . . . . . . . . . . . . .  22
     7.6.  Differentiation through Peering Policies  . . . . . . . .  23
     7.7.  Bindable Local Prefix . . . . . . . . . . . . . . . . . .  24
     7.8.  Benefiting from Adaptive Flags  . . . . . . . . . . . . .  25
   8.  Global Routing of TBD1::/32 . . . . . . . . . . . . . . . . .  26
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  27
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  28
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  29
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  31







Van Rein                Expires January 10, 2021                [Page 2]

Internet-Draft                    6bed4                        July 2020


1.  Terminology

   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].

2.  Introduction

   Several tunnels for IPv6 have been proposed [RFC7059]; the novelty of
   6bed4 is that it allows the assumption that IPv6 is everywhere; not
   only can it be implemented for hosts or networks, but even inside an
   application.  As a result, application developers can rely on
   transparant IPv6 addressing, even when their code is distributed over
   a network that may include IPv4-only users.  Currently unsupported
   use cases such as SIP/RTP, direct file transfer and other peer-to-
   peer protocols can benefit from the relative simplicity of this model
   and the knowledge that traffic either transfers directly between
   peers, or reflects through a relay of the user's choosing.

   To carry IPv6 anywhere, 6bed4 transports it as a UDP payload,
   contained in UDP/IPv4.  The UDP port and IPv4 address are derived
   from the IPv6 address on sending, and validated to match upon
   arrival.  This means that much of the 6bed4 infrastructure can be
   stateless, like a router.  In addition, IPv4 attackers are still
   traceable when they use 6bed4 to step up to IPv6.

   The 6bed4 network consists of any number of 6bed4peers running IPv6
   applications and usually a 6bed4router that defines a prefix under
   which it reliably connects peers, and through which it may route to
   and from native IPv6 addresses.  To optimise routing, one 6bed4peer
   may choose to access multiple 6bed4routers, but automatic detection
   of crossover between 6bed4peers under different 6bed4routers is also
   possible.

2.1.  Address Format

   The structure of a 6bed4 address may involve a specialised top half
   structure in the /64 prefix and/or a specialised bottom half
   structure following it.  The format of a 6bed4 address with both
   specialised parts is:

   |  32 bits |          32         |          50             |  14   |
   +----------+---------------------+-------------------------+-------+
   |  prefix  | 6bed4router address | direct 6bed4peer address| lanid |
   +----------+---------------------+-------------------------+-------+

   Whether the top half is a 6bed4 address depends on the prefix.  The
   prefix TBD1::/32 globally defines a 6bed4 address, and supports



Van Rein                Expires January 10, 2021                [Page 3]

Internet-Draft                    6bed4                        July 2020


   routing across the Internet.  Prefixes fc64:<netid>::/32 for any
   <netid> are interpreted as 6bed4 addresses when they occurs on the
   6bed4 network, but this interpretation cannot be generally
   prescribed.  These /32 prefixes permit the interpretation of the top
   half, where bits 32..64 hold the IPv4 address of a 6bed4router that
   can further relay the traffic.  Any IPv6 router may pass TBD1::/32 by
   forward the IPv6 packet over UDP/IPv4 to port TBD2 and the address in
   the IPv6 top half.

   Any /64 prefix that is a destination address on the 6bed4 network
   must adhere to this format for the lower half.  These are prefixes
   announced by 6bed4router and 6bed4peer components, extended to a /114
   in a Router Advertisement and having the L and A flags set.  Traffic
   with a 6bed4peer source address never came from a routed backend, so
   source addresses arriving over direct peering instead of from a
   subscribed-to 6bed4router can also be considered to have a 6bed4
   lower half.  This lower half contains the IPv4 address and UDP port,
   as observed by an addressed party.

2.2.  Protocol Description

   The role of a 6bed4router is to be the defining home for one /64
   prefix and potentially connect to other IPv6 addresses.  It binds a
   UDP socket to a static IPv4 address and the standard UDP port TBD2.

   Every 6bed4peer opens a UDP socket and is identified by one or more
   external pairs of an IPv4 address and UDP port.  The UDP socket is
   seen as a /64 prefix, usually obtained from a 6bed4router, extended
   into to as many /114 prefixes as the 6bed4 network has external
   address/port pairs for its UDP/IPv4 socket.

   When a 6bed4peer desires to run under the /64 prefix of a given
   6bed4router, it sends a Router Solicitation to its UDP/IPv4 address.
   The response is an initial Router Advertisement that offers a /114
   prefix, consisting of the /64 of the 6bed4router externded with the
   UDP/IPv4 address of the 6bed4peer, as observed by the 6bed4router.
   This /114 must be used as the source address in future communications
   with that 6bed4router.  A 6bed4peer sends Keepalive messages to keep
   the NAPT mapping towards the 6bed4router open as a reliable
   bidirectional routing path.

   When attempting direct peering, the UDP/IPv4 destination address of a
   remote 6bed4peer is collected from its /114 and a direct UDP/IPv4
   message is attempted.  This may or may not succeed, so the initial
   attempt is usually a Probe that may result in a future report of a
   Seen flag.  In reliable modes of operation, the initial traffic is
   sent through the 6bed4router until it learns that direct peering is




Van Rein                Expires January 10, 2021                [Page 4]

Internet-Draft                    6bed4                        July 2020


   possible; more agressive but less reliable peering policies are
   defined as alternatives.

   Traffic on the 6bed4 network is validated to hold an IPv6 source
   address with a lower half mentioning the source UDP/IPv4 address.
   Failure to match rejects the message with a corrective Router
   Advertisement in return.  This allows a 6bed4peer to communicate
   directly with any 6bed4peer, and to learn of another external UDP/
   IPv4 address for its UDP socket in relation to other network
   components.

2.3.  Use Cases

   The 6bed4peer can be run for a network, a machine or even a single
   application.  It can add IPv6 to any machine that supports IPv4,
   whether it already supports IPv6 or not.

   The 6bed4router can share a /64 prefix to any number of 6bed4peer
   nodes.  It may offer additional routes to network regions that can
   route back to this /64 prefix, including an offering of a default
   route if the shared prefix is globally routable.

   Applications may benefit from the certainty that IPv6 is available,
   especially when they run their own 6bed4 network.  They would
   normally want to connect to a 6bed4router at its specified IPv4
   address and UDP port TBD2 and obtain a /114 prefix holding their own
   IPv4/UDP address.  The final 14 lanid bits allow a range of addresses
   to divide as the 6bed4peer sees fit.

   Peer-to-peer applications may prefer to evade the 6bed4router and
   prefer direct peering, at least when both peers are known to use
   6bed4 address bottom halves.  This may not always succeed, mostly
   dependent on NAPT properties which cannot generally be solved.  The
   desired peering policy can be specified in each frame, and peering
   success or failure can be learnt from received frames, so preferences
   among alternative routes could be based on peering properties.

   The reliable and desired-direct approaches can be mixed, because the
   peering policy is separately set in the traffic class for each IPv6
   frame.  An application might connect (perhaps with SIP) through a
   6bed4router and use a direct-peering data path (perhaps with RTP)
   afterwards.  It is possible to bind to another address for RTP than
   for SIP, and the addition of Keepalive messages can even support non-
   symmetric RTP streams; all this can help to find direct routes where
   they are possible, and thus rely on a minimum of fallback routing
   through the 6bed4router.





Van Rein                Expires January 10, 2021                [Page 5]

Internet-Draft                    6bed4                        July 2020


3.  6bed4 Network Components

   This section describes common aspects that apply to 6bed4peers as
   well as 6bed4routers.  Later sections specify aspects that these
   components add.

   Every component on the 6bed4 network opens a UDP port over which it
   sends and receives IPv6 frames.  The further processing of these
   frames depends on the component.

3.1.  IPv6 Address Validation

   Upon arrival of an IPv6 frame over UDP/IPv4, the IPv6 source (and
   destination) address is verified.  This usually involves testing an
   IPv6 address to have a lower half containing an IPv4 address and UDP
   port, almost in network bit order.  The lower half must follow this
   format:


    |      6      |  2    |     24       |   16  |      2      |   14  |
   -+-------------+-------+--------------+-------+-------------+-------+
    | IPv4 [0..5] | EIU64 | IPv4 [8..31] |  UDP  | IPv4 [6..7] | lanid |
   -+-------------+-------+--------------+-------+-------------+-------+


   The IPv4 address is split into portions [N..M] with bits N to M,
   counting from 0 for the high end.  The IPv4 address effectively has
   two bits taken out to conform to the EUI-64 address format [RFC3513].
   The overlaid IPv4 address bits follow after the UDP port.  The last
   14 bits form the lanid, which can be freely used on the component
   bound to the given UDP port and IPv4, except for the value 0, which
   is reserved for the 6bed4router for this IPv6 address.

3.2.  Router Solicitation and Advertisement

   When a local 6bed4 component intends to connect to a remote 6bed4
   component, it may send a Router Solicitation [Section 4.1 of
   [RFC4861]] to the IPv4 address and UDP port of the remote.  The
   prefix supplied can be used after the remote sends back a Router
   Advertisement [Section 4.2 of [RFC4861]], the composition of which is

   o  Flags [Section 3 of [RFC5175]] are M=0, O=0, H=0, P=0.

   o  A prefix of length /114, where the /64 portion defines the 6bed4
      network and the added 50 bits hold the local component's UDP port
      and IPv4 address as observed by the remote 6bed4 component.  The
      trailing 14 bits are the lanid; lanid 0 is reserved for the




Van Rein                Expires January 10, 2021                [Page 6]

Internet-Draft                    6bed4                        July 2020


      router, but the other 16383 values may be used freely by the local
      component, perhaps through DHCPv6.

   o  Any number of routes, possibly including a default route.  Any
      route MAY be ignored by the local 6bed4 component.  Routes only
      make sense when the reachable prefixes can route traffic back to
      the remote 6bed4 component; a 6bed4peer SHOULD NOT offer routes
      because it is considered a terminal in the 6bed4 network, rather
      than an authoritative source of routes.

   Every component on the 6bed4 network SHOULD send a Router
   Advertisement to correct an invalid bottom-half Section 3.1 in an
   IPv6 source address.  This allow the sending 6bed4 component to
   correct its own idea of its externally observed UDP/IPv4 address, at
   least towards the designated recipient.  The bits that would change
   are the bottom-half bits holding its IPv4 address and UDP port; note
   that the lanid is always zero in a /114 prefix.

3.3.  Network Prefixes

   The 6bed4 network uses /114 prefixes for its destination addresses.
   These addresses contain a UDP/IPv4 address in their bottom half,
   following a /64 prefix in the address top half.  The top half is
   considered the identity of a 6bed4 network segment, as ususally
   defined by a 6bed4router and sometimes by a 6bed4peer.  The top half
   never changes while processing a corrective Router Advertisement; it
   does however get assigned by the initial Router Advertisement that
   follows up on a Router Solicitation.

   Even if a 6bed4peer obtains a /64 prefix from a 6bed4router as part
   of a /114 in an initial Router Advertisement, and even though it is
   not a router for that address, it may nonetheless use the /64 to
   construct a /114 towards other 6bed4peers.  This bottom-half logic is
   a point where 6bed4 destination addresses have more semantics than
   general IPv6.  Two 6bed4peers may use Router Solicitation and/or
   Router Advertisements to learn about each other's view on their
   addresses.  This behaviour is not required for reliable exchanges,
   but it can help to pierce through more kinds of NAPT router; it is
   why the /64 is said to describe a 6bed4 network, rather than just the
   component that introduces it.

   Typical for IPv6, there is some variation in use cases for different
   prefix kinds.  We distinguish native prefixes, locally routed
   prefixes and specific 6bed4 prefixes.







Van Rein                Expires January 10, 2021                [Page 7]

Internet-Draft                    6bed4                        July 2020


3.3.1.  Native /64 Prefixes

   Every 6bed4 component can export a native /64 prefix, provided that
   it can route to it and that the native prefix is routed back to it.
   This facility allows sharing that prefix to connecting other
   components; do note that no access control exists, but the bottom
   half of an IPv6 address under the prefix reveals the validated UDP/
   IPv4 address of a source.

   The top-half of a native prefix is not recognised as a 6bed4 address,
   as it is not possible to extract a 6bed4router IPv4 address from it.
   As a result, its traffic usually passes over native IPv6 routes.  The
   benefit of a publicly routable IPv6 address is that it can be used in
   connections to arbitrary other IPv6 addresses that are also globally
   routable.

   Some hosts have only one /64 available, and may want to mix 6bed4
   with services.  Although invalid 6bed4 bottom halves (for instance,
   UDP port 0) could be allocated for other uses than 6bed4, this is NOT
   RECOMMENDED because it would break connectivity for other 6bed4
   components when the prefix is passed through the 6bed4 network via
   Router Advertisements.  Instead, the RECOMMENDED procedure would be
   to setup IPv6 addresses as available to a locally run 6bed4peer on a
   fixated public IPv4 address and UDP port; the 6bed4 component
   software may optimise handling for these purposes.

3.3.2.  Locally Routed fc00::/7 Prefixes

   Some IPv6 addresses have been allocated for local routing [RFC4193].
   The fc00::/7 prefix is divided into administratively assigned
   fc00::/8 prefixes and randomly completed fd00::/8 prefixes.  With the
   exception of fc64::/16 discussed below, these addresses are locally
   routed, also on a 6bed4 network.

   Local routes cannot be used to communicate with native IPv6 address,
   unless they happen to be aware of how to return the traffic.  Such
   native routes in the direct backend of a 6bed4router can be
   explicitly mentioned in its Router Advertisement, even for a fc00::/7
   prefix.

   Locally routed addresses can only be communicated with the 6bed4
   component that defines them.  Because of this, they MUST NOT be
   further transmitted through Router Advertisement; connections are 1:1
   only.  Whether this is a 6bed4peer to a 6bed4router (reliable) or a
   6bed4peer to another 6bed4peer (not reliable) is a matter of
   application or network configuration.





Van Rein                Expires January 10, 2021                [Page 8]

Internet-Draft                    6bed4                        July 2020


   It is quite possible for a 6bed4peer to setup a random /64 prefix
   based on fd00::/8, and peers might even form networks between such
   addresses, possibly based on a distributed hash table.  In such
   networks, redundancy can be helpful to overcome unreliable direct
   peering connections.  As explained below, 6bed4 can support the
   detection of reliability.

3.3.3.  The 6bed4 fc64::/16 and TBD1::/32 Prefixes

   The prefixes fc64::/16 and TBD1::/32 mark what are called 6bed4
   prefixes.  The fc64::/16 prefix receives an additional network
   identifier <netid> to form fc64:<netid>::/32.  These /32 prefixes are
   used in a top half, whose format is completed with the IPv4 address
   of a 6bed4router, in network byte order:


   |               32               |               32               |
   +--------------------------------+--------------------------------+-
   |      fc64:<netid> or TBD1      |   IPv4 address of 6bed4router  |
   +--------------------------------+--------------------------------+-


   The 6bed4router is responsible of knowing its public IPv4 address.
   The fixed UDP port on which the 6bed4router provides its service MUST
   be TBD2.  As a result, a network component that can interpret the
   prefix as a 6bed4 prefix can route the traffic over the 6bed4
   network.  For the TBD1::/32 prefix, this can be any party on the
   Internet; for fc64::/16 it can only be assumed when the address is
   found on the 6bed4 network.  The added value of TBD1::/32 over
   fc64::/16 therefore is that it expands the IPv6-everywhere
   facilitation of 6bed4 from an overlay network to a globally routed
   network.

   The 6bed4router is vital in the reliability of the 6bed4 network:

   o  The 6bed4router is always reachable at its IPv4 address and the
      fixed UDP port TBD2;

   o  The 6bed4router can always reach every 6bed4peer that subscribes
      to its serviced prefix.

   This means that a conservative route can always be made through a
   6bed4router.  This is also possible when the prefixes differ, either
   in the IPv4 address or also in the /32 part.  Within the constraints
   of source address validation, it is possible to route traffic through
   the 6bed4router covering the source prefix and the 6bed4router
   covering the destination prefix; or it is possible to route traffic




Van Rein                Expires January 10, 2021                [Page 9]

Internet-Draft                    6bed4                        July 2020


   through the 6bed4router of a destination node, after a source
   6bed4peer (also) connects to the destination's 6bed4router.

   Another value of the 6bed4 prefix is that they represent end points
   on the 6bed4 network.  This means that the bottom half can also be
   interpreted and used for direct 6bed4 traffic.  This usually works
   best when the source address is then also chosen to be a 6bed4
   address, which can be achieved under normal address binding rules
   when a low-priority interface offers routes for fc64::/16 or
   TBD1::/32 with a prefix under either.

4.  The 6bed4peer Component

   The 6bed4peer opens a UDP socket over which it sends and receives
   IPv6 frames.  The UDP remote end can be any number of 6bed4peers and/
   or 6bed4routers.  A basic configuration would communicate with a
   single 6bed4router which may be its default route to native IPv6
   addresses, and as many 6bed4peers as it can connect to directly.

   To be able to route under a 6bed4router's prefix, the 6bed4peer sends
   a Router Solicitation and awaits an initial Router Advertisement
   Section 3.2 to learn about its /114 prefix, which includes the /64
   prefix provisioned by the 6bed4router.  The 6bed4peer MAY configure
   any additional routes provided in a Router Advertisement from a
   6bed4router.  Through the Router Advertisement, the 6bed4peer learns
   about the external address of its UDP socket, as observed by the
   6bed4router.  Over this route, the 6bed4peer will send regular
   Keepalive messages to keep the NAPT traversal open and guarantee a
   reliable incoming route through the 6bed4router.  A generally advised
   minimum frequency for Keepalive messages is once in 30 seconds.

4.1.  6bed4peer Forwarding

   To submit an IPv6 frame on the 6bed4 network, a 6bed4peer first
   determines whether it can forward to a 6bed4router or directly to a
   6bed4peer:

   o  When source and destination share the same /64 prefix, consider
      direct routing as well as the 6bed4router.

   o  When the destination is a 6bed4 prefix and the source and
      destination have different /64 prefixes, consider direct routing
      as well as the 6bed4router.

   o  When the destination has another prefix (that was offered and
      accepted as a route from a 6bed4router), consider going through
      the 6bed4router.




Van Rein                Expires January 10, 2021               [Page 10]

Internet-Draft                    6bed4                        July 2020


   When a direct route is considered, the default peering policy
   Section 6 only uses direct peering when it is known to be reliable
   Section 7.  Other peering policies provide variations on a frame-by-
   frame basis, to allow for maximum flexibility.  When direct routing
   is selected, any considerations of going through the 6bed4router are
   dropped.

   When considering the 6bed4router, the /64 prefix of the source
   address determines which one to use.  When the source and destination
   have 6bed4 addresses with different /64, the traffic bounces through
   both 6bed4routers, which is useful to validate the traffic for not
   forging IPv6 addresses.  To avoid this "trapeziums-shaped" routing,
   it is also possible for a 6bed4peer to bind an address under the
   destination address's 6bed4router by sending a Router Solicitation
   and acquiring a /114 prefix to work from.  The result would be only
   one 6bed4router bouncing the traffic instead of two.  Whether or not
   this is done, direct peering may be discovered as reliable
   alternative and either shape bypassed completely.

   The IPv6 frame can now be sent over the 6bed4 network, from the UDP
   socket held by the 6bed4peer.  The remote UDP port and IPv4 address
   are learnt from the bottom half of the destination IPv6 address.
   Since a 6bed4peer is not supposed to route traffic, any source
   address is supposed to be locally bound, therefore be a 6bed4
   address, and so its bottom half is supposed to contain the external
   view on its UDP port and IPv4 address.

   Although it makes less sense for UDP than for TCP, NAPT middleware
   may have imposed an Endpoint-Dependent Mapping [RFC4787], which means
   that the external UDP port and IPv4 address observed by the
   6bed4router form a reasonable initial guess when communicating
   directly with other 6bed4peers, but there may be a need to correct
   these aspects when communicating with such 6bed4peers.  To this end,
   a remote peer might send a corrective Router Advertisement and the
   IPv6 frame would be lost.  This should not happen when reliability
   rules are obeyed, but it may happen for frames that select another
   peering policy than the default.

   Note how this opens degrees of freedom to the an application acting
   as/via a 6bed4peer.  For general TCP or SCTP, a first SYN or INIT
   frame might be sent under a peering policy that enforces direct
   peering, and fall back to reliable routing when resent.  And a
   application could send SIP messages over reliable patterns, but work
   towards direct peering for RTP; a SIP/SDP offer can welcome RTP
   traffic on a 6bed4 address, possibly using a 6bed4router in a SIP/SDP
   offer that was just received; many SIP networks are closed, and could
   opt to be IPv6-only networks, with 6bed4 as a reliable fallback
   option.



Van Rein                Expires January 10, 2021               [Page 11]

Internet-Draft                    6bed4                        July 2020


4.2.  6bed4peer Filtering

   Anyone might send packets to the UDP socket of a 6bed4peer, but not
   all traffic should pass.  Specifically, filtering on the IPv4/UDP
   source address in relation to the IPv6 source address is necessary to
   stop peers from claiming arbitrary IPv6 addresses.

   Traffic without a full IPv6 header is exceptional, and considered to
   be a Probe; an attempt to reach our UDP socket through direct
   peering.  This is not routed any further, but it counts as successful
   input under direct peering.  Usually sent before or after an IPv6
   frame via the 6bed4router, it permits flagging that this direct input
   succeeded on return traffic to that same 6bed4peer.

   There are two reasons why an IPv6 header's source address might be
   acceptable; it could be from a 6bed4router to which the receiving
   6bed4peer maintains an uplink, or it might be a direct connection
   from another 6bed4peer under the same 6bed4router.  On top of this, a
   third reason to accept an IPv6 header is when its source and
   destination address together indicate that a bypass of a trapezium
   route is made.

   The 6bed4peer should know the 6bed4routers to which it maintains an
   uplink; it needs this information for sending Keepalives that
   maintain an open NAPT mapping.  Each 6bed4router can be uniquely
   identified by matching their IPv4 address and UDP port against the
   UDP/IPv4 source address of an incoming frame.

   A frame sent directly from another 6bed4peer working under the same
   6bed4router will use a /64 prefix that we got from that 6bed4router.
   As a result, we can rely on the bottom half address to contain a IPv4
   address and UDP port, which MUST then match the source of the
   incoming frame.  When the /64 prefix matches but the bottom half does
   not, a corrective Router Advertisement SHOULD be sent (possibly with
   a limited frequency).  TODO:REQUIRE_SRC/64_IS_DST/64?

   The bypass for a trapezium route is more complicated.  In this case,
   the frame came from a 6bed4peer acting under another 6bed4router.
   The frame was first passed to the source's 6bed4router and then the
   destination's.  When the latter delivers the frame at the
   6bed4destination, the source and destination IPv6 address are used.
   First, both addresses MUST be 6bed4 addresses, so have either the
   fc64::/16 or TBD1::/32 prefix, in any combination.  Second, the
   6bed4router addresses in the top half are considered; the source
   6bed4router address is assumed to have been validated by our
   6bed4router; the destination 6bed4router address MUST be found as one
   to which we maintain an uplink.  Third, the source IPv4 address and
   UDP port MUST be set in the bottom half of the source IPv6 address.



Van Rein                Expires January 10, 2021               [Page 12]

Internet-Draft                    6bed4                        July 2020


   Fourth, our IPv4 address and UDP port according to our 6bed4router
   (which is mentioned in the top half of the IPv6 destination address)
   MUST match the bottom half of the IPv6 destination address.  Failure
   on any of these four conditions leads to discarding of the frame as a
   suspect frame.

5.  The 6bed4router Component

   The 6bed4router is a stateless component.  It can be reached reliably
   on a static IPv4 address on the fixed UDP port TBD2, so it can be
   reached by all 6bed4 components.  If a NAPT mapping applies, it is a
   static mapping.

   Every 6bed4router defines its own /64 prefix and when this is a 6bed4
   address its static IPv4 address is contained in the IPv6 address top
   half that forms this prefix.  In addition to the offered prefix, a
   6bed4router may also exchange IPv6 frames with locally routable
   prefixes and/or with globally routable prefixes anywhere on the
   Internet.

   Among the routes offered may be the default route ::/0.  This is just
   one of many possible routes.

   Another seemingly special route is fc64::/16, which captures more
   than just a specific fc64:<netid>::/32 that the 6bed4router may use
   as its prefix.  A route fc64::/16 states that other <netid> values
   can be routed to the 6bed4router's connected network.  Only the one
   announced in the prefix is handled directly by the 6bed4router.
   Again, there is no need to treat such cases in any special way.
   TODO: BUT WE DO TREAT IT ESPECIALLY; IF NOT OUR IPV4 IS USED, WE
   RELAY SUCH A PREFIX.  SAME FOR TBD1::/32 BY THE WAY.

   Traffic that arrives over the 6bed4 network is first filtered to be
   properly formed.  After this, one possible forwarding option is to
   bounce the frame back into the 6bed4 network, but to another IPv4
   address and UDP port.  This is done to relay traffic between two
   6bed4peers that share the 6bed4router's /64 prefix but that are not
   (yet) able or willing to connect directly.  It is also done to relay
   traffic between two 6bed4routers if their 6bed4peers use different
   /64 prefixes and are not (yet) able or willing to connect directly;
   this situation is called trapezium routing and is effectively a
   bypass for routing over IPv6, mostly to permit fc64::/16 prefixes to
   work across 6bed4routers' prefixes.








Van Rein                Expires January 10, 2021               [Page 13]

Internet-Draft                    6bed4                        July 2020


5.1.  6bed4router Filtering

   The 6bed4router is stateless, but it is careful about filtering
   traffic before agreeing to route it.  Different filtering rules are
   applied on the IPv6 side of the 6bed4router than on the side of the
   6bed4 network.

   Traffic arriving at the IPv6 side is called return traffic.  Traffic
   arriving over the 6bed4 network can be routed for either local,
   backend or first and second stage of trapezium routing.

   Return traffic MUST be rejected unless:

   o  The destination IPv6 address matches the 6bed4router's defined /64
      prefix;

   o  The bottom half of the destination IPv6 address does not mention
      IPv4 address 0.0.0.0;

   o  The bottom half of the destination IPv6 address does not mention
      UDP port 0.

   Local routing applies when the IPv6 source and destination addresses
   both use the /64 prefix defined by the 6bed4router.  Local routing
   MUST be rejected unless:

   o  The bottom half of the IPv6 source address mentions the IPv4
      address and UDP port over which the frame arrived from the 6bed4
      network;

   o  The bottom half of the IPv6 destination address does not mention
      IPv4 address 0.0.0.0;

   o  The bottom half of the IPv6 destination address does not mention
      UDP port 0.

   Backend routing applies when the IPv6 source address uses the /64
   prefix defined by the 6bed4router, while the IPv6 destination address
   matches a route announced in Router Advertisements.  TODO:CONSIDER_TR
   APEZIUM_ROUTING_FOR_6BED4ADDRS_WITH_DIFFERENT_TOP_IPV4ADDR.  Backend
   routing MUST be rejected unless:

   o  The bottom half of the IPv6 source address mentions the IPv4
      address and UDP port over which the frame arrived from the 6bed4
      network.

   The first stage of trapezium routing applies when the IPv6 source
   address uses the /64 prefix defined by the 6bed4router, but the



Van Rein                Expires January 10, 2021               [Page 14]

Internet-Draft                    6bed4                        July 2020


   desination IPv6 address neither suggests local or backend routing.
   The first stage of trapezium routing MUST be rejected unless:

   o  The source and destination IPv6 addresses are both 6bed4
      addresses, though not necessarily the same;

   o  The IPv6 source address matches the /64 prefix of the 6bed4router;

   o  The bottom half of the IPv6 source address mentions the IPv4
      address and UDP port over which the frame arrived from the 6bed4
      network;

   o  The bottom half of the IPv6 destination address does not mention
      IPv4 address 0.0.0.0;

   o  The bottom half of the IPv6 destination address does not mention
      UDP port 0.

   The second stage of trapezium routing applies when the IPv6
   destination address uses the /64 prefix defined by the 6bed4router,
   but the source IPv6 address neither suggests local or backend
   routing.  The second stage of trapezium routing MUST be rejected
   unless:

   o  The source and destination IPv6 addresses are both 6bed4
      addresses, though not necessarily the same;

   o  The IPv4 address over which the frame arrived from the 6bed4
      network matches the 6bed4router address in the top half of the
      IPv6 source address;

   o  The UDP port over which the frame arrived from the 6bed4 network
      is the standard port TBD2;

   o  The bottom half of the IPv6 destination address does not mention
      IPv4 address 0.0.0.0;

   o  The bottom half of the IPv6 destination address does not mention
      UDP port 0.

5.2.  6bed4router Forwarding

   The 6bed4router terminates certain IPv6 destination addresses.  These
   addresses match the /64 prefix, and the bottom half defines the IPv4
   address at which the 6bed4router can be reached, along with its
   standard UDP port TBD2.  Furthermore, any bottom half that specifies
   lanid value 0 is considered to terminate at the 6bed4router.  Such
   addresses may have some special treatment for ICMPv6 traffic, but



Van Rein                Expires January 10, 2021               [Page 15]

Internet-Draft                    6bed4                        July 2020


   most other traffic would be relayed to a local interface binding to
   that address.  In absense of such a binding, an ICMPv6 error may be
   sent back.

   Return traffic is relayed over the 6bed4 network to the IPv4 address
   and UDP port found in the bottom half of the IPv6 destination
   address.

   Local traffic is relayed back over the 6bed4 network to the IPv4
   address and UDP port found in the bottom half of the IPv6 destination
   address.

   Backend traffic is relayed into the backend, normally using the
   routing table under which the 6bed4router operates.

   The first stage of trapezium routing is relayed over the 6bed4
   network to the 6bed4router address in the top half of the destination
   IPv6 address and the standard UDP port TBD2.

   The second stage of trapezium routing relays over the 6bed4 network
   to the IPv4 address and UDP port found in the bottom half of the IPv6
   destination address.

5.3.  Combining 6bed4peer and 6bed4router Functions

   It is possible for a single component to act both as a 6bed4peer and
   a 6bed4router.  The individual requirements for each apply,
   specifically resolving potential conflicts with:

   o  The component MUST be externally reachable on a static IPv4
      address at the standard UDP port TBD2;

   o  When sending a Router Advertisement, it MUST NOT provide
      additional routing information.

6.  Peering Policies

   The IPv6 frame that travels over the 6bed4 network, so between 6bed4
   components, can express its preferred peering policy.  This is
   expressed through the Traffic Class, which is spread over two bytes
   in the IPv6 header.  The value of the Traffic Class is generally
   considered [RFC2474][RFC3168] to follow this structure:









Van Rein                Expires January 10, 2021               [Page 16]

Internet-Draft                    6bed4                        July 2020


   |       6      |  2  |
   +--------------+-----+
   |      DS      | ECN |
   +--------------+-----+


   Part of the DS field is interpreted [RFC2474] as a Class Selector CS:


   |    3   |  3  |  2  |
   +--------+-----+-----+
   |   CS   | 000 | ECN |
   +--------+-----+-----+


   On the 6bed4 network, the interpretation of CS is further split into
   a two-bit peering policy PP and a Seen flag S:


   |  2 | 1 |  3  |  2  |
   +----+---+-----+-----+
   | PP | S | 000 | ECN |
   +----+---+-----+-----+


   The PP and S values may be retained when a frame exits a 6bed4peer
   and arrive at an application.  The Seen flag expresses that direct
   peering from this side to the source address recently succeeded, even
   if just as a Probe.  This means that direct peering to the IPv6
   source address is considered reliable for 27 seconds from the arrival
   of the frame with the Seen flag.  The 6bed4peer normally takes note
   of this flag, and modifies its peering behaviour accordingly.

   Before entry into the 6bed4 network, so in the application that
   constructs the IPv6 frame to be relayed through a 6bed4peer, the
   peering policy PP indicates the desired peering policy, but the Seen
   flag has no meaning yet; its place is taken by Adaptive flag A:


   |  2 | 1 |  3  |  2  |
   +----+---+-----+-----+
   | PP | A | 000 | ECN |
   +----+---+-----+-----+


   The Adaptive flag expresses that the IPv4 address and UDP port in the
   bottom half of the source IPv6 address may be modified at will.  When
   local NAPT performs Endpoint-Dependent Mapping it would map the same



Van Rein                Expires January 10, 2021               [Page 17]

Internet-Draft                    6bed4                        July 2020


   UDP socket to different external address/port combinations for
   different remote peers.  Normally, this makes the reliable traffic
   fall back on the 6bed4router, because there is no basis of trust for
   the remote that two seemingly different peers map to the same UDP
   socket and hence to the same 6bed4peer.  Through Adaptive source
   addresses, a prefix supplied through a corrective Router
   Advertisement in the past can be used to construct a suitable source
   address.  Other than the Adaptive flag, the 6bed4peer needs no
   instructions to do this.  The application may learn the new address
   from replies to a frame sent with the Adaptive flag.  It is then free
   to adopt the address and continue without an Adaptive flag, or to
   continue and even allow connected updates to the address when NAPT
   changes state.  If and when this can work is up to the application
   logic.

   The four peering policy (PP) values defined for 6bed4 are:

   Proper Peering  has bit value 00 or decimal value 0 and is the
      default.  This policy routes through the source's 6bed4router when
      direct peering has not been detected to be reliable, but as soon
      as it is considered reliable it switches to direct peering.

   Prohibited Peering  has bit value 01 or decimal value 1.  This policy
      prohibits direct peering and will always route through the
      source's 6bed4router.

   Presumptious Peering  has bit value 10 or decimal value 2.  At the
      expense of reliability, this policy tries direct peering for a few
      seconds.  If reliability is not achieved within these seconds, it
      falls back to the same behaviour as Proper Peering, which can also
      route through the 6bed4router.  Until that fallback however,
      traffic may be lost.

   Persistent Peering  has bit value 11 or decimal value 3.  At the
      expense of reliability, this policy tries direct peering for a few
      seconds.  If reliability is not achieved within these seconds, it
      persists in this behaviour but will report errors, either with
      return values or through occasional ICMPv6 errors.  This policy is
      the most likely to drop traffic.

   These values can be chosen on a frame-by-frame basis without damage
   to the logic that learns about the reliability of direct peering.
   Applications being aware of the meaning in a protocol of each frame,
   may choose to use less reliable delivery modes for application-
   specific purposes.






Van Rein                Expires January 10, 2021               [Page 18]

Internet-Draft                    6bed4                        July 2020


7.  Reliable Peering

   Given the nature of NAPT, there can be no completely reliable peering
   system without a fallback to a services that bounces traffic.  This
   is why a 6bed4 network needs the fallback option of a 6bed4router to
   offer reliable routing.  When NAPT is enhanced with port forwarding,
   this situation can be changed, and some applications may implement so
   many alternative routing options that full reliability might be
   waived.  This is why special situations might be created to work
   reliably without a 6bed4router.  However, when 6bed4 is built into an
   application that should "just work", it does need the fallback
   6bed4router to be reliable.

   The 6bed4 network can reliably switch to direct peering after a
   successful peering handshake.  This is a deductive approach to NAPT
   traversal, and is achieved simply by trying direct peering and
   observing if it arrives.  The lesson taken from prior inductive
   approaches [RFC4380] founded on classification of NAPT [RFC3489] was
   that such an approach can easily misclassify NAPT behaviour, ensuing
   in brittle IPv6 connectivity.

   The decuction in 6bed4 is mostly through properties of UDP.
   Specifically, the absense of a protocol identifier disables
   interpretation of the protocol behaviour by NAPT, unless bold
   assumptions are made on the basis of a port number.  To be workable,
   a NAPT therefore must keep an outward-sending UDP port open for
   response traffic.  For some protocols, the response may come from
   other angles, which suggests that Endpoint-Dependent Mapping is not
   suitable for UDP, but this cannot be assumed in general.  A certain
   amount of acceptable silence until the given connection closes can
   however be assumed, and it is commonly suggested that this should be
   at least 30 seconds.  The only assumption made by 6bed4 is that these
   30 seconds are a reasonable default, but of course this MUST be a
   setting that can be overridden by operators.  NAPT software MUST NOT
   make any assumptions of passing 6bed4 on the basis of the standard
   port TBD2 if it is to comply with this specification.

7.1.  Reliable 6bed4router Uplinks

   Given that NAPT can only handle 6bed4peer traffic as generic UDP
   traffic, any outbound UDP traffic necessarily keeps a hole open for
   reverse traffic over a reasonable minimum time.  When more traffic is
   sent before this period has passed, there is no basis for NAPT to
   assume that the connection can be severed, causing a reset of the
   timeout for the hole.

   To allow reliable bidirectional traffic between a 6bed4peer and its
   6bed4router, it therefore initiates with a Router Solicitation, and



Van Rein                Expires January 10, 2021               [Page 19]

Internet-Draft                    6bed4                        July 2020


   then continues to send Keepalive messages with no smaller separating
   delay than the delay for UDP holes.

   Keepalive messages need not make it to the 6bed4router to be
   effective.  Their only need is to make it beyond the last NAPT or
   firewall.  This can both help to offload a 6bed4router and to avoid
   that it detects the 6bed4peer still being online; since the
   6bed4router is stateless, it has no use for this information.

   The content of a Keepalive message can be the minimum that counts as
   UDP traffic, according to NAPT and firewalls; this is an empty UDP
   frame.

   A 6bed4peer can keep up any number of 6bed4router uplinks, and would
   send Keepalive messages to each of them.  This being a resource, the
   application may have to indicate explicitly what uplinks are
   considered to be useful (or a trivial setup such as a single uplink
   might be applied).

7.2.  Probing for Direct Peering

   When choosing how to forward an IPv6 frame, a 6bed4peer may consider
   direct routing, but refrain from it on account of reliable
   considerations.  These are good moments to start working towards
   direct routing.  Other moments are when a 6bed4peer forces direct
   peering through the Presumptious and Persistent Peering Policies.

   While working towards direct routing, a few attempts to connect
   directly are made, by sending a Probe message if no direct traffic is
   sent at the same time.  Probes are the smallest possible UDP frame,
   so an empty UDP message.  They differ from Keepalives because their
   reach is not constrained but the message is sent with the intention
   of arriving at the remote 6bed4peer.  The destination IPv4 address
   and UDP port are taken from the bottom half of the destination IPv6
   address, which is only permitted for addresses known to be bound by
   the 6bed4 network.

   When a Probe arrives on a 6bed4peer, it cannot be considered an IPv6
   frame.  It is however detected as an incoming UDP frame from a given
   IPv4 address and UDP port.  This identifies a remote peer that
   appears to be able to make its way to the UDP socket, all the way
   through the NAPT and firewalls at the destination end.

7.3.  Sending and Receiving the Seen Flag

   When a Probe arrives at a 6bed4peer, it MUST look if the sending IPv4
   address and UDP port have recently received any traffic.  If so, the
   Probe will be processed into a timer/state product.



Van Rein                Expires January 10, 2021               [Page 20]

Internet-Draft                    6bed4                        July 2020


   Starting with the time of arrival, a hole can be reliably assumed to
   be open in local NAPT, and that it remains open for 30 seconds (or a
   locally overridden timeout) after the last direct send to that
   remote, even if it was just a Probe or Keepalive.

   The time for the open hole is subdivided as follows:

   o  1 second accounts for a message delay in both directions;

   o  27 seconds account for the time that the remote peer may send
      directly;

   o  the remaining time allows informing the other side that a Probe
      arrived.

   when a NAPT hole is assumed to be open for 30 seconds, then this
   remaining time amounts to 2 seconds.  This time period, added to the
   time of the last message sent to that remote, indicates a period in
   which the Seen flag can be sent to the remote.  The remaining time
   may be negative, in which case the Sent flag is never sent to the
   remote.  When the local NAPT holes are set to be open for longer
   periods, then the Seen flag is sent correspondingly longer.

   The Seen flag can be set in any Traffic Class that adheres to the
   format for the 6bed4 network.  It does not matter if it is relayed
   through one or two 6bed4routers, because it informs about the direct
   connectivity between terminating 6bed4peers, whose IPv4 address and
   UDP port must occur in the bottom half of addresses if direct peering
   is to be considered at all.

   It is an event when the Seen flag arrives from a 6bed4peer, even from
   a 6bed4router, when it occurs in a Traffic Class that adheres to the
   format for the 6bed4 network.  In case of this event, the destination
   6bed4peer may conclude that it can use direct peering to the remote
   6bed4peer for 27 seconds after arrival of the Seen flag.  In active
   direct peering connections, the Seen flag is likely to be present on
   most frames, causing the regular reset of the 27-second timer.

7.4.  Peer NAPT State

   Every 6bed4peer keeps some state for its remote peers.  In contrast,
   the 6bed4router is a simple stateless process.  The state kept per
   remote peer is known as Peer NAPT State, and is indexed by the IPv4
   address and UDP port for the remote peer.

   The information kept for each remote peer consists of:

   o  A current state and related timeout



Van Rein                Expires January 10, 2021               [Page 21]

Internet-Draft                    6bed4                        July 2020


   o  A time for the last message sent

   o  A time for the last message sent directly

   o  A time until which the Seen flag is reported

   o  A /64 or /114 prefix for local address binding (once known)

   There is no explicit time until which direct peering is possible;
   this is instead derived from the current state.

   This information differs from 6bed4router state, which minimally
   requires just a /114 prefix and a timer until the next Keepalive
   needs to be sent.  If so desired, the Keepalive timer can be reset
   when a message is sent to the 6bed4router without risking to reduce
   reliability.

7.5.  State/Timer Diagram

   The Peer NAPT State for a 6bed4peer follows the following state
   diagram with default progression timeouts to administer sender state:


                   First.Send
                      |
                      V
                       INIT --1s--> INIT --1s-->.<------+
                       |            |           |       |
                       V            V           |       |
   Seen.Flag         Probe        Probe         |      25s
       |                                        |       |
       V                                        V       |
        PEER---25s---> POLL --1s--> POLL --1s--> FAIL --+
                       |            |            |
                       V            V            V
                     Probe        Probe        Probe


   This section describes the flow of this state/timer diagram for the
   Proper Peering, which is the default peering policy.  The next
   section describes the modifications for the other peering policies.

   The transitions marked 1s and 25s represent a default transition to
   occur after 1 and 25 seconds in the state, respectively.  Timeouts
   for NAPT holes below 28 seconds MAY be rejected by a 6bed4peer; if
   not, it MUST split the 25 second delays into values less that the
   NAPT hole timeout and send Keepalives at the extra points.  The total
   time MUST however be kept at 25 seconds.



Van Rein                Expires January 10, 2021               [Page 22]

Internet-Draft                    6bed4                        July 2020


   First.Send marks the entry point to the diagram, used when initiating
   new Peer NAPT State for a remote 6bed4peer that had no such state
   managed yet.  When entering FAIL state after a reasonable period with
   no traffic sent to the remote peer, the Peer NAPT State may be
   removed from administration.  What counts as a "reasonable period"
   may be locally selected, but would normally be in the range of tens
   of seconds.

   Seen.Flag marks the point of reset of the state when a Seen flag is
   set for traffic from this remote.  When connections are actively
   used, this flag would occur on most frames, causing repeated resets
   of this state diagram.

   Probe marks the side-effect of sending a Probe upon entry of a state.
   The intention of the Probe is to open a hole in outgoing NAPT and, at
   the same time, to reach the remote peer directly and trigger the
   return of a Seen flag.

   The states in the diagram should be read as follows:

   INIT  marks the intention to work towards reliable direct peering.  A
      total of 3 Probes is sent to allow reasonable opportunity for the
      remote peer to detect it and send a Seen flag.

   PEER  marks reliably direct peering for a duration of 27 seconds
      (continued into POLL states).  Having established in hole in local
      NAPT, no need for further Probes exists.

   POLL  still marks reliable direct peering, but also starts to send
      Probes because the hole in NAPT is assumed to be timing out soon.
      The Probes are hoped to trigger new Seen flags, and are especially
      useful during one-directional transmissions.  However, when no
      traffic is passed at all there is nothing to carry the Seen flag,
      and the state diagram continues.

   FAIL  marks durable failure to cause a Seen flag to be returned from
      the remote peer.  This does not imply that the hole in NAPT
      towards that peer has been closed however; with 25 seconds between
      Probes, the hole would be kept open.  TODO:SETTING.  Because
      Probes have no IPv6 header, there is no vessel for Seen flags, so
      connections are setup to close after a reasonable time of
      inactivity.

7.6.  Differentiation through Peering Policies

   When a Traffic Class passes into and over the 6bed4 network, and its
   format is that defined for the 6bed4 network, then it may specify a




Van Rein                Expires January 10, 2021               [Page 23]

Internet-Draft                    6bed4                        July 2020


   peering policy.  In other cases, the default peering policy applies,
   which is Proper Peering.

   Peering Policies define how the choice between direct peering and the
   source's 6bed4router is made:

   Proper Peering  defines the default behaviour as described in the
      previous paragram.

   Prohibited Peering  does not interact with Peer NAPT State or its
      State/Timer diagram.  Instead, traffic is always forwarded to the
      source's 6bed4router.

   Presumptious Peering  forces direct peering during the INIT states,
      but has the default behaviour in all other states.  When the frame
      causes creation of Peer NAT State, the First.Send entry point is
      used, but the first Probe MAY be dropped because the frame causing
      it takes its place.

   Persistent Peering  forces direct peering in all states, but triggers
      errors instead of sending while residing in the FAIL state.

   There is only one Peer NAPT State for a given remote peer; this same
   diagram applies to all the peering policies, and may be modified by
   it.  This allows traffic from a variety of peering policies and a
   variety of connections to share one knowledge base about direct
   peering.

7.7.  Bindable Local Prefix

   The Peer NAPT State holds a prefix, which is either the unspecified
   address 0::0, a /64 prefix followed by 64 zeroed bits, or a /114
   prefix.

   The initial state depends on the purpose; when a 6bed4peer is
   contacted from an already-used source IPv6 prefix, then the full /114
   may be copied to it.  When initiating the contact through a Router
   Solicitation to the remote 6bed4peer, it is set to a /64 prefix to be
   shared, or to 0::0 if the prefix of the remote 6bed4peer is to be
   assumed.

   Upon arrival of an initial Router Advertisement from a remote
   6bed4peer, the /64 in the prefix is only updated when it was 0::0;
   the following IPv4 address and UDP port in the bottom half are always
   copied.  The last 14 bits with the lanid are left zero.

   Until the /114 prefix is complete, it is not possible to bind a local
   address for traffic to the remote 6bed4peer, let alone use it as a



Van Rein                Expires January 10, 2021               [Page 24]

Internet-Draft                    6bed4                        July 2020


   source address.  Only after the /114 prefix is known is it possible
   to select lanid values to complete the IPv6 address.

   After binding has occurred, a corrective Router Advertisement may
   overwrite the IPv4 address and UDP port in the bottom half of this
   binding prefix.  This marks a change, and any further attempts to
   send to this remote peer from a previously bound source IPv6 address
   with different IPv4 address and UDP port in its bottom half are
   rejected by the 6bed4peer.  TODO:CODE

   This undesirable situation blocks further direct peering and requires
   a fallback to the 6bed4router, whose connection is kept open through
   Keepalives.  The same approach can only work between 6bed4peers when
   both send Keepalives to each other, but this may be wasteful in many
   scenarios, especially when normal traffic flows regularly.  Also note
   that what worked for setting up direct peering once is likely to work
   again later.

7.8.  Benefiting from Adaptive Flags

   The 6bed4 network is concerned with routing and peering policy; this
   is used by applications, whose logic may be so courteous that it does
   not matter if a locally bound address changes.  In terms of the
   Socket API this would be the case when neither bind() nor
   getsockname() are ever called.

   Such ambivalence to the locally bound address can be a benefit when
   NAPT mappings alter on a given connection.  It may help the number of
   direct peering successes to signal that such an address change does
   not matter to the application logic.  To this end, the Adaptive flag
   can be set in frames submitted through a 6bed4peer, at the same time
   as the desired Peering Policy.

   When this flag is set, the behaviour in case of a mismatched prefix
   for the remote peer is not to reject the traffic, but instead to
   substitute the IPv4 address and UDP port in the source IPv6 address
   of a frame; the /64 prefix should match as always, and the lanid is
   not altered.

   The address change is not reversed in the destination IPv6 address of
   reply traffic.  This means that the application would receive the
   altered address.  If this could otherwise lead to confusion, the
   application might choose to match reply traffic on the basis of a
   unique lanid or a random Flow Label.

   It is up to the application if this is possible, and in which frames
   sent.  The safe default is to not allow Adaptive source IPv6




Van Rein                Expires January 10, 2021               [Page 25]

Internet-Draft                    6bed4                        July 2020


   addresses, but as long as it is usually beneficial to set the
   Adaptive flag whenever it is of no concern to application logic.

8.  Global Routing of TBD1::/32

   TODO: SOLVE A FILTER ON AUTHORITATIVE GATEWAY ROUTERS

   HINTS FILE OPTION: Distribute the IPv4 addresses of gateway routers
   as part of the 6bed4router software, as is done for DNS root name
   servers.

   DNS OPTION: Define 32.gateway.6bed4.net to hold /32 gateways, and
   perhaps <IPv4/16>.48.gateway.6bed4.net to hold /48 gateways.  These
   gateways are trusted by 6bed4routers.  The only thing these gateways
   do is to relay native IPv6 prefix TBD1::/32 from/to the 6bed4
   network.  The IPv4/UDP is always that of the 6bed4router and the
   standard UDP port TBD2.

   6TO4 OPTION??? Compare to https://labs.ripe.net/Members/
   emileaben/6to4-why-is-it-so-bad -- the main problem of 6to4 is
   firewalls not being setup for it, especially --
   https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really --
   if it is pushed through without asking users.  Note that a 6bed4peer
   may also run on a LAN, but only announces an address prefix when
   Router Solicitation responds.  The 6bed4router should however route
   properly... which is more easily established when it integrates into
   a router device where it has access to external interfaces and/or
   firewall rules.  Given that, even using 2002::/16 instead of
   TBD1::/32 and routing backend traffic over proto-41 might be an
   option?  But it has fallen in disgrace, even if only the anycast/
   unicast mixup of router setups appears to have been a cause and
   anycast was deprecated for 6to4.  Still, there is the issue of
   firewall traversal (that we solve by demanding a public IPv4 address
   and fixed UDP port for 6bed4routers).

9.  IANA Considerations

   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.3.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.





Van Rein                Expires January 10, 2021               [Page 26]

Internet-Draft                    6bed4                        July 2020


   This specification also reserves Port TBD2 from the pools of UDP
   ports, TCP ports and SCTP ports, subject to possible updates in
   follow-up specifications.

   The port TBD2 will be the port on which 6bed4routers 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.

   [[CREF1: Requests to IANA / to be removed after processing: The
   requested assignment for TBD1 is 2001:64, so TBD1::/32 allocates
   2001:64::/32 from 2001::/23 which is suggested (with the 6BONE
   example) in RFC 2928 and https://www.iana.org/assignments/ipv6-
   unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
   The requested assignment for TBD2 is 25790, which is what we
   currently use in our code and experimental deployments.  As per RFC
   6335, this will probably be assigned under IETF Review or IESG
   Approval _or_ Expert Review, all defined in RFC 5226.  Note that IETF
   Review is banned for independent submissions under https://www.rfc-
   editor.org/about/independent/ and IESG Approval is not a very common
   procedure.  For Expert Review, it is necessary to document clearly
   that a Dynamic Port is required; this is the case because clients
   have no means to infer the port at which to contact a server or a
   peer.  Especially for peers, whose addresses are inferred from their
   IPv6 address within the 6bed4 address space, there is no derivation
   mechanism for these ports; and it is the ability to communicate
   directly with peers that sets this mechanism apart as extremely
   scalable and apt for VoIP applications.  --Rick]]

10.  Security Considerations

   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



Van Rein                Expires January 10, 2021               [Page 27]

Internet-Draft                    6bed4                        July 2020


   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.

11.  Acknowledgements

   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
   6bed4router, 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.

   Many thanks to Henri Manson for supporting me over a long time in
   experimental development and many, many tests.

   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



Van Rein                Expires January 10, 2021               [Page 28]

Internet-Draft                    6bed4                        July 2020


   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.

12.  Normative References

   [BCP38]    Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [IEEE-EUI64]
              IEEE, "Guidelines for 64-bit Global Identifier (EUI-
              64TM)", December 2013.

   [POTAROO]  Huston, G., "Testing Teredo", April 2011,
              <http://www.potaroo.net/ispcol/2011-04/teredo.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2372]  Evans, K., Klein, J., and J. Lyon, "Transaction Internet
              Protocol - Requirements and Supplemental Information",
              RFC 2372, July 1998.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.

   [RFC3095]  Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
              Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le,
              K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K.,
              Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header
              Compression (ROHC): Framework and four profiles: RTP, UDP,
              ESP, and uncompressed", RFC 3095, July 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/info/rfc3168>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.





Van Rein                Expires January 10, 2021               [Page 29]

Internet-Draft                    6bed4                        July 2020


   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513,
              DOI 10.17487/RFC3513, April 2003,
              <https://www.rfc-editor.org/info/rfc3513>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <https://www.rfc-editor.org/info/rfc4193>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380, February
              2006.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC5175]  Haberman, B., Ed. and R. Hinden, "IPv6 Router
              Advertisement Flags Option", RFC 5175,
              DOI 10.17487/RFC5175, March 2008,
              <https://www.rfc-editor.org/info/rfc5175>.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.




Van Rein                Expires January 10, 2021               [Page 30]

Internet-Draft                    6bed4                        July 2020


   [RFC6169]  Krishnan, S., Thaler, D., and J. Hoagland, "Security
              Concerns with IP Tunneling", RFC 6169, April 2011.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, December 2011.

   [RFC6496]  Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-
              Martinez, "Secure Proxy ND Support for SEcure Neighbor
              Discovery (SEND)", RFC 6496, February 2012.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.

   [RFC7059]  Steffann, S., van Beijnum, I., and R. van Rein, "A
              Comparison of IPv6-over-IPv4 Tunnel Mechanisms", RFC 7059,
              November 2013.

Author's Address

   Rick van Rein
   OpenFortress B.V.
   Haarlebrink 5
   Enschede, Overijssel  7544 WP
   The Netherlands

   Email: rick@openfortress.nl
























Van Rein                Expires January 10, 2021               [Page 31]