%% You should probably cite draft-vanrein-6bed4-04 instead of this revision.
@techreport{vanrein-6bed4-03,
    number =    {draft-vanrein-6bed4-03},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-vanrein-6bed4/03/},
    author =    {Rick van Rein},
    title =     {{6bed4: Peer-to-Peer IPv6 on Any Internetwork}},
    pagetotal = 31,
    year =      2017,
    month =     feb,
    day =       27,
    abstract =  {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.},
}