idnits 2.17.1 draft-vanrein-6bed4-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 805 has weird spacing: '...Peering has b...' == Line 810 has weird spacing: '...Peering has b...' == Line 814 has weird spacing: '...Peering has b...' == Line 821 has weird spacing: '...Peering has b...' == Line 1079 has weird spacing: '...Peering defin...' == (3 more instances...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (July 9, 2020) is 1380 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE-EUI64' is defined on line 1321, but no explicit reference was found in the text == Unused Reference: 'POTAROO' is defined on line 1325, but no explicit reference was found in the text == Unused Reference: 'RFC2372' is defined on line 1331, but no explicit reference was found in the text == Unused Reference: 'RFC3095' is defined on line 1341, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 1353, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 1372, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 1383, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 1387, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 1390, but no explicit reference was found in the text == Unused Reference: 'RFC4960' is defined on line 1394, but no explicit reference was found in the text == Unused Reference: 'RFC5175' is defined on line 1397, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 1402, but no explicit reference was found in the text == Unused Reference: 'RFC6455' is defined on line 1409, but no explicit reference was found in the text == Unused Reference: 'RFC6496' is defined on line 1412, but no explicit reference was found in the text == Unused Reference: 'RFC6724' is defined on line 1416, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 5 errors (**), 0 flaws (~~), 25 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Van Rein 3 Internet-Draft OpenFortress B.V. 4 Intended status: Informational July 9, 2020 5 Expires: January 10, 2021 7 6bed4: IPv6 Anywhere in support of Reliable Peering 8 draft-vanrein-6bed4-04 10 Abstract 12 The purpose of 6bed4 is to support IPv6-only networks, hosts and 13 applications. It passes IPv6 frames over UDP between IPv4 sites. 14 Peers connected over 6bed4 can switch to direct routes over UDP/IPv4 15 after deducing that this will be reliable. 17 6bed4 lets peer-to-peer applications benefit from transparant 18 addressing in IPv6 and delegates NAPT concerns to 6bed4. It is 19 possible to use 6bed4 as a fallback for IPv6, or as an additional 20 route. Servers can be setup as IPv6-only servers with NAT64 for 21 IPv4-only customers who only need client-server facilities, and add a 22 6bed4router to also facilitate reliable peer-to-peer protocols. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 10, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Address Format . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Protocol Description . . . . . . . . . . . . . . . . . . 4 62 2.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. 6bed4 Network Components . . . . . . . . . . . . . . . . . . 6 64 3.1. IPv6 Address Validation . . . . . . . . . . . . . . . . . 6 65 3.2. Router Solicitation and Advertisement . . . . . . . . . . 6 66 3.3. Network Prefixes . . . . . . . . . . . . . . . . . . . . 7 67 3.3.1. Native /64 Prefixes . . . . . . . . . . . . . . . . . 8 68 3.3.2. Locally Routed fc00::/7 Prefixes . . . . . . . . . . 8 69 3.3.3. The 6bed4 fc64::/16 and TBD1::/32 Prefixes . . . . . 9 70 4. The 6bed4peer Component . . . . . . . . . . . . . . . . . . . 10 71 4.1. 6bed4peer Forwarding . . . . . . . . . . . . . . . . . . 10 72 4.2. 6bed4peer Filtering . . . . . . . . . . . . . . . . . . . 12 73 5. The 6bed4router Component . . . . . . . . . . . . . . . . . . 13 74 5.1. 6bed4router Filtering . . . . . . . . . . . . . . . . . . 14 75 5.2. 6bed4router Forwarding . . . . . . . . . . . . . . . . . 15 76 5.3. Combining 6bed4peer and 6bed4router Functions . . . . . . 16 77 6. Peering Policies . . . . . . . . . . . . . . . . . . . . . . 16 78 7. Reliable Peering . . . . . . . . . . . . . . . . . . . . . . 19 79 7.1. Reliable 6bed4router Uplinks . . . . . . . . . . . . . . 19 80 7.2. Probing for Direct Peering . . . . . . . . . . . . . . . 20 81 7.3. Sending and Receiving the Seen Flag . . . . . . . . . . . 20 82 7.4. Peer NAPT State . . . . . . . . . . . . . . . . . . . . . 21 83 7.5. State/Timer Diagram . . . . . . . . . . . . . . . . . . . 22 84 7.6. Differentiation through Peering Policies . . . . . . . . 23 85 7.7. Bindable Local Prefix . . . . . . . . . . . . . . . . . . 24 86 7.8. Benefiting from Adaptive Flags . . . . . . . . . . . . . 25 87 8. Global Routing of TBD1::/32 . . . . . . . . . . . . . . . . . 26 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 90 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 91 12. Normative References . . . . . . . . . . . . . . . . . . . . 29 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 94 1. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2. Introduction 102 Several tunnels for IPv6 have been proposed [RFC7059]; the novelty of 103 6bed4 is that it allows the assumption that IPv6 is everywhere; not 104 only can it be implemented for hosts or networks, but even inside an 105 application. As a result, application developers can rely on 106 transparant IPv6 addressing, even when their code is distributed over 107 a network that may include IPv4-only users. Currently unsupported 108 use cases such as SIP/RTP, direct file transfer and other peer-to- 109 peer protocols can benefit from the relative simplicity of this model 110 and the knowledge that traffic either transfers directly between 111 peers, or reflects through a relay of the user's choosing. 113 To carry IPv6 anywhere, 6bed4 transports it as a UDP payload, 114 contained in UDP/IPv4. The UDP port and IPv4 address are derived 115 from the IPv6 address on sending, and validated to match upon 116 arrival. This means that much of the 6bed4 infrastructure can be 117 stateless, like a router. In addition, IPv4 attackers are still 118 traceable when they use 6bed4 to step up to IPv6. 120 The 6bed4 network consists of any number of 6bed4peers running IPv6 121 applications and usually a 6bed4router that defines a prefix under 122 which it reliably connects peers, and through which it may route to 123 and from native IPv6 addresses. To optimise routing, one 6bed4peer 124 may choose to access multiple 6bed4routers, but automatic detection 125 of crossover between 6bed4peers under different 6bed4routers is also 126 possible. 128 2.1. Address Format 130 The structure of a 6bed4 address may involve a specialised top half 131 structure in the /64 prefix and/or a specialised bottom half 132 structure following it. The format of a 6bed4 address with both 133 specialised parts is: 135 | 32 bits | 32 | 50 | 14 | 136 +----------+---------------------+-------------------------+-------+ 137 | prefix | 6bed4router address | direct 6bed4peer address| lanid | 138 +----------+---------------------+-------------------------+-------+ 140 Whether the top half is a 6bed4 address depends on the prefix. The 141 prefix TBD1::/32 globally defines a 6bed4 address, and supports 142 routing across the Internet. Prefixes fc64:::/32 for any 143 are interpreted as 6bed4 addresses when they occurs on the 144 6bed4 network, but this interpretation cannot be generally 145 prescribed. These /32 prefixes permit the interpretation of the top 146 half, where bits 32..64 hold the IPv4 address of a 6bed4router that 147 can further relay the traffic. Any IPv6 router may pass TBD1::/32 by 148 forward the IPv6 packet over UDP/IPv4 to port TBD2 and the address in 149 the IPv6 top half. 151 Any /64 prefix that is a destination address on the 6bed4 network 152 must adhere to this format for the lower half. These are prefixes 153 announced by 6bed4router and 6bed4peer components, extended to a /114 154 in a Router Advertisement and having the L and A flags set. Traffic 155 with a 6bed4peer source address never came from a routed backend, so 156 source addresses arriving over direct peering instead of from a 157 subscribed-to 6bed4router can also be considered to have a 6bed4 158 lower half. This lower half contains the IPv4 address and UDP port, 159 as observed by an addressed party. 161 2.2. Protocol Description 163 The role of a 6bed4router is to be the defining home for one /64 164 prefix and potentially connect to other IPv6 addresses. It binds a 165 UDP socket to a static IPv4 address and the standard UDP port TBD2. 167 Every 6bed4peer opens a UDP socket and is identified by one or more 168 external pairs of an IPv4 address and UDP port. The UDP socket is 169 seen as a /64 prefix, usually obtained from a 6bed4router, extended 170 into to as many /114 prefixes as the 6bed4 network has external 171 address/port pairs for its UDP/IPv4 socket. 173 When a 6bed4peer desires to run under the /64 prefix of a given 174 6bed4router, it sends a Router Solicitation to its UDP/IPv4 address. 175 The response is an initial Router Advertisement that offers a /114 176 prefix, consisting of the /64 of the 6bed4router externded with the 177 UDP/IPv4 address of the 6bed4peer, as observed by the 6bed4router. 178 This /114 must be used as the source address in future communications 179 with that 6bed4router. A 6bed4peer sends Keepalive messages to keep 180 the NAPT mapping towards the 6bed4router open as a reliable 181 bidirectional routing path. 183 When attempting direct peering, the UDP/IPv4 destination address of a 184 remote 6bed4peer is collected from its /114 and a direct UDP/IPv4 185 message is attempted. This may or may not succeed, so the initial 186 attempt is usually a Probe that may result in a future report of a 187 Seen flag. In reliable modes of operation, the initial traffic is 188 sent through the 6bed4router until it learns that direct peering is 189 possible; more agressive but less reliable peering policies are 190 defined as alternatives. 192 Traffic on the 6bed4 network is validated to hold an IPv6 source 193 address with a lower half mentioning the source UDP/IPv4 address. 194 Failure to match rejects the message with a corrective Router 195 Advertisement in return. This allows a 6bed4peer to communicate 196 directly with any 6bed4peer, and to learn of another external UDP/ 197 IPv4 address for its UDP socket in relation to other network 198 components. 200 2.3. Use Cases 202 The 6bed4peer can be run for a network, a machine or even a single 203 application. It can add IPv6 to any machine that supports IPv4, 204 whether it already supports IPv6 or not. 206 The 6bed4router can share a /64 prefix to any number of 6bed4peer 207 nodes. It may offer additional routes to network regions that can 208 route back to this /64 prefix, including an offering of a default 209 route if the shared prefix is globally routable. 211 Applications may benefit from the certainty that IPv6 is available, 212 especially when they run their own 6bed4 network. They would 213 normally want to connect to a 6bed4router at its specified IPv4 214 address and UDP port TBD2 and obtain a /114 prefix holding their own 215 IPv4/UDP address. The final 14 lanid bits allow a range of addresses 216 to divide as the 6bed4peer sees fit. 218 Peer-to-peer applications may prefer to evade the 6bed4router and 219 prefer direct peering, at least when both peers are known to use 220 6bed4 address bottom halves. This may not always succeed, mostly 221 dependent on NAPT properties which cannot generally be solved. The 222 desired peering policy can be specified in each frame, and peering 223 success or failure can be learnt from received frames, so preferences 224 among alternative routes could be based on peering properties. 226 The reliable and desired-direct approaches can be mixed, because the 227 peering policy is separately set in the traffic class for each IPv6 228 frame. An application might connect (perhaps with SIP) through a 229 6bed4router and use a direct-peering data path (perhaps with RTP) 230 afterwards. It is possible to bind to another address for RTP than 231 for SIP, and the addition of Keepalive messages can even support non- 232 symmetric RTP streams; all this can help to find direct routes where 233 they are possible, and thus rely on a minimum of fallback routing 234 through the 6bed4router. 236 3. 6bed4 Network Components 238 This section describes common aspects that apply to 6bed4peers as 239 well as 6bed4routers. Later sections specify aspects that these 240 components add. 242 Every component on the 6bed4 network opens a UDP port over which it 243 sends and receives IPv6 frames. The further processing of these 244 frames depends on the component. 246 3.1. IPv6 Address Validation 248 Upon arrival of an IPv6 frame over UDP/IPv4, the IPv6 source (and 249 destination) address is verified. This usually involves testing an 250 IPv6 address to have a lower half containing an IPv4 address and UDP 251 port, almost in network bit order. The lower half must follow this 252 format: 254 | 6 | 2 | 24 | 16 | 2 | 14 | 255 -+-------------+-------+--------------+-------+-------------+-------+ 256 | IPv4 [0..5] | EIU64 | IPv4 [8..31] | UDP | IPv4 [6..7] | lanid | 257 -+-------------+-------+--------------+-------+-------------+-------+ 259 The IPv4 address is split into portions [N..M] with bits N to M, 260 counting from 0 for the high end. The IPv4 address effectively has 261 two bits taken out to conform to the EUI-64 address format [RFC3513]. 262 The overlaid IPv4 address bits follow after the UDP port. The last 263 14 bits form the lanid, which can be freely used on the component 264 bound to the given UDP port and IPv4, except for the value 0, which 265 is reserved for the 6bed4router for this IPv6 address. 267 3.2. Router Solicitation and Advertisement 269 When a local 6bed4 component intends to connect to a remote 6bed4 270 component, it may send a Router Solicitation [Section 4.1 of 271 [RFC4861]] to the IPv4 address and UDP port of the remote. The 272 prefix supplied can be used after the remote sends back a Router 273 Advertisement [Section 4.2 of [RFC4861]], the composition of which is 275 o Flags [Section 3 of [RFC5175]] are M=0, O=0, H=0, P=0. 277 o A prefix of length /114, where the /64 portion defines the 6bed4 278 network and the added 50 bits hold the local component's UDP port 279 and IPv4 address as observed by the remote 6bed4 component. The 280 trailing 14 bits are the lanid; lanid 0 is reserved for the 281 router, but the other 16383 values may be used freely by the local 282 component, perhaps through DHCPv6. 284 o Any number of routes, possibly including a default route. Any 285 route MAY be ignored by the local 6bed4 component. Routes only 286 make sense when the reachable prefixes can route traffic back to 287 the remote 6bed4 component; a 6bed4peer SHOULD NOT offer routes 288 because it is considered a terminal in the 6bed4 network, rather 289 than an authoritative source of routes. 291 Every component on the 6bed4 network SHOULD send a Router 292 Advertisement to correct an invalid bottom-half Section 3.1 in an 293 IPv6 source address. This allow the sending 6bed4 component to 294 correct its own idea of its externally observed UDP/IPv4 address, at 295 least towards the designated recipient. The bits that would change 296 are the bottom-half bits holding its IPv4 address and UDP port; note 297 that the lanid is always zero in a /114 prefix. 299 3.3. Network Prefixes 301 The 6bed4 network uses /114 prefixes for its destination addresses. 302 These addresses contain a UDP/IPv4 address in their bottom half, 303 following a /64 prefix in the address top half. The top half is 304 considered the identity of a 6bed4 network segment, as ususally 305 defined by a 6bed4router and sometimes by a 6bed4peer. The top half 306 never changes while processing a corrective Router Advertisement; it 307 does however get assigned by the initial Router Advertisement that 308 follows up on a Router Solicitation. 310 Even if a 6bed4peer obtains a /64 prefix from a 6bed4router as part 311 of a /114 in an initial Router Advertisement, and even though it is 312 not a router for that address, it may nonetheless use the /64 to 313 construct a /114 towards other 6bed4peers. This bottom-half logic is 314 a point where 6bed4 destination addresses have more semantics than 315 general IPv6. Two 6bed4peers may use Router Solicitation and/or 316 Router Advertisements to learn about each other's view on their 317 addresses. This behaviour is not required for reliable exchanges, 318 but it can help to pierce through more kinds of NAPT router; it is 319 why the /64 is said to describe a 6bed4 network, rather than just the 320 component that introduces it. 322 Typical for IPv6, there is some variation in use cases for different 323 prefix kinds. We distinguish native prefixes, locally routed 324 prefixes and specific 6bed4 prefixes. 326 3.3.1. Native /64 Prefixes 328 Every 6bed4 component can export a native /64 prefix, provided that 329 it can route to it and that the native prefix is routed back to it. 330 This facility allows sharing that prefix to connecting other 331 components; do note that no access control exists, but the bottom 332 half of an IPv6 address under the prefix reveals the validated UDP/ 333 IPv4 address of a source. 335 The top-half of a native prefix is not recognised as a 6bed4 address, 336 as it is not possible to extract a 6bed4router IPv4 address from it. 337 As a result, its traffic usually passes over native IPv6 routes. The 338 benefit of a publicly routable IPv6 address is that it can be used in 339 connections to arbitrary other IPv6 addresses that are also globally 340 routable. 342 Some hosts have only one /64 available, and may want to mix 6bed4 343 with services. Although invalid 6bed4 bottom halves (for instance, 344 UDP port 0) could be allocated for other uses than 6bed4, this is NOT 345 RECOMMENDED because it would break connectivity for other 6bed4 346 components when the prefix is passed through the 6bed4 network via 347 Router Advertisements. Instead, the RECOMMENDED procedure would be 348 to setup IPv6 addresses as available to a locally run 6bed4peer on a 349 fixated public IPv4 address and UDP port; the 6bed4 component 350 software may optimise handling for these purposes. 352 3.3.2. Locally Routed fc00::/7 Prefixes 354 Some IPv6 addresses have been allocated for local routing [RFC4193]. 355 The fc00::/7 prefix is divided into administratively assigned 356 fc00::/8 prefixes and randomly completed fd00::/8 prefixes. With the 357 exception of fc64::/16 discussed below, these addresses are locally 358 routed, also on a 6bed4 network. 360 Local routes cannot be used to communicate with native IPv6 address, 361 unless they happen to be aware of how to return the traffic. Such 362 native routes in the direct backend of a 6bed4router can be 363 explicitly mentioned in its Router Advertisement, even for a fc00::/7 364 prefix. 366 Locally routed addresses can only be communicated with the 6bed4 367 component that defines them. Because of this, they MUST NOT be 368 further transmitted through Router Advertisement; connections are 1:1 369 only. Whether this is a 6bed4peer to a 6bed4router (reliable) or a 370 6bed4peer to another 6bed4peer (not reliable) is a matter of 371 application or network configuration. 373 It is quite possible for a 6bed4peer to setup a random /64 prefix 374 based on fd00::/8, and peers might even form networks between such 375 addresses, possibly based on a distributed hash table. In such 376 networks, redundancy can be helpful to overcome unreliable direct 377 peering connections. As explained below, 6bed4 can support the 378 detection of reliability. 380 3.3.3. The 6bed4 fc64::/16 and TBD1::/32 Prefixes 382 The prefixes fc64::/16 and TBD1::/32 mark what are called 6bed4 383 prefixes. The fc64::/16 prefix receives an additional network 384 identifier to form fc64:::/32. These /32 prefixes are 385 used in a top half, whose format is completed with the IPv4 address 386 of a 6bed4router, in network byte order: 388 | 32 | 32 | 389 +--------------------------------+--------------------------------+- 390 | fc64: or TBD1 | IPv4 address of 6bed4router | 391 +--------------------------------+--------------------------------+- 393 The 6bed4router is responsible of knowing its public IPv4 address. 394 The fixed UDP port on which the 6bed4router provides its service MUST 395 be TBD2. As a result, a network component that can interpret the 396 prefix as a 6bed4 prefix can route the traffic over the 6bed4 397 network. For the TBD1::/32 prefix, this can be any party on the 398 Internet; for fc64::/16 it can only be assumed when the address is 399 found on the 6bed4 network. The added value of TBD1::/32 over 400 fc64::/16 therefore is that it expands the IPv6-everywhere 401 facilitation of 6bed4 from an overlay network to a globally routed 402 network. 404 The 6bed4router is vital in the reliability of the 6bed4 network: 406 o The 6bed4router is always reachable at its IPv4 address and the 407 fixed UDP port TBD2; 409 o The 6bed4router can always reach every 6bed4peer that subscribes 410 to its serviced prefix. 412 This means that a conservative route can always be made through a 413 6bed4router. This is also possible when the prefixes differ, either 414 in the IPv4 address or also in the /32 part. Within the constraints 415 of source address validation, it is possible to route traffic through 416 the 6bed4router covering the source prefix and the 6bed4router 417 covering the destination prefix; or it is possible to route traffic 418 through the 6bed4router of a destination node, after a source 419 6bed4peer (also) connects to the destination's 6bed4router. 421 Another value of the 6bed4 prefix is that they represent end points 422 on the 6bed4 network. This means that the bottom half can also be 423 interpreted and used for direct 6bed4 traffic. This usually works 424 best when the source address is then also chosen to be a 6bed4 425 address, which can be achieved under normal address binding rules 426 when a low-priority interface offers routes for fc64::/16 or 427 TBD1::/32 with a prefix under either. 429 4. The 6bed4peer Component 431 The 6bed4peer opens a UDP socket over which it sends and receives 432 IPv6 frames. The UDP remote end can be any number of 6bed4peers and/ 433 or 6bed4routers. A basic configuration would communicate with a 434 single 6bed4router which may be its default route to native IPv6 435 addresses, and as many 6bed4peers as it can connect to directly. 437 To be able to route under a 6bed4router's prefix, the 6bed4peer sends 438 a Router Solicitation and awaits an initial Router Advertisement 439 Section 3.2 to learn about its /114 prefix, which includes the /64 440 prefix provisioned by the 6bed4router. The 6bed4peer MAY configure 441 any additional routes provided in a Router Advertisement from a 442 6bed4router. Through the Router Advertisement, the 6bed4peer learns 443 about the external address of its UDP socket, as observed by the 444 6bed4router. Over this route, the 6bed4peer will send regular 445 Keepalive messages to keep the NAPT traversal open and guarantee a 446 reliable incoming route through the 6bed4router. A generally advised 447 minimum frequency for Keepalive messages is once in 30 seconds. 449 4.1. 6bed4peer Forwarding 451 To submit an IPv6 frame on the 6bed4 network, a 6bed4peer first 452 determines whether it can forward to a 6bed4router or directly to a 453 6bed4peer: 455 o When source and destination share the same /64 prefix, consider 456 direct routing as well as the 6bed4router. 458 o When the destination is a 6bed4 prefix and the source and 459 destination have different /64 prefixes, consider direct routing 460 as well as the 6bed4router. 462 o When the destination has another prefix (that was offered and 463 accepted as a route from a 6bed4router), consider going through 464 the 6bed4router. 466 When a direct route is considered, the default peering policy 467 Section 6 only uses direct peering when it is known to be reliable 468 Section 7. Other peering policies provide variations on a frame-by- 469 frame basis, to allow for maximum flexibility. When direct routing 470 is selected, any considerations of going through the 6bed4router are 471 dropped. 473 When considering the 6bed4router, the /64 prefix of the source 474 address determines which one to use. When the source and destination 475 have 6bed4 addresses with different /64, the traffic bounces through 476 both 6bed4routers, which is useful to validate the traffic for not 477 forging IPv6 addresses. To avoid this "trapeziums-shaped" routing, 478 it is also possible for a 6bed4peer to bind an address under the 479 destination address's 6bed4router by sending a Router Solicitation 480 and acquiring a /114 prefix to work from. The result would be only 481 one 6bed4router bouncing the traffic instead of two. Whether or not 482 this is done, direct peering may be discovered as reliable 483 alternative and either shape bypassed completely. 485 The IPv6 frame can now be sent over the 6bed4 network, from the UDP 486 socket held by the 6bed4peer. The remote UDP port and IPv4 address 487 are learnt from the bottom half of the destination IPv6 address. 488 Since a 6bed4peer is not supposed to route traffic, any source 489 address is supposed to be locally bound, therefore be a 6bed4 490 address, and so its bottom half is supposed to contain the external 491 view on its UDP port and IPv4 address. 493 Although it makes less sense for UDP than for TCP, NAPT middleware 494 may have imposed an Endpoint-Dependent Mapping [RFC4787], which means 495 that the external UDP port and IPv4 address observed by the 496 6bed4router form a reasonable initial guess when communicating 497 directly with other 6bed4peers, but there may be a need to correct 498 these aspects when communicating with such 6bed4peers. To this end, 499 a remote peer might send a corrective Router Advertisement and the 500 IPv6 frame would be lost. This should not happen when reliability 501 rules are obeyed, but it may happen for frames that select another 502 peering policy than the default. 504 Note how this opens degrees of freedom to the an application acting 505 as/via a 6bed4peer. For general TCP or SCTP, a first SYN or INIT 506 frame might be sent under a peering policy that enforces direct 507 peering, and fall back to reliable routing when resent. And a 508 application could send SIP messages over reliable patterns, but work 509 towards direct peering for RTP; a SIP/SDP offer can welcome RTP 510 traffic on a 6bed4 address, possibly using a 6bed4router in a SIP/SDP 511 offer that was just received; many SIP networks are closed, and could 512 opt to be IPv6-only networks, with 6bed4 as a reliable fallback 513 option. 515 4.2. 6bed4peer Filtering 517 Anyone might send packets to the UDP socket of a 6bed4peer, but not 518 all traffic should pass. Specifically, filtering on the IPv4/UDP 519 source address in relation to the IPv6 source address is necessary to 520 stop peers from claiming arbitrary IPv6 addresses. 522 Traffic without a full IPv6 header is exceptional, and considered to 523 be a Probe; an attempt to reach our UDP socket through direct 524 peering. This is not routed any further, but it counts as successful 525 input under direct peering. Usually sent before or after an IPv6 526 frame via the 6bed4router, it permits flagging that this direct input 527 succeeded on return traffic to that same 6bed4peer. 529 There are two reasons why an IPv6 header's source address might be 530 acceptable; it could be from a 6bed4router to which the receiving 531 6bed4peer maintains an uplink, or it might be a direct connection 532 from another 6bed4peer under the same 6bed4router. On top of this, a 533 third reason to accept an IPv6 header is when its source and 534 destination address together indicate that a bypass of a trapezium 535 route is made. 537 The 6bed4peer should know the 6bed4routers to which it maintains an 538 uplink; it needs this information for sending Keepalives that 539 maintain an open NAPT mapping. Each 6bed4router can be uniquely 540 identified by matching their IPv4 address and UDP port against the 541 UDP/IPv4 source address of an incoming frame. 543 A frame sent directly from another 6bed4peer working under the same 544 6bed4router will use a /64 prefix that we got from that 6bed4router. 545 As a result, we can rely on the bottom half address to contain a IPv4 546 address and UDP port, which MUST then match the source of the 547 incoming frame. When the /64 prefix matches but the bottom half does 548 not, a corrective Router Advertisement SHOULD be sent (possibly with 549 a limited frequency). TODO:REQUIRE_SRC/64_IS_DST/64? 551 The bypass for a trapezium route is more complicated. In this case, 552 the frame came from a 6bed4peer acting under another 6bed4router. 553 The frame was first passed to the source's 6bed4router and then the 554 destination's. When the latter delivers the frame at the 555 6bed4destination, the source and destination IPv6 address are used. 556 First, both addresses MUST be 6bed4 addresses, so have either the 557 fc64::/16 or TBD1::/32 prefix, in any combination. Second, the 558 6bed4router addresses in the top half are considered; the source 559 6bed4router address is assumed to have been validated by our 560 6bed4router; the destination 6bed4router address MUST be found as one 561 to which we maintain an uplink. Third, the source IPv4 address and 562 UDP port MUST be set in the bottom half of the source IPv6 address. 564 Fourth, our IPv4 address and UDP port according to our 6bed4router 565 (which is mentioned in the top half of the IPv6 destination address) 566 MUST match the bottom half of the IPv6 destination address. Failure 567 on any of these four conditions leads to discarding of the frame as a 568 suspect frame. 570 5. The 6bed4router Component 572 The 6bed4router is a stateless component. It can be reached reliably 573 on a static IPv4 address on the fixed UDP port TBD2, so it can be 574 reached by all 6bed4 components. If a NAPT mapping applies, it is a 575 static mapping. 577 Every 6bed4router defines its own /64 prefix and when this is a 6bed4 578 address its static IPv4 address is contained in the IPv6 address top 579 half that forms this prefix. In addition to the offered prefix, a 580 6bed4router may also exchange IPv6 frames with locally routable 581 prefixes and/or with globally routable prefixes anywhere on the 582 Internet. 584 Among the routes offered may be the default route ::/0. This is just 585 one of many possible routes. 587 Another seemingly special route is fc64::/16, which captures more 588 than just a specific fc64:::/32 that the 6bed4router may use 589 as its prefix. A route fc64::/16 states that other values 590 can be routed to the 6bed4router's connected network. Only the one 591 announced in the prefix is handled directly by the 6bed4router. 592 Again, there is no need to treat such cases in any special way. 593 TODO: BUT WE DO TREAT IT ESPECIALLY; IF NOT OUR IPV4 IS USED, WE 594 RELAY SUCH A PREFIX. SAME FOR TBD1::/32 BY THE WAY. 596 Traffic that arrives over the 6bed4 network is first filtered to be 597 properly formed. After this, one possible forwarding option is to 598 bounce the frame back into the 6bed4 network, but to another IPv4 599 address and UDP port. This is done to relay traffic between two 600 6bed4peers that share the 6bed4router's /64 prefix but that are not 601 (yet) able or willing to connect directly. It is also done to relay 602 traffic between two 6bed4routers if their 6bed4peers use different 603 /64 prefixes and are not (yet) able or willing to connect directly; 604 this situation is called trapezium routing and is effectively a 605 bypass for routing over IPv6, mostly to permit fc64::/16 prefixes to 606 work across 6bed4routers' prefixes. 608 5.1. 6bed4router Filtering 610 The 6bed4router is stateless, but it is careful about filtering 611 traffic before agreeing to route it. Different filtering rules are 612 applied on the IPv6 side of the 6bed4router than on the side of the 613 6bed4 network. 615 Traffic arriving at the IPv6 side is called return traffic. Traffic 616 arriving over the 6bed4 network can be routed for either local, 617 backend or first and second stage of trapezium routing. 619 Return traffic MUST be rejected unless: 621 o The destination IPv6 address matches the 6bed4router's defined /64 622 prefix; 624 o The bottom half of the destination IPv6 address does not mention 625 IPv4 address 0.0.0.0; 627 o The bottom half of the destination IPv6 address does not mention 628 UDP port 0. 630 Local routing applies when the IPv6 source and destination addresses 631 both use the /64 prefix defined by the 6bed4router. Local routing 632 MUST be rejected unless: 634 o The bottom half of the IPv6 source address mentions the IPv4 635 address and UDP port over which the frame arrived from the 6bed4 636 network; 638 o The bottom half of the IPv6 destination address does not mention 639 IPv4 address 0.0.0.0; 641 o The bottom half of the IPv6 destination address does not mention 642 UDP port 0. 644 Backend routing applies when the IPv6 source address uses the /64 645 prefix defined by the 6bed4router, while the IPv6 destination address 646 matches a route announced in Router Advertisements. TODO:CONSIDER_TR 647 APEZIUM_ROUTING_FOR_6BED4ADDRS_WITH_DIFFERENT_TOP_IPV4ADDR. Backend 648 routing MUST be rejected unless: 650 o The bottom half of the IPv6 source address mentions the IPv4 651 address and UDP port over which the frame arrived from the 6bed4 652 network. 654 The first stage of trapezium routing applies when the IPv6 source 655 address uses the /64 prefix defined by the 6bed4router, but the 656 desination IPv6 address neither suggests local or backend routing. 657 The first stage of trapezium routing MUST be rejected unless: 659 o The source and destination IPv6 addresses are both 6bed4 660 addresses, though not necessarily the same; 662 o The IPv6 source address matches the /64 prefix of the 6bed4router; 664 o The bottom half of the IPv6 source address mentions the IPv4 665 address and UDP port over which the frame arrived from the 6bed4 666 network; 668 o The bottom half of the IPv6 destination address does not mention 669 IPv4 address 0.0.0.0; 671 o The bottom half of the IPv6 destination address does not mention 672 UDP port 0. 674 The second stage of trapezium routing applies when the IPv6 675 destination address uses the /64 prefix defined by the 6bed4router, 676 but the source IPv6 address neither suggests local or backend 677 routing. The second stage of trapezium routing MUST be rejected 678 unless: 680 o The source and destination IPv6 addresses are both 6bed4 681 addresses, though not necessarily the same; 683 o The IPv4 address over which the frame arrived from the 6bed4 684 network matches the 6bed4router address in the top half of the 685 IPv6 source address; 687 o The UDP port over which the frame arrived from the 6bed4 network 688 is the standard port TBD2; 690 o The bottom half of the IPv6 destination address does not mention 691 IPv4 address 0.0.0.0; 693 o The bottom half of the IPv6 destination address does not mention 694 UDP port 0. 696 5.2. 6bed4router Forwarding 698 The 6bed4router terminates certain IPv6 destination addresses. These 699 addresses match the /64 prefix, and the bottom half defines the IPv4 700 address at which the 6bed4router can be reached, along with its 701 standard UDP port TBD2. Furthermore, any bottom half that specifies 702 lanid value 0 is considered to terminate at the 6bed4router. Such 703 addresses may have some special treatment for ICMPv6 traffic, but 704 most other traffic would be relayed to a local interface binding to 705 that address. In absense of such a binding, an ICMPv6 error may be 706 sent back. 708 Return traffic is relayed over the 6bed4 network to the IPv4 address 709 and UDP port found in the bottom half of the IPv6 destination 710 address. 712 Local traffic is relayed back over the 6bed4 network to the IPv4 713 address and UDP port found in the bottom half of the IPv6 destination 714 address. 716 Backend traffic is relayed into the backend, normally using the 717 routing table under which the 6bed4router operates. 719 The first stage of trapezium routing is relayed over the 6bed4 720 network to the 6bed4router address in the top half of the destination 721 IPv6 address and the standard UDP port TBD2. 723 The second stage of trapezium routing relays over the 6bed4 network 724 to the IPv4 address and UDP port found in the bottom half of the IPv6 725 destination address. 727 5.3. Combining 6bed4peer and 6bed4router Functions 729 It is possible for a single component to act both as a 6bed4peer and 730 a 6bed4router. The individual requirements for each apply, 731 specifically resolving potential conflicts with: 733 o The component MUST be externally reachable on a static IPv4 734 address at the standard UDP port TBD2; 736 o When sending a Router Advertisement, it MUST NOT provide 737 additional routing information. 739 6. Peering Policies 741 The IPv6 frame that travels over the 6bed4 network, so between 6bed4 742 components, can express its preferred peering policy. This is 743 expressed through the Traffic Class, which is spread over two bytes 744 in the IPv6 header. The value of the Traffic Class is generally 745 considered [RFC2474][RFC3168] to follow this structure: 747 | 6 | 2 | 748 +--------------+-----+ 749 | DS | ECN | 750 +--------------+-----+ 752 Part of the DS field is interpreted [RFC2474] as a Class Selector CS: 754 | 3 | 3 | 2 | 755 +--------+-----+-----+ 756 | CS | 000 | ECN | 757 +--------+-----+-----+ 759 On the 6bed4 network, the interpretation of CS is further split into 760 a two-bit peering policy PP and a Seen flag S: 762 | 2 | 1 | 3 | 2 | 763 +----+---+-----+-----+ 764 | PP | S | 000 | ECN | 765 +----+---+-----+-----+ 767 The PP and S values may be retained when a frame exits a 6bed4peer 768 and arrive at an application. The Seen flag expresses that direct 769 peering from this side to the source address recently succeeded, even 770 if just as a Probe. This means that direct peering to the IPv6 771 source address is considered reliable for 27 seconds from the arrival 772 of the frame with the Seen flag. The 6bed4peer normally takes note 773 of this flag, and modifies its peering behaviour accordingly. 775 Before entry into the 6bed4 network, so in the application that 776 constructs the IPv6 frame to be relayed through a 6bed4peer, the 777 peering policy PP indicates the desired peering policy, but the Seen 778 flag has no meaning yet; its place is taken by Adaptive flag A: 780 | 2 | 1 | 3 | 2 | 781 +----+---+-----+-----+ 782 | PP | A | 000 | ECN | 783 +----+---+-----+-----+ 785 The Adaptive flag expresses that the IPv4 address and UDP port in the 786 bottom half of the source IPv6 address may be modified at will. When 787 local NAPT performs Endpoint-Dependent Mapping it would map the same 788 UDP socket to different external address/port combinations for 789 different remote peers. Normally, this makes the reliable traffic 790 fall back on the 6bed4router, because there is no basis of trust for 791 the remote that two seemingly different peers map to the same UDP 792 socket and hence to the same 6bed4peer. Through Adaptive source 793 addresses, a prefix supplied through a corrective Router 794 Advertisement in the past can be used to construct a suitable source 795 address. Other than the Adaptive flag, the 6bed4peer needs no 796 instructions to do this. The application may learn the new address 797 from replies to a frame sent with the Adaptive flag. It is then free 798 to adopt the address and continue without an Adaptive flag, or to 799 continue and even allow connected updates to the address when NAPT 800 changes state. If and when this can work is up to the application 801 logic. 803 The four peering policy (PP) values defined for 6bed4 are: 805 Proper Peering has bit value 00 or decimal value 0 and is the 806 default. This policy routes through the source's 6bed4router when 807 direct peering has not been detected to be reliable, but as soon 808 as it is considered reliable it switches to direct peering. 810 Prohibited Peering has bit value 01 or decimal value 1. This policy 811 prohibits direct peering and will always route through the 812 source's 6bed4router. 814 Presumptious Peering has bit value 10 or decimal value 2. At the 815 expense of reliability, this policy tries direct peering for a few 816 seconds. If reliability is not achieved within these seconds, it 817 falls back to the same behaviour as Proper Peering, which can also 818 route through the 6bed4router. Until that fallback however, 819 traffic may be lost. 821 Persistent Peering has bit value 11 or decimal value 3. At the 822 expense of reliability, this policy tries direct peering for a few 823 seconds. If reliability is not achieved within these seconds, it 824 persists in this behaviour but will report errors, either with 825 return values or through occasional ICMPv6 errors. This policy is 826 the most likely to drop traffic. 828 These values can be chosen on a frame-by-frame basis without damage 829 to the logic that learns about the reliability of direct peering. 830 Applications being aware of the meaning in a protocol of each frame, 831 may choose to use less reliable delivery modes for application- 832 specific purposes. 834 7. Reliable Peering 836 Given the nature of NAPT, there can be no completely reliable peering 837 system without a fallback to a services that bounces traffic. This 838 is why a 6bed4 network needs the fallback option of a 6bed4router to 839 offer reliable routing. When NAPT is enhanced with port forwarding, 840 this situation can be changed, and some applications may implement so 841 many alternative routing options that full reliability might be 842 waived. This is why special situations might be created to work 843 reliably without a 6bed4router. However, when 6bed4 is built into an 844 application that should "just work", it does need the fallback 845 6bed4router to be reliable. 847 The 6bed4 network can reliably switch to direct peering after a 848 successful peering handshake. This is a deductive approach to NAPT 849 traversal, and is achieved simply by trying direct peering and 850 observing if it arrives. The lesson taken from prior inductive 851 approaches [RFC4380] founded on classification of NAPT [RFC3489] was 852 that such an approach can easily misclassify NAPT behaviour, ensuing 853 in brittle IPv6 connectivity. 855 The decuction in 6bed4 is mostly through properties of UDP. 856 Specifically, the absense of a protocol identifier disables 857 interpretation of the protocol behaviour by NAPT, unless bold 858 assumptions are made on the basis of a port number. To be workable, 859 a NAPT therefore must keep an outward-sending UDP port open for 860 response traffic. For some protocols, the response may come from 861 other angles, which suggests that Endpoint-Dependent Mapping is not 862 suitable for UDP, but this cannot be assumed in general. A certain 863 amount of acceptable silence until the given connection closes can 864 however be assumed, and it is commonly suggested that this should be 865 at least 30 seconds. The only assumption made by 6bed4 is that these 866 30 seconds are a reasonable default, but of course this MUST be a 867 setting that can be overridden by operators. NAPT software MUST NOT 868 make any assumptions of passing 6bed4 on the basis of the standard 869 port TBD2 if it is to comply with this specification. 871 7.1. Reliable 6bed4router Uplinks 873 Given that NAPT can only handle 6bed4peer traffic as generic UDP 874 traffic, any outbound UDP traffic necessarily keeps a hole open for 875 reverse traffic over a reasonable minimum time. When more traffic is 876 sent before this period has passed, there is no basis for NAPT to 877 assume that the connection can be severed, causing a reset of the 878 timeout for the hole. 880 To allow reliable bidirectional traffic between a 6bed4peer and its 881 6bed4router, it therefore initiates with a Router Solicitation, and 882 then continues to send Keepalive messages with no smaller separating 883 delay than the delay for UDP holes. 885 Keepalive messages need not make it to the 6bed4router to be 886 effective. Their only need is to make it beyond the last NAPT or 887 firewall. This can both help to offload a 6bed4router and to avoid 888 that it detects the 6bed4peer still being online; since the 889 6bed4router is stateless, it has no use for this information. 891 The content of a Keepalive message can be the minimum that counts as 892 UDP traffic, according to NAPT and firewalls; this is an empty UDP 893 frame. 895 A 6bed4peer can keep up any number of 6bed4router uplinks, and would 896 send Keepalive messages to each of them. This being a resource, the 897 application may have to indicate explicitly what uplinks are 898 considered to be useful (or a trivial setup such as a single uplink 899 might be applied). 901 7.2. Probing for Direct Peering 903 When choosing how to forward an IPv6 frame, a 6bed4peer may consider 904 direct routing, but refrain from it on account of reliable 905 considerations. These are good moments to start working towards 906 direct routing. Other moments are when a 6bed4peer forces direct 907 peering through the Presumptious and Persistent Peering Policies. 909 While working towards direct routing, a few attempts to connect 910 directly are made, by sending a Probe message if no direct traffic is 911 sent at the same time. Probes are the smallest possible UDP frame, 912 so an empty UDP message. They differ from Keepalives because their 913 reach is not constrained but the message is sent with the intention 914 of arriving at the remote 6bed4peer. The destination IPv4 address 915 and UDP port are taken from the bottom half of the destination IPv6 916 address, which is only permitted for addresses known to be bound by 917 the 6bed4 network. 919 When a Probe arrives on a 6bed4peer, it cannot be considered an IPv6 920 frame. It is however detected as an incoming UDP frame from a given 921 IPv4 address and UDP port. This identifies a remote peer that 922 appears to be able to make its way to the UDP socket, all the way 923 through the NAPT and firewalls at the destination end. 925 7.3. Sending and Receiving the Seen Flag 927 When a Probe arrives at a 6bed4peer, it MUST look if the sending IPv4 928 address and UDP port have recently received any traffic. If so, the 929 Probe will be processed into a timer/state product. 931 Starting with the time of arrival, a hole can be reliably assumed to 932 be open in local NAPT, and that it remains open for 30 seconds (or a 933 locally overridden timeout) after the last direct send to that 934 remote, even if it was just a Probe or Keepalive. 936 The time for the open hole is subdivided as follows: 938 o 1 second accounts for a message delay in both directions; 940 o 27 seconds account for the time that the remote peer may send 941 directly; 943 o the remaining time allows informing the other side that a Probe 944 arrived. 946 when a NAPT hole is assumed to be open for 30 seconds, then this 947 remaining time amounts to 2 seconds. This time period, added to the 948 time of the last message sent to that remote, indicates a period in 949 which the Seen flag can be sent to the remote. The remaining time 950 may be negative, in which case the Sent flag is never sent to the 951 remote. When the local NAPT holes are set to be open for longer 952 periods, then the Seen flag is sent correspondingly longer. 954 The Seen flag can be set in any Traffic Class that adheres to the 955 format for the 6bed4 network. It does not matter if it is relayed 956 through one or two 6bed4routers, because it informs about the direct 957 connectivity between terminating 6bed4peers, whose IPv4 address and 958 UDP port must occur in the bottom half of addresses if direct peering 959 is to be considered at all. 961 It is an event when the Seen flag arrives from a 6bed4peer, even from 962 a 6bed4router, when it occurs in a Traffic Class that adheres to the 963 format for the 6bed4 network. In case of this event, the destination 964 6bed4peer may conclude that it can use direct peering to the remote 965 6bed4peer for 27 seconds after arrival of the Seen flag. In active 966 direct peering connections, the Seen flag is likely to be present on 967 most frames, causing the regular reset of the 27-second timer. 969 7.4. Peer NAPT State 971 Every 6bed4peer keeps some state for its remote peers. In contrast, 972 the 6bed4router is a simple stateless process. The state kept per 973 remote peer is known as Peer NAPT State, and is indexed by the IPv4 974 address and UDP port for the remote peer. 976 The information kept for each remote peer consists of: 978 o A current state and related timeout 979 o A time for the last message sent 981 o A time for the last message sent directly 983 o A time until which the Seen flag is reported 985 o A /64 or /114 prefix for local address binding (once known) 987 There is no explicit time until which direct peering is possible; 988 this is instead derived from the current state. 990 This information differs from 6bed4router state, which minimally 991 requires just a /114 prefix and a timer until the next Keepalive 992 needs to be sent. If so desired, the Keepalive timer can be reset 993 when a message is sent to the 6bed4router without risking to reduce 994 reliability. 996 7.5. State/Timer Diagram 998 The Peer NAPT State for a 6bed4peer follows the following state 999 diagram with default progression timeouts to administer sender state: 1001 First.Send 1002 | 1003 V 1004 INIT --1s--> INIT --1s-->.<------+ 1005 | | | | 1006 V V | | 1007 Seen.Flag Probe Probe | 25s 1008 | | | 1009 V V | 1010 PEER---25s---> POLL --1s--> POLL --1s--> FAIL --+ 1011 | | | 1012 V V V 1013 Probe Probe Probe 1015 This section describes the flow of this state/timer diagram for the 1016 Proper Peering, which is the default peering policy. The next 1017 section describes the modifications for the other peering policies. 1019 The transitions marked 1s and 25s represent a default transition to 1020 occur after 1 and 25 seconds in the state, respectively. Timeouts 1021 for NAPT holes below 28 seconds MAY be rejected by a 6bed4peer; if 1022 not, it MUST split the 25 second delays into values less that the 1023 NAPT hole timeout and send Keepalives at the extra points. The total 1024 time MUST however be kept at 25 seconds. 1026 First.Send marks the entry point to the diagram, used when initiating 1027 new Peer NAPT State for a remote 6bed4peer that had no such state 1028 managed yet. When entering FAIL state after a reasonable period with 1029 no traffic sent to the remote peer, the Peer NAPT State may be 1030 removed from administration. What counts as a "reasonable period" 1031 may be locally selected, but would normally be in the range of tens 1032 of seconds. 1034 Seen.Flag marks the point of reset of the state when a Seen flag is 1035 set for traffic from this remote. When connections are actively 1036 used, this flag would occur on most frames, causing repeated resets 1037 of this state diagram. 1039 Probe marks the side-effect of sending a Probe upon entry of a state. 1040 The intention of the Probe is to open a hole in outgoing NAPT and, at 1041 the same time, to reach the remote peer directly and trigger the 1042 return of a Seen flag. 1044 The states in the diagram should be read as follows: 1046 INIT marks the intention to work towards reliable direct peering. A 1047 total of 3 Probes is sent to allow reasonable opportunity for the 1048 remote peer to detect it and send a Seen flag. 1050 PEER marks reliably direct peering for a duration of 27 seconds 1051 (continued into POLL states). Having established in hole in local 1052 NAPT, no need for further Probes exists. 1054 POLL still marks reliable direct peering, but also starts to send 1055 Probes because the hole in NAPT is assumed to be timing out soon. 1056 The Probes are hoped to trigger new Seen flags, and are especially 1057 useful during one-directional transmissions. However, when no 1058 traffic is passed at all there is nothing to carry the Seen flag, 1059 and the state diagram continues. 1061 FAIL marks durable failure to cause a Seen flag to be returned from 1062 the remote peer. This does not imply that the hole in NAPT 1063 towards that peer has been closed however; with 25 seconds between 1064 Probes, the hole would be kept open. TODO:SETTING. Because 1065 Probes have no IPv6 header, there is no vessel for Seen flags, so 1066 connections are setup to close after a reasonable time of 1067 inactivity. 1069 7.6. Differentiation through Peering Policies 1071 When a Traffic Class passes into and over the 6bed4 network, and its 1072 format is that defined for the 6bed4 network, then it may specify a 1073 peering policy. In other cases, the default peering policy applies, 1074 which is Proper Peering. 1076 Peering Policies define how the choice between direct peering and the 1077 source's 6bed4router is made: 1079 Proper Peering defines the default behaviour as described in the 1080 previous paragram. 1082 Prohibited Peering does not interact with Peer NAPT State or its 1083 State/Timer diagram. Instead, traffic is always forwarded to the 1084 source's 6bed4router. 1086 Presumptious Peering forces direct peering during the INIT states, 1087 but has the default behaviour in all other states. When the frame 1088 causes creation of Peer NAT State, the First.Send entry point is 1089 used, but the first Probe MAY be dropped because the frame causing 1090 it takes its place. 1092 Persistent Peering forces direct peering in all states, but triggers 1093 errors instead of sending while residing in the FAIL state. 1095 There is only one Peer NAPT State for a given remote peer; this same 1096 diagram applies to all the peering policies, and may be modified by 1097 it. This allows traffic from a variety of peering policies and a 1098 variety of connections to share one knowledge base about direct 1099 peering. 1101 7.7. Bindable Local Prefix 1103 The Peer NAPT State holds a prefix, which is either the unspecified 1104 address 0::0, a /64 prefix followed by 64 zeroed bits, or a /114 1105 prefix. 1107 The initial state depends on the purpose; when a 6bed4peer is 1108 contacted from an already-used source IPv6 prefix, then the full /114 1109 may be copied to it. When initiating the contact through a Router 1110 Solicitation to the remote 6bed4peer, it is set to a /64 prefix to be 1111 shared, or to 0::0 if the prefix of the remote 6bed4peer is to be 1112 assumed. 1114 Upon arrival of an initial Router Advertisement from a remote 1115 6bed4peer, the /64 in the prefix is only updated when it was 0::0; 1116 the following IPv4 address and UDP port in the bottom half are always 1117 copied. The last 14 bits with the lanid are left zero. 1119 Until the /114 prefix is complete, it is not possible to bind a local 1120 address for traffic to the remote 6bed4peer, let alone use it as a 1121 source address. Only after the /114 prefix is known is it possible 1122 to select lanid values to complete the IPv6 address. 1124 After binding has occurred, a corrective Router Advertisement may 1125 overwrite the IPv4 address and UDP port in the bottom half of this 1126 binding prefix. This marks a change, and any further attempts to 1127 send to this remote peer from a previously bound source IPv6 address 1128 with different IPv4 address and UDP port in its bottom half are 1129 rejected by the 6bed4peer. TODO:CODE 1131 This undesirable situation blocks further direct peering and requires 1132 a fallback to the 6bed4router, whose connection is kept open through 1133 Keepalives. The same approach can only work between 6bed4peers when 1134 both send Keepalives to each other, but this may be wasteful in many 1135 scenarios, especially when normal traffic flows regularly. Also note 1136 that what worked for setting up direct peering once is likely to work 1137 again later. 1139 7.8. Benefiting from Adaptive Flags 1141 The 6bed4 network is concerned with routing and peering policy; this 1142 is used by applications, whose logic may be so courteous that it does 1143 not matter if a locally bound address changes. In terms of the 1144 Socket API this would be the case when neither bind() nor 1145 getsockname() are ever called. 1147 Such ambivalence to the locally bound address can be a benefit when 1148 NAPT mappings alter on a given connection. It may help the number of 1149 direct peering successes to signal that such an address change does 1150 not matter to the application logic. To this end, the Adaptive flag 1151 can be set in frames submitted through a 6bed4peer, at the same time 1152 as the desired Peering Policy. 1154 When this flag is set, the behaviour in case of a mismatched prefix 1155 for the remote peer is not to reject the traffic, but instead to 1156 substitute the IPv4 address and UDP port in the source IPv6 address 1157 of a frame; the /64 prefix should match as always, and the lanid is 1158 not altered. 1160 The address change is not reversed in the destination IPv6 address of 1161 reply traffic. This means that the application would receive the 1162 altered address. If this could otherwise lead to confusion, the 1163 application might choose to match reply traffic on the basis of a 1164 unique lanid or a random Flow Label. 1166 It is up to the application if this is possible, and in which frames 1167 sent. The safe default is to not allow Adaptive source IPv6 1168 addresses, but as long as it is usually beneficial to set the 1169 Adaptive flag whenever it is of no concern to application logic. 1171 8. Global Routing of TBD1::/32 1173 TODO: SOLVE A FILTER ON AUTHORITATIVE GATEWAY ROUTERS 1175 HINTS FILE OPTION: Distribute the IPv4 addresses of gateway routers 1176 as part of the 6bed4router software, as is done for DNS root name 1177 servers. 1179 DNS OPTION: Define 32.gateway.6bed4.net to hold /32 gateways, and 1180 perhaps .48.gateway.6bed4.net to hold /48 gateways. These 1181 gateways are trusted by 6bed4routers. The only thing these gateways 1182 do is to relay native IPv6 prefix TBD1::/32 from/to the 6bed4 1183 network. The IPv4/UDP is always that of the 6bed4router and the 1184 standard UDP port TBD2. 1186 6TO4 OPTION??? Compare to https://labs.ripe.net/Members/ 1187 emileaben/6to4-why-is-it-so-bad -- the main problem of 6to4 is 1188 firewalls not being setup for it, especially -- 1189 https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really -- 1190 if it is pushed through without asking users. Note that a 6bed4peer 1191 may also run on a LAN, but only announces an address prefix when 1192 Router Solicitation responds. The 6bed4router should however route 1193 properly... which is more easily established when it integrates into 1194 a router device where it has access to external interfaces and/or 1195 firewall rules. Given that, even using 2002::/16 instead of 1196 TBD1::/32 and routing backend traffic over proto-41 might be an 1197 option? But it has fallen in disgrace, even if only the anycast/ 1198 unicast mixup of router setups appears to have been a cause and 1199 anycast was deprecated for 6to4. Still, there is the issue of 1200 firewall traversal (that we solve by demanding a public IPv4 address 1201 and fixed UDP port for 6bed4routers). 1203 9. IANA Considerations 1205 This specification reserves a 32-bit address prefix TBD1::/32 in the 1206 IPv6 address space assigned to the IANA IPv6 Special-Purpose Address 1207 Registry. The prefix will be exclusively used for 6bed4 addresses, 1208 and further assigned as defined in Section 3.3.3. Addresses under 1209 this prefix can be used as source and destination addresses, as they 1210 are globally routable. The termination date for the allocation falls 1211 ten years after the publication date of this specification in the 1212 Request For Comments series; future standardisation work could modify 1213 the end date if this is considered useful. 1215 This specification also reserves Port TBD2 from the pools of UDP 1216 ports, TCP ports and SCTP ports, subject to possible updates in 1217 follow-up specifications. 1219 The port TBD2 will be the port on which 6bed4routers provide their 1220 services. These servers form a public resource, and remote peers 1221 have no mechanism other than the standardised port to know how to 1222 contact an arbitrary 6bed4 Server of which only the Fallback IPv4 1223 Address was found in an IPv6 destination address falling under the 1224 6bed4 prefix TBD1::/32. 1226 [[CREF1: Requests to IANA / to be removed after processing: The 1227 requested assignment for TBD1 is 2001:64, so TBD1::/32 allocates 1228 2001:64::/32 from 2001::/23 which is suggested (with the 6BONE 1229 example) in RFC 2928 and https://www.iana.org/assignments/ipv6- 1230 unicast-address-assignments/ipv6-unicast-address-assignments.xhtml 1231 The requested assignment for TBD2 is 25790, which is what we 1232 currently use in our code and experimental deployments. As per RFC 1233 6335, this will probably be assigned under IETF Review or IESG 1234 Approval _or_ Expert Review, all defined in RFC 5226. Note that IETF 1235 Review is banned for independent submissions under https://www.rfc- 1236 editor.org/about/independent/ and IESG Approval is not a very common 1237 procedure. For Expert Review, it is necessary to document clearly 1238 that a Dynamic Port is required; this is the case because clients 1239 have no means to infer the port at which to contact a server or a 1240 peer. Especially for peers, whose addresses are inferred from their 1241 IPv6 address within the 6bed4 address space, there is no derivation 1242 mechanism for these ports; and it is the ability to communicate 1243 directly with peers that sets this mechanism apart as extremely 1244 scalable and apt for VoIP applications. --Rick]] 1246 10. Security Considerations 1248 Tunneling mechanisms must always be on their guard for wrapped 1249 packets containing false origins [RFC6169]. To shield against this, 1250 6bed4 ensures that the source IPv4 address and UDP port of the 1251 together match either the Direct or Fallback 6bed4 Address contained 1252 in the source IPv6 address. 1254 Note that this facility works best when address filtering [BCP38] is 1255 applied. In lieu of authentication facilities for frame source, the 1256 best that the 6bed4 tunnel can do is to avoid worsening the problems 1257 of incomplete address filtering. 1259 One exception arises with the possibility that a target 1260 6bed4-Prefixed Address publishes a /32+16 Prefix which is not seen 1261 everywhere on the Internet; or that such a prefix is not actually 1262 published at all. In such situations, a 6bed4 Frame may be routed to 1263 a TBD1::/32 route, which passes it on to the Fallback 6bed4 Address 1264 contained in the IPv6 destination address. The list of routers that 1265 can pass on such traffic will generally be limited, and will be 1266 maintained externally to this specification, but documented on 1267 6bed4.net. Routes announced to larger IP space than owned by the 1268 publishing Anonymous System MUST be registered on 6bed4.net so as to 1269 distinguish them from abuse. The domain will publish processible 1270 information that helps 6bed4 Servers to recognise this distinction 1271 too. 1273 It is important to realise that 6bed4 bypasses NAT and Firewalls. 1274 This is a feature inasfar as it enables peer-to-peer connectivity, 1275 but it also implies a responsibility to not lightly attach services 1276 to a 6bed4-Prefixed Address. There is no protection, other than what 1277 is being added. Specifically noteworthy is that the operator of the 1278 6bed4 Server cannot implement filtering on behalf of their customers; 1279 the ability to use Direct 6bed4 Connections would bypass this, and 1280 since this could happen at any time such filtering could not even be 1281 realiably made connection-aware. 1283 11. Acknowledgements 1285 This work has evolved from a simple, and perhaps simplistic protocol 1286 to its current form. I owe gratitude to many who contributed. 1288 Special thanks go to SURFnet, for generally supporting the idea of 1289 6bed4 and providing long-term support for the first public 1290 6bed4router, as well as supporting the expansion of the initial 1291 tunnel investigation work into a generally useful publication 1292 [RFC7059]. 1294 Thanks for financial support in developing phases of the 1295 specification and coding of 6bed4 are due towards NLnet Foundation, 1296 as well as SURFnet and SIDNfonds. 1298 I owe gratitude to the NLUUG, ISOC NL and RIPE communities for 1299 discussing prior tunnel designs and pointing out scaling and routing 1300 problems; although the protocol has become more complex it also has 1301 become more reliable and, I think, more generally acceptable. 1303 Many thanks to Henri Manson for supporting me over a long time in 1304 experimental development and many, many tests. 1306 Finally, the work in this tunnel design called for a creative mind 1307 set in which technical concepts were highly fluid and changing. 1308 Although it would be difficult to point out a direct link or assign 1309 an economic figure, the ability to think in such a mode has clearly 1310 been influenced by independent, thought-provoking, boundary-breaking 1311 expression by the many artists whose work I have been able to enjoy. 1312 I cherish art in all its forms for its incredible power to help us be 1313 imaginative and innovative in the pragmatic field of technology. 1315 12. Normative References 1317 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1318 Defeating Denial of Service Attacks which employ IP Source 1319 Address Spoofing", BCP 38, RFC 2827, May 2000. 1321 [IEEE-EUI64] 1322 IEEE, "Guidelines for 64-bit Global Identifier (EUI- 1323 64TM)", December 2013. 1325 [POTAROO] Huston, G., "Testing Teredo", April 2011, 1326 . 1328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1329 Requirement Levels", BCP 14, RFC 2119, March 1997. 1331 [RFC2372] Evans, K., Klein, J., and J. Lyon, "Transaction Internet 1332 Protocol - Requirements and Supplemental Information", 1333 RFC 2372, July 1998. 1335 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1336 "Definition of the Differentiated Services Field (DS 1337 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1338 DOI 10.17487/RFC2474, December 1998, 1339 . 1341 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 1342 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 1343 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 1344 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 1345 Compression (ROHC): Framework and four profiles: RTP, UDP, 1346 ESP, and uncompressed", RFC 3095, July 2001. 1348 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1349 of Explicit Congestion Notification (ECN) to IP", 1350 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1351 . 1353 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1354 A., Peterson, J., Sparks, R., Handley, M., and E. 1355 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1356 June 2002. 1358 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1359 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1360 Through Network Address Translators (NATs)", RFC 3489, 1361 March 2003. 1363 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1364 (IPv6) Addressing Architecture", RFC 3513, 1365 DOI 10.17487/RFC3513, April 2003, 1366 . 1368 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1369 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 1370 . 1372 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1373 Architecture", RFC 4291, February 2006. 1375 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1376 Network Address Translations (NATs)", RFC 4380, February 1377 2006. 1379 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1380 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1381 RFC 4787, January 2007. 1383 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1384 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1385 September 2007. 1387 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1388 Address Autoconfiguration", RFC 4862, September 2007. 1390 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1391 Extensions for Stateless Address Autoconfiguration in 1392 IPv6", RFC 4941, September 2007. 1394 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1395 RFC 4960, September 2007. 1397 [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router 1398 Advertisement Flags Option", RFC 5175, 1399 DOI 10.17487/RFC5175, March 2008, 1400 . 1402 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1403 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1404 October 2008. 1406 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 1407 Concerns with IP Tunneling", RFC 6169, April 2011. 1409 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1410 RFC 6455, December 2011. 1412 [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- 1413 Martinez, "Secure Proxy ND Support for SEcure Neighbor 1414 Discovery (SEND)", RFC 6496, February 2012. 1416 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1417 "Default Address Selection for Internet Protocol Version 6 1418 (IPv6)", RFC 6724, September 2012. 1420 [RFC7059] Steffann, S., van Beijnum, I., and R. van Rein, "A 1421 Comparison of IPv6-over-IPv4 Tunnel Mechanisms", RFC 7059, 1422 November 2013. 1424 Author's Address 1426 Rick van Rein 1427 OpenFortress B.V. 1428 Haarlebrink 5 1429 Enschede, Overijssel 7544 WP 1430 The Netherlands 1432 Email: rick@openfortress.nl