idnits 2.17.1 draft-vanrein-v6ops-6bed4-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4861], [RFC4862]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Every 6bed4 Peer MUST have an assigned 6bed4 Router that it can use as its default route to the general IPv6 network. This 6bed4 Router MAY be configured, or it MAY be determined using some automated mech-anism during initialization of the 6bed4 Peer. Furthermore, the 6bed4 Peer MAY iterate over a number of options until it finds one that it finds acceptable. It SHOULD not change its 6bed4 Router after it has decided to join its 6bed4 Network. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If no MTU settings are provided as part of the Router Advertisement, then the 6bed4 Peer MUST not assume more than the guaranteed minimum MTU of 1280 for IPv6 networks without performing Path MTU Discovery. -- The document date (March 11, 2012) is 4401 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4787' is mentioned on line 120, but not defined == Missing Reference: 'RFC791' is mentioned on line 975, but not defined == Unused Reference: 'RFC4291' is defined on line 1091, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 1094, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3022 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Rick van Rein 3 Intended Status: Proposed Standard OpenFortress 4 Expires: September 12, 2012 March 11, 2012 6 6bed4: Peer-to-Peer IPv6 on Any Internetwork 7 draft-vanrein-v6ops-6bed4-01 9 Abstract 11 The intention of 6bed4 is to support IPv6-only applications, even on 12 IPv4-only networks. A specific area of concern is that of peer-to- 13 peer protocols such as SIP or document exchange during a chat 14 session. Such protocols are designed to run in any environment, 15 which means that they cannot rely on IPv6 for themselves, or their 16 peers. The 6bed4 tunnel mechanism ensures that IPv6 can be assumed 17 on all peers, without a need to configure it explicitly. 19 The 6bed4 mechanism is meant as a fallback mechanism for IPv6 20 connectivity on networks that do not support it natively, by running 21 a tunnel over UDP and IPv4. The IPv4 address is used to support 22 traceability of the traffic originator, which means that no user 23 account or other configuration is needed. 25 The tunnel mechanism builds on existing IPv6 mechanisms; it employs 26 Stateless Address Autoconfiguration [RFC4862] to setup an IPv6 27 address on a 6bed4 Peer, and Neighbor Discovery [RFC4861] to find the 28 most direct route to a remote 6bed4 Peer. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Conceptual Model for a 6bed4 node . . . . . . . . . . . . . . 6 67 4. Link-Local Profile for 6bed4 . . . . . . . . . . . . . . . . . 9 68 5. 6bed4 Router Behavior . . . . . . . . . . . . . . . . . . . . 10 69 5.1. Address Information . . . . . . . . . . . . . . . . . . . 11 70 5.2. Relaying Plain Unicast Traffic . . . . . . . . . . . . . . 11 71 5.3. Relaying Plain Multicast Traffic . . . . . . . . . . . . . 12 72 5.4. Handling Router Solicitation from the 6bed4 Network . . . 12 73 5.5. Handling Router Advertisement from the 6bed4 Network . . . 13 74 5.6. Handling Neighbor Solicitation from the 6bed4 Network . . 13 75 5.7. Handling Neighbor Advertisement from the 6bed4 Network . . 13 76 5.8. Handling Redirect from the 6bed4 Network . . . . . . . . . 13 77 5.9. Handling Empty UDP Packets from the 6bed4 Network . . . . 14 78 5.10. Dealing with Packet Fragmentation . . . . . . . . . . . . 14 79 6. 6bed4 Peer Behavior . . . . . . . . . . . . . . . . . . . . . 14 80 6.1. Filtering Incoming Traffic . . . . . . . . . . . . . . . . 14 81 6.2. 6bed4 Tunnel and Link-Layer Address Setup . . . . . . . . 15 82 6.3. Relaying Plain Unicast Traffic . . . . . . . . . . . . . . 16 83 6.4. Relaying Plain Multicast Traffic . . . . . . . . . . . . . 16 84 6.5. Handling Router Solicitation from the 6bed4 Network . . . 17 85 6.6. Handling Router Advertisement from the 6bed4 Network . . . 17 86 6.7. Handling Router Solicitation from the 6bed4 Link . . . . . 18 87 6.8. Handling Router Advertisement from the 6bed4 Link . . . . 18 88 6.9. Handling Neighbor Solicitation from the 6bed4 Network . . 18 89 6.10. Handling Neighbor Advertisement from the 6bed4 Network . 18 90 6.11. Handling Neighbor Solicitation from the 6bed4 Link . . . 19 91 6.12. Handling Neighbor Advertisement from the 6bed4 Link . . . 21 92 6.13. Handling Redirect from the 6bed4 Network . . . . . . . . 21 93 6.14. Handling Redirect from the 6bed4 Link . . . . . . . . . . 22 94 6.15. Dealing with Packet Fragmentation . . . . . . . . . . . . 22 95 7. Impact of Firewalls and Network Address Translation . . . . . 22 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 98 9.1. Registered UDP port: 6bed4 . . . . . . . . . . . . . . . . 24 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 101 10.2. Informative References . . . . . . . . . . . . . . . . . 26 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 104 1. Introduction 106 The 6bed4 mechanism is a fallback for networks that have no support 107 for IPv6. It is designed to work without configuration on any 108 network that is not secured beyond common defaults. It works behind 109 any sequence of Network Address Translating (NAT) devices and 110 Firewalls, and it does not require support (such as protocol 41) from 111 any of those devices. The local network may or may not support IPv6 112 already; and also upstream network providers may or may not support 113 IPv6. The 6bed4 traffic does not mingle with local IPv6 traffic, so 114 it will never raise alarms that monitor native local IPv6 traffic for 115 potential IPv6-specific attacks. 117 All traffic on the 6bed4 Network is embedded in UDP and IPv4. The 118 6bed4 Network is thereby layered on top of the IPv4 Internet. Common 119 default configurations for NAT and firewalls support UDP [RFC3022] 120 [RFC4787], as long as the communication is initiated internally. 121 This is precisely what 6bed4 does. 123 This traffic is exchanged between 6bed4 Peers, which are the 124 endpoints in the communication. They may pass their traffic through 125 a 6bed4 Router. A 6bed4 Router recognizes 6bed4 traffic because it 126 is received on the standard UDP port TBD1, and it recognizes IPv6 127 addresses as 6bed4 addresses because they start with the /64 prefix 128 that it has dedicated to 6bed4. Such IPv6 prefixes are paired to the 129 IPv4 address and UDP port of the 6bed4 Router. 131 The IPv4 address and UDP port as seen from the Internet are combined 132 to form a link-layer address, from which an Interface Identifier is 133 constructed in the same way as for Ethernet Networks [RFC2464]. This 134 implies that the IPv4 address and UDP port are shown as part of the 135 IPv6 address. This supports traceback of a traffic originator in 136 case of abuse, without a need to register accounts or login to them. 137 Every 6bed4 Router validate that the IPv4 address and UDP port in the 138 IPv6 address against the actual traffic, so the properties of egress 139 filtering on IPv4 packets are inherited by the 6bed4 Network. 141 The simplest mode of communication between to 6bed4 Peers is to 142 communicate through a 6bed4 Router. This service relays between 143 6bed4 traffic and native IPv6 or, if both IPv6 addresses are IPv6 144 addresses under the same 6bed4 prefix, then a 6bed4 Router relays the 145 traffic between the 6bed4 Peers, using its own IPv4 address and UDP 146 port when forwarding a packet over 6bed4 to the destination. Traffic 147 intended for addresses that the 6bed4 Router does not handle as 6bed4 148 prefixes are relayed as IPv6 over normal IPv6 routes. 150 It is normal for a 6bed4 Peer to attempt to bypass the 6bed4 Router 151 by contacting remote peers directly. One such bypass that every 152 6bed4 Peer MUST attempt is to contact 6bed4 Peers at the IPv4 address 153 and UDP port contained in their Interface Identifier. Other 154 bypassing mechanisms may also be tried; the success or failure of 155 each bypass method depends on co-operation of intermediate network 156 nodes. Rather than devising a model of these intermediate nodes, 157 6bed4 Peers simply try to send Neighbor Solicitation over a candidate 158 bypass, and when the remote 6bed4 Peer replies with a matching 159 Neighbor Advertisement, then the bypass is fit for use. If the reply 160 does not arrive, the 6bed4 Peer can still fallback to the 6bed4 161 Router for that remote 6bed4 Peer. 163 Information about bypasses to a 6bed4 Peer should be cached for some 164 time. A good place to do this is the Neighbor Cache, which retains 165 such information for tens of seconds [RFC4861]. This happens 166 automatically if the IPv6 stack that uses a 6bed4 Link for IPv6 167 connectivity is used to relay link-layer addresses for the 6bed4 168 Network; such link-layer addresses would be composed of the IPv4 169 address and UDP port needed to contact the 6bed4 Peer over the 6bed4 170 Network. Whenever the IPv6 stack sends a Neighbor Solicitation down 171 the 6bed4 Link, the 6bed4 Peer will know that it should try a number 172 of bypasses for that route, once again using Neighbor Discovery. 173 When no bypasses work, then the link-local address of the 6bed4 174 Router is passed back up to the IPv6 stack. 176 [TO BE REMOVED: Code demonstrating this specification is, or will 177 soon be, available on http://devel.0cpm.org/6bed4/ -- please contact 178 the author for details, information and feedback] 180 2. Definitions 182 The following definitions will be used throughout this document. 184 A 6bed4 Router is a network node connected to both IPv4 and IPv6 185 networks, which supports the translation of a particular IPv6 /64 186 prefix to 6bed4 and back. The IPv6 prefix forms a pair with the 187 router's IPv4 address and UDP port for 6bed4. A 6bed4 Router may 188 translate traffic bidirectionally, or in the case of more advanced 189 routing topologies, it could rest on the assumption that another 190 6bed4 Router to perform the reverse translation for the same pair of 191 IPv6 prefix and IPv4/UDP coordinates. 193 A 6bed4 Peer is a communication endpoint that uses 6bed4 to embed 194 IPv6 packets in UDP and IPv4. It has a relationship to one 6bed4 195 Router which serves as its default router and as a fallback for 196 remote 6bed4 Peers that cannot be connected to directly. 198 A bypass or bypass route is a connection between two 6bed4 Peers that 199 does not run through a 6bed4 Router. 201 A 6bed4 Network comprises of the 6bed4 Router(s) and all 6bed4 Peers. 202 This may include bypass routes that connect over a local network, 203 even using private IPv4 addresses [RFC1918]. The identity of a 6bed4 204 Network is its IPv6 /64 prefix as supplied by its 6bed4 Router(s). 206 A 6bed4 Link is a (virtual) network interface that is offered to an 207 IPv6 stack that wants to use it to link to IPv6 nodes. This term is 208 non-normative; it is introduced below as part of the conceptual model 209 for a 6bed4 Peer. 211 A 6bed4 Tunnel is the connection between a 6bed4 Link and the 6bed4 212 Network. This term is non-normative; it is introduced below as part 213 of the conceptual model for a 6bed4 Peer. 215 A 6bed4 Address is a pair of an IPv4 address and UDP port that can be 216 used as an endpoint on the 6bed4 Network, at the very least to its 217 6bed4 Router and possibly through Bypass Routes from other 6bed4 218 Peers as well. The IPv4 address and UDP port are the values as seen 219 by the public Internet. This is a conceptual notion, free from any 220 representation in network packets. 222 A 6bed4 Link-Local Address is a particular representation of a 6bed4 223 Address. It is employed in network packets for Neighbor Discovery, 224 Router Discovery and Redirect messages. 226 Plain traffic is defined as IPv6 traffic that is not one of the 227 special ICMPv6 [RFC4443] types Router Solicitation, Router 228 Advertisement, Neighbor Solicitation, Neighbor Advertisement or 229 Redirect. 231 The Metric, or Communication Cost Metric, of communicating to a given 232 6bed4 Address is an indication of the relative cost of a number of 233 possible routes; a bypass route to a local subnet ranks as Low, a 234 bypass route directly to the UDP port and IPv4 address of a remote 235 6bed4 Peer ranks as Medium and a route to the 6bed4 Router ranks as 236 High. 238 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 239 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 240 document are to be interpreted as described in RFC 2119 [RFC2119]. 242 3. Conceptual Model for a 6bed4 node 244 A 6bed4 node is a network node that acts as a 6bed4 Router or a 6bed4 245 Peer. This conceptual model for a 6bed4 nodes is non-normative; the 246 terms and layers it introduces are intended for illustration 247 purposes, but any equivalent implementation would be equally 248 suitable. 250 The conceptual model of the internal structure of a 6bed4 node is 251 based on what is called a tunnel in many operating systems; this is a 252 structure which acts as a network interface on one end, and gives 253 programmatic control over packet handling on the other end. An IPv6 254 stack can access the 6bed4 services through a 6bed4 Link. 256 The 6bed4 Link is the network side of a 6bed4 Tunnel. This 6bed4 257 Link acts as a level 2 service to an IPv6 stack. The programmatic 258 side of the 6bed4 Tunnel uses the level 4 service of a UDP/IPv4 259 stack. The function of the 6bed4 Tunnel is to translate packets 260 between these two interfaces. 262 : : 263 | IPv6 stack | 264 +-------++-------+ 265 || <-- 6bed4 Link 266 || Layer 2 transport: IPv6 over a link-layer protocol 267 \/ 268 +-------++-------+ 269 | 6bed4 Tunnel | 270 +-------++-------+ 271 || 272 || Layer 4 transport: IPv6 over UDP/IPv4 273 \/ 274 +-------++-------+ 275 | UDP/IPv4 stack | <-- 6bed4 Network 276 : : 278 The translation of plain traffic is a matter of adding or removing 279 headers into which an IPv6 packet is embedded. On the IPv6 end, some 280 form of header information revealing the 6bed4 Link-Local Address of 281 the next-hop destination must be present, and on the IPv4 end there 282 are UDP/IPv4 headers. Since 6bed4 Link-Local Addresses incorporate 283 the destination's UDP port and IPv4 address, a complete translation 284 between these two prefixed headers is possible. This is what is done 285 with plain traffic. 287 An exception is made for Router Discovery, Neighbor Discovery and 288 Redirect messages. These were designed for local use, and should 289 therefore be treated differently; the messages are exchanged between 290 the IPv6 stack and the 6bed4 Tunnel, and somewhat independently 291 between the 6bed4 Tunnel and the 6bed4 Network. relayed through a 292 tunnel. These messages are therefore handled explicitly by the 6bed4 293 Tunnel. 295 The link-layer address of a 6bed4 Link is not normally known as soon 296 as the 6bed4 Link is created, as it relies on observations made on 297 the Public Internet. To obtain this link-layer address, the 6bed4 298 Tunnel will send a Router Solicitation to its 6bed4 Router. The 299 6bed4 Router responds with a Router Advertisement containing the 300 6bed4 Peer's Interface Identifier as the IPv6 destination address. 301 From this address, the 6bed4 Peer's link-layer address is derived and 302 assigned to the 6bed4 Link; this also serves as the 6bed4 Link-Layer 303 Address when communicating on the 6bed4 Network. This information is 304 usually be exchanged prior to bringing up the 6bed4 Link. 306 The prefix information from the Router Advertisement is held back 307 until the IPv6 stack on top of the 6bed4 Link sends a Router 308 Solicitation. In response to that, a Router Advertisement is sent to 309 the IPv6 stack that holds the prefix. The IPv6 stack is assumed to 310 reconstruct the Interface Identifier from the link-layer address, 311 prefix it with the Router Solicitation's prefix and assign the 312 resulting address to the 6bed4 Link. Any attempts to perform 313 Neighbor Discovery on its own address should be dropped in the 6bed4 314 Tunnel, as it is safe to assume that no competition for the link- 315 layer address and its derived full address exists. 317 The 6bed4 Link is now configured with a /64 prefix and a default 318 route through the 6bed4 Router. Any IPv6 addresses starting with the 319 /64 prefix handled by the 6bed4 Router are treated by the IPv6 stack 320 as local traffic to be contacted through the 6bed4 Link, and any 321 other IPv6 traffic may be forwarded to the 6bed4 Router. 323 Whenever the IPv6 stack needs to find either the 6bed4 Router or a 324 6bed4 Peer with the same /64 prefix, it will perform Neighbor 325 Discovery on the 6bed4 Link. The 6bed4 Tunnel handles these 326 especially, in an attempt to create a bypass when possible. To this 327 end, it will first try one or more bypasses before falling back to 328 the 6bed4 Router. 330 The 6bed4 Tunnel will first try a few times to send Neighbor 331 Solicitation messages with the targeted IPv6 address to the direct 332 IPv4 address and UDP port of the remote 6bed4 Peer. When this 333 results in a matching Neighbor Advertisement, it will relay that 334 knowledge through Neighbor Advertisement to the IPv6 stack, which 335 will note it in its Neighbor Cache. If it fails to receive such a 336 response, but before the IPv6 stack times out on its Neighbor 337 Solicitation, the 6bed4 Tunnel will instead send back a Neighbor 338 Advertisement announcing the 6bed4 Link-Local Address of the 6bed4 339 Router. 341 Among the possibly found direct routes may be Pinholes, which relay 342 the traffic back to the local network. These Pinholes, as well as 343 any other bypass routes through a hole in a Network Address 344 Translator or Firewall, are subject to timeouts. It is useful to 345 realize that Neighbor Caches tend to hold a Link-Local Address for 346 "tens of seconds" [RFC4861] and then either drop it or revitalize it 347 through another Neighbor Discovery attempt. These delays are smaller 348 than common expiration times of holes in NAT or Firewalls, so no 349 Neighbor Cache parameter changes should normally be needed to sustain 350 a connection between 6bed4 Peers communicating through any of these 351 bypasses. 353 It is even find a better bypass than a Pinhole if a direct connection 354 to a locally connected 6bed4 Peer is possible. This may be 355 considered for contact between 6bed4 Peers that exhibit the same 356 public IPv4 address. Those may be sought through multicasting a 357 Neighbor Solicitation over 6bed4 on the local IPv4 network, by 358 sending to the address for all IPv4 nodes on the current subnet, or 359 224.0.0.1, using the standard UDP port TBD1 to select 6bed4 Peers. 361 To keep a hole in a Firewall or NAT open while it is in active use, 362 it is generally useful to pass traffic in both directions; this means 363 that two 6bed4 Peers must use the same route to pass traffic between 364 each other. In exceptional cases however, asymmetric routes may be 365 learnt. This may be remedied with a Redirect message that requests a 366 6bed4 Peer to change to a more efficient bypass. Redirect messages 367 will never be sent to request changing to a route with a higher 368 Metric, but only to a bypass with a lower Metric. In order of rising 369 Metric, the available bypass mechanisms are: 371 o Low: Traffic sent to locally attached private addresses [RFC1918] 372 (Optionally supported) 374 o Medium: Traffic sent to the IPv4 address and UDP port in the 6bed4 375 Link-Local Address 377 o High: Traffic sent through the 6bed4 Router 379 Note that these variations can be distinguished easily by observing 380 the IPv4 address targeted. Also note that the third routing mecha- 381 nism would not add anything to local networks by supporting publicly 382 routed addresses, as the second mechanism provides sufficient support 383 for optimal bypasses on such networks. 385 4. Link-Local Profile for 6bed4 387 Each 6bed4 Link-Local Address contains the UDP port and IPv4 address 388 as observed on the public Internet. This means that it is 6 bytes in 389 size. The format is as follows: 391 0 47 392 +-------+-------+-------+-------+-------+-------+ 393 | UDP.1 | UDP.0 |IPv4.0 |IPv4.1 |IPv4.2 |IPv4.3 | 394 +-------+-------+-------+-------+-------+-------+ 396 The UDP port is encoded in two bytes, where UDP.0 UDP.1 would be the 397 network byte order; note that the bytes in the 6bed4 Link-Local 398 Address are included in the reverse of network byte order. The IPv4 399 address bytes are represented in the network byte order, IPv4.0 400 IPv4.1 IPv4.2 IPv4.3. 402 The UDP port MUST be an even number. The lowest-valued bit of UDP.1 403 is reserved to indicate a multicast address, when it is set. In sit- 404 uations where multicast addresses are known to be impossible, the bit 405 may alternately be interpreted as an error indication. 407 The 64 bits of Interface Identifier to follow a /64 prefix can be 408 derived from the 6bed4 Link-Local Address as it is done for 6-byte 409 Ethernet addresses, as follows: 411 0 63 412 +-------+-------+-------+-------+-------+-------+-------+-------+ 413 | UDP.1'| UDP.0 |IPv4.0 | 0xff | 0xfe |IPv4.1 |IPv4.2 |IPv4.3 | 414 +-------+-------+-------+-------+-------+-------+-------+-------+ 416 In this representation UDP.1' is UDP.1, bitwise xor-ed with 0x02. 417 The result is the EUI-64 address derivation that is also used for 418 Ethernet Networks [RFC2464]. 420 Multicast addresses for IPv6 are also constructed as for Ethernet, 421 resulting in the following format: 423 0 47 424 +-------+-------+-------+-------+-------+-------+ 425 | 0x33 | 0x33 |IPv6.12|IPv6.13|IPv6.14|IPv6.15| 426 +-------+-------+-------+-------+-------+-------+ 428 The bytes IPv6.12 through IPv6.15 are the last four bytes of the IPv6 429 address sought over multicast. 431 5. 6bed4 Router Behavior 433 The 6bed4 Router services 6bed4 Peers with Router Solicitation 434 requests, and by relaying any traffic that it cannot automatically 435 direct. The following definitions specify the behavior in detail. 437 The description below assumes that the 6bed4 Router acts bidirection- 438 ally; note that a split of this function over multiple network nodes 439 is thinkable, in which case their combined behavior should match 440 these specifications. 442 5.1. Address Information 444 A 6bed4 Router offers its services on an IPv4 address and the UDP 445 port TBD1. The IPv4 address varies between 6bed4 Routers, and may be 446 found through various means; it may be hard-coded into 6bed4 Tunnel 447 software, it may be an Anycast address [RFC4786], or it may be found 448 through IPv4 application protocols such as DNS [RFC1034] or DHCP 449 [RFC2131]. The combined IPv4 address and UDP port form its 6bed4 450 Address, which will sometimes be represented as its 6bed4 Link-Local 451 Address. 453 Traffic arriving at this UDP/IPv4 combination is said to have arrived 454 from the 6bed4 Network. Similarly, whenever the 6bed4 Router sends 455 traffic over the 6bed4 Network, so when addressing a 6bed4 Peer, it 456 MUST send from that same IPv4 address and UDP port. 458 The IPv4 address and UDP port are paired with a IPv6 /64 prefix for 459 which the 6bed4 Router serves as a router. The prefix is assumed to 460 be assigned indefinitely to the 6bed4 Router. 462 5.2. Relaying Plain Unicast Traffic 464 The 6bed4 Router relays plain unicast traffic between 6bed4 Peers, as 465 well as between 6bed4 Peers and the general IPv6 Internet. This sec- 466 tion describes how this is done. 468 Upon arrival of plain unicast traffic over the 6bed4 Network, the 469 6bed4 Router MUST validate that the sender's IPv6 address is correct; 470 this means that the /64 prefix MUST match the prefix serviced by the 471 6bed4 Router, and that the IPv4 address and UDP port as shown in the 472 Interface Identifier MUST match the parameters of the incoming 6bed4 473 message. This certifies the IPv6 address of the 6bed4 Peer as well 474 as its IPv4 address is certified. The value of the bytes 0xff and 475 0xfe in the default Interface Identifier MUST NOT be validated, as 476 these may vary when the sending 6bed4 Peer acts as a local router. 478 If only the Interface Identifier fails validation, then the 6bed4 479 Router MUST proceed as if it had received a Router Solicitation over 480 the 6bed4 Network. The 6bed4 Router MUST drop all other 6bed4 traf- 481 fic that fails validation. The remainder of this section applies 482 only to plain unicast traffic that passed validation. 484 When the destination address starts with the /64 prefix that the 485 6bed4 Router announces to 6bed4 Peers, then the destination is con- 486 sidered to be on the 6bed4 Network. Otherwise, it is considered a 487 general IPv6 address, and MUST be routed through a general IPv6 net- 488 work to which the 6bed4 Router is connected. 490 To route a network packet to the 6bed4 Network, the 6bed4 Router MUST 491 extract the IPv4 address and UDP port from the Interface Identifier 492 part of the IPv6 destination address, and forward the packet over UDP 493 and IPv4 to those coordinates. 495 When relaying traffic to the IPv6 network, the Differentiated Ser- 496 vices field [RFC2474], contained in the Traffic Class in the IPv6 497 header, SHOULD be retained inasfar as it cannot interfere with normal 498 network operation. When relaying traffic to the 6bed4 network, the 499 Differentiated Services field in the Traffic Class in the IPv6 header 500 SHOULD be used to fill the Type Of Service field in the IPv4 header, 501 inasfar as normal network operation permits. 503 5.3. Relaying Plain Multicast Traffic 505 This specification places no restrictions on handling of plain multi- 506 cast traffic. As a result, a 6bed4 Router MAY drop all plain multi- 507 cast traffic, but extensions to this specification MAY be implemented 508 to support carrying multicast across uncooperative networks. 510 When relaying traffic to the IPv6 network, the Differentiated Ser- 511 vices field [RFC2474], contained in the Traffic Class in the IPv6 512 header, SHOULD be retained inasfar as it cannot interfere with normal 513 network operation. When relaying traffic to the 6bed4 network, the 514 Differentiated Services field in the Traffic Class in the IPv6 header 515 SHOULD be used to fill the Type Of Service field in the IPv4 header, 516 inasfar as normal network operation permits. 518 5.4. Handling Router Solicitation from the 6bed4 Network 520 The 6bed4 Router MUST accept Router Solicitation messages from the 521 6bed4 Network. In addition, certain validation errors on the origin 522 of plain unicast messages are handled as if a Router Solicitation had 523 been received. 525 In response to a Router Solicitation, the 6bed4 Router MUST send a 526 Router Advertisement, which is sent back to the originator over the 527 6bed4 Network, so to the IPv4 address and UDP port over which the 528 incoming message arrived. The Router Advertisement sent MUST at 529 least include the Neighbor Discovery Option for Prefix. 531 The Prefix Option communicates the /64 prefix that the 6bed4 Router 532 has paired to the IPv4 address and UDP port combination over which 533 the incoming message was received; the Valid and Preferred Lifetime 534 fields are set to infinite by setting all bits to 1. 536 The IPv6 destination address of the Router Advertisement MUST be set 537 to fe80::/64 plus an Interface Identifier constructed from the UDP 538 port and IPv4 address from which the Router Solicitation was 539 received. 541 If the UDP port from which the Router Solicitation was received is an 542 odd number, then the lowest-value bit of the first byte in the Inter- 543 face Identifier of the IPv6 destination address of the Router Adver- 544 tisement MUST be set as an error indication. This informs the 6bed4 545 Peer that its UDP port is invalid, and that it should try again from 546 another port. Note that an odd UDP port number on a private address 547 [RFC1918] makes it more likely that an odd UDP port number is 548 assigned on the public Internet, and also that an odd UDP port number 549 can find its way into a 6bed4 Link-Local Address on a bypass route 550 over the local network; for these reason, an odd UDP port number 551 SHOULD be rejected when it is assigned locally, even in a private 552 address range. 554 5.5. Handling Router Advertisement from the 6bed4 Network 556 The 6bed4 Router MUST drop all Router Advertisements arriving over 557 the 6bed4 Network. 559 5.6. Handling Neighbor Solicitation from the 6bed4 Network 561 The 6bed4 Router accepts Neighbor Solicitation messages over the 562 6bed4 Network. Incoming packets are subject to the same validation 563 as before relaying plain unicast traffic, and will be dropped if the 564 validation fails. 566 The only validating Neighbor Solicitation messages to which the 6bed4 567 Router responds are those directed at its IPv6 address composed of 568 the /64 prefix used for 6bed4 plus its Interface Identifier, its IPv6 569 address composed of fe80::/64 plus its Interface Identifier, and 570 finally its IPv6 address fe80::/128. To all these, it will respond 571 with a Neighbor Advertisement that provides its 6bed4 Link-Local 572 Address in a Target Link-Local Address Neighbor Discovery Option. 574 5.7. Handling Neighbor Advertisement from the 6bed4 Network 576 The 6bed4 Router MUST drop all Neighbor Advertisements arriving over 577 the 6bed4 Network. 579 5.8. Handling Redirect from the 6bed4 Network 580 A 6bed4 Router MUST drop all Redirect messages arriving over the 581 6bed4 Network. 583 5.9. Handling Empty UDP Packets from the 6bed4 Network 585 Packets arriving over the 6bed4 Network may consist of nothing but an 586 IPv4 header and a UDP header, so without any UDP data. Such messages 587 may have been sent to keep an open connection to the 6bed4 Router, 588 especially by 6bed4 Peers behind Network Address Translators and/or 589 Firewalls. For this purpose, it is usually the outgoing traffic that 590 keeps a hole open, and no return traffic is required. Therefore, 591 such packets MAY be dropped. 593 5.10. Dealing with Packet Fragmentation 595 The IPv6 specifications define a minimal MTU that exceeds that of 596 IPv4; as a result, it is always possible for packets on the 6bed4 597 Network to be subjected to fragmentation. The 6bed4 Router SHOULD 598 NOT set the Don't Fragment flag [RFC0791] on IPv4 traffic and it 599 SHOULD be prepared to reconstruct packets from fragments. 601 The 6bed4 Router MAY reject packets in excess of the 1280 byte MTU 602 for IPv6 traffic; it MUST then respond with an ICMPv6 message of type 603 2, Packet Too Big. 605 6. 6bed4 Peer Behavior 607 Every 6bed4 Peer has a single 6bed4 Router that it uses as its gate- 608 way to the general IPv6 network, and possibly to other 6bed4 Peers on 609 the same 6bed4 Network to which it cannot create a bypass route. The 610 6bed4 Router has a fixed IPv6 /64 prefix setup for its 6bed4 Network. 611 The following details the behavior of the 6bed4 Peer over the 6bed4 612 Network defined by that prefix, both in its relation to its 6bed4 613 Router and to other 6bed4 Peers. 615 The following gives some background information about a possible 616 implementation of a 6bed4 Tunnel from the aforementioned conceptual 617 model. This involves the behavior of the 6bed4 Tunnel and its link 618 to the IPv6 stack over the 6bed4 Link. All such information should 619 be considered as non-normative illustrations; any equivalent imple- 620 mentation is acceptable. This specification is normative where it 621 concerns the behavior of the 6bed4 Peer over the 6bed4 Network. 623 6.1. Filtering Incoming Traffic 625 As a general precaution against spurious senders, the 6bed4 Peer MUST 626 filter traffic reaching it over the 6bed4 Network. The IPv4 address 627 and UDP port over which traffic originates should arrive over an 628 approved (bypass) route: 630 o Traffic from the 6bed4 Router's IPv4 address and UDP port TBD1 are 631 always acceptable; 633 o Traffic with an IPv6 source address under the /64 prefix that is 634 either fe80::/64 or the 64 prefix of the 6bed4 Network is accept- 635 able, provided that the IPv4 address and UDP port from which the 636 6bed4 Network traffic originated match the Interface Identifier of 637 the IPv6 source address. 639 o Traffic that originated from a directly attached IPv4 subnet MAY 640 be accepted if the implementation and configuration of the 6bed4 641 Peer support it. Note that the destination address MAY in this 642 case be the multicast address 224.0.0.1 for all nodes on the local 643 subnet, provided that it is used with UDP port TBD1. 645 Any other incoming traffic over the 6bed4 Network MUST be dropped. 647 Since other 6bed4 Peers also implement these tests, sending behavior 648 must match it. Any traffic that a 6bed4 Peer sends over the 6bed4 649 Network MUST originate from the 6bed4 Link-Local Address, even the 650 Router Solicitation sent to the 6bed4 Router. Normal sending of 651 UDP/IPv4 traffic from a socket would implement that automatically, 652 even if the 6bed4 Peer does not know its origin yet. IPv6 traffic 653 that is not a Router Solicitation MUST additionally use an IPv6 654 source address comprising of the IPv6 /64 prefix for the 6bed4 Net- 655 work, plus an Interface Identifier derived from the 6bed4 Link-Local 656 Address of the 6bed4 Peer. 658 6.2. 6bed4 Tunnel and Link-Layer Address Setup 660 Every 6bed4 Peer MUST have an assigned 6bed4 Router that it can use 661 as its default route to the general IPv6 network. This 6bed4 Router 662 MAY be configured, or it MAY be determined using some automated mech- 663 anism during initialization of the 6bed4 Peer. Furthermore, the 664 6bed4 Peer MAY iterate over a number of options until it finds one 665 that it finds acceptable. It SHOULD not change its 6bed4 Router 666 after it has decided to join its 6bed4 Network. 668 To be able to communicate on the 6bed4 Network attached to its 6bed4 669 Router, the 6bed4 Peer MUST obtain a 6bed4 Link-Local Address. To 670 obtain one, it sends a Router Solicitation to its 6bed4 Router. The 671 6bed4 Router responds with a Router Advertisement that is processed 672 as specified below, among others to derive the 6bed4 Link-Local 673 Address for the 6bed4 Peer. If this response is not received for 674 some time, then another Router Advertisement SHOULD be attempted, 675 observing an exponential fallback scheme to avoid overloading the 676 6bed4 Network. 678 In terms of the non-normative conceptual model, an accepted 6bed4 679 Link-Local Address can be assigned to the 6bed4 Tunnel, and the 6bed4 680 Link can be brought online. 682 When bringing the 6bed4 Peer online, he 6bed4 Peer MAY setup a 683 default route over the 6bed4 Network with the 6bed4 Router as a 684 default router; in terms of the non-normative conceptual model, the 685 router's address may be setup as fe80::/128 or as fe80::/64 plus the 686 Interface Identifier of the 6bed4 Router. 688 In addition to listening for traffic on the UDP port and IPv4 address 689 from which the 6bed4 Peer sends its traffic, it MAY also subscribe to 690 multicast traffic sent to IPv4 address 224.0.0.1 for all hosts on 691 local subnets, and UDP port TBD1. Subscribing to this port and pro- 692 cessing messages on it as though they arrived over the usual UDP port 693 and IPv4 address is optional, but for reasons of symmetric routing it 694 MUST be done if the 6bed4 Peer wants to be able to setup bypass 695 routes with the Low Metric. 697 6.3. Relaying Plain Unicast Traffic 699 The 6bed4 Peer relays between the 6bed4 Network and IPv6 stack, such 700 as over the 6bed4 Link proposed in the non-normative conceptual 701 model. 703 When plain unicast traffic passes from IPv6 to the 6bed4 Network, it 704 is assumed that a 6bed4 Link-Local Address is provided as the next 705 hop destination. From this next hop address, the IPv4 address and 706 UDP port are retrieved, and the IPv6 packet is sent to those coordi- 707 nates over the 6bed4 Network. 709 When relaying traffic to the 6bed4 network, the Differentiated Ser- 710 vices field in the Traffic Class in the IPv6 header SHOULD be used to 711 fill the Type Of Service field in the IPv4 header, inasfar as normal 712 network operation permits. 714 6.4. Relaying Plain Multicast Traffic 716 This specification places no restrictions on handling of plain multi- 717 cast traffic. As a result, a 6bed4 Router MAY drop all plain multi- 718 cast traffic, but extensions to this specification MAY be implemented 719 to support carrying multicast across uncooperative networks. 721 When plain multicast traffic arrives over the 6bed4 Network, the 722 6bed4 Peer MAY accept it for processing; in terms of the non-norma- 723 tive conceptual model, that would mean to relay it over the 6bed4 724 Link to the IPv6 stack. 726 A 6bed4 Peer MAY also support sending plain multicast traffic; to 727 that end, it MAY utilize the destination address 224.0.0.1 to reach 728 all IPv4 hosts on the local subnet, with UDP port TBD1 to select 729 6bed4 Peers. Multicast through the 6bed4 Router and to remote 6bed4 730 Peers are not covered by this specification. 732 When relaying traffic to the 6bed4 network, the Differentiated Ser- 733 vices field in the Traffic Class in the IPv6 header SHOULD be used to 734 fill the Type Of Service field in the IPv4 header, inasfar as normal 735 network operation permits. 737 6.5. Handling Router Solicitation from the 6bed4 Network 739 The 6bed4 Peer is normally not a router, because that would require a 740 /64 prefix under which to offer addresses. Therefore, incoming 741 attempts of Router Solicitation over the 6bed4 Network are usually a 742 mistake and SHOULD be dropped. 744 There is one possible exception though. A 6bed4 Peer MAY provide 745 leases over an additional protocol, such as DHCPv6. To that end, it 746 would substitute the middle two bytes of the Interface Identifier 747 with other values than the default 0xff,0xfe values and offer a 748 thusly constructed address; it would also serve as a router for any 749 such traffic. To make this possible, the 6bed4 Peer MAY send back 750 Router Advertisements with the Managed Address Configuration flag 751 set. 753 6.6. Handling Router Advertisement from the 6bed4 Network 755 Incoming Router Advertisement from the 6bed4 Network MUST be dropped 756 if its origin 6bed4 Address is not that of the 6bed4 Router assigned 757 to the 6bed4 Peer. 759 To be accepted, a Router Advertisement must have been sent by the 760 6bed4 Router, it MUST NOT have a set Managed Address Configuration 761 flag [RFC4861], it MUST have a Prefix Option with a /64 prefix, and 762 it MUST have an IPv6 destination address that starts with fe80::/64 763 and that has bytes 0xff,0xfe in the middle of the Interface Identi- 764 fier. This Interface Identifier MUST NOT have the lowest-value bit 765 in the first byte set, as that would indicate an error condition; 766 this is usually due to an odd UDP port as seen by the public Inter- 767 net. Since this is not permitted, the 6bed4 Peer SHOULD retry the 768 Router Solicitation if that happens, after switching to another UDP 769 port. It MUST NOT continue to communicate on the 6bed4 Network with 770 an UDP port that flagged this error. 772 If no MTU settings are provided as part of the Router Advertisement, 773 then the 6bed4 Peer MUST not assume more than the guaranteed minimum 774 MTU of 1280 for IPv6 networks without performing Path MTU Discovery. 776 When sent by the 6bed4 Router, the message MUST be treated as a new 777 announcement of a prefix and a 6bed4 Link-Local Address, possibly 778 replacing previously set values. The 6bed4 Peer MUST either remove 779 any old settings that do not match the new announcement, or deprecate 780 them and then it SHOULD remove them at a later time. When the 6bed4 781 Link-Local Address changed, then the hole punched in Network Address 782 Translators and/or Firewalls appears to have changed, so connections 783 through the 6bed4 Router are not likely to be able to continue; but 784 some connections through bypass routes may continue to work. 786 6.7. Handling Router Solicitation from the 6bed4 Link 788 This subsection is an illustration of a possible implementation; it 789 is non-normative. 791 The assumption in the conceptual model is that the 6bed4 Link has 792 been setup with a 6bed4 Link-Local Address before it is brought 793 online; this information is obtained with Router Discovery initiated 794 by the 6bed4 Peer. As a result, the 6bed4 Link's attempts to Router 795 Discovery are a bit late, but should nonetheless be handled. 797 When a Router Solicitation enters over the 6bed4 Link, it could be 798 responded to with a Router Advertisement holding a Prefix Option with 799 the /64 prefix obtained from the 6bed4 Router. The Default Router 800 Preference Field [RFC4191] may be set to Low, so as to prefer default 801 routing over native links, except for traffic targeted at the /64 802 prefix offered in this Router Advertisement. 804 6.8. Handling Router Advertisement from the 6bed4 Link 806 This subsection is an illustration of a possible implementation; it 807 is non-normative. 809 Any Router Advertisement arriving over the 6bed4 Link must be 810 dropped. 812 6.9. Handling Neighbor Solicitation from the 6bed4 Network 814 When a Neighbor Solicitation destined for one of its IPv6 addresses 815 enters a 6bed4 Peer over the 6bed4 Network, then a reply MUST be for- 816 mulated in the form of a Neighbor Advertisement. In terms of the 817 non-normative conceptual model, the message could be replicated to 818 the IPv6 stack through the 6bed4 Link. 820 6.10. Handling Neighbor Advertisement from the 6bed4 Network 822 When a Neighbor Advertisement arrives over the 6bed4 Network, then 823 the message will be normally processed; in terms of the non-normative 824 conceptual model, the message would be replicated to the IPv6 stack 825 over the 6bed4 Link. 827 Any work scheduled to find the target in the received Neighbor Adver- 828 tisement MUST be descheduled as a result of processing the Neighbor 829 Advertisement. 831 6.11. Handling Neighbor Solicitation from the 6bed4 Link 833 This subsection is an illustration of a possible implementation; it 834 is non-normative. 836 Neighbor Solicitation can be used by the IPv6 stack to avoid colli- 837 sions. This is not required on the 6bed4 Network, where addresses 838 are already unique if they are assigned through 6bed4 Link-Local 839 Addresses. Therefore, an attempt to verify the prior existence of an 840 IPv6 address based on this is not required. In terms of the non-nor- 841 mative conceptual model, this means that a Neighbor Solicitation 842 arriving over the 6bed4 Link and inquiring after the 6bed4 Network's 843 /64 prefix plus the Interface Identifier of the 6bed4 Peer should be 844 dropped. 846 In general however, Neighbor Solicitation serves attempts to contact 847 a remote 6bed4 Peer with an unknown 6bed4 Link-Local Address. In 848 terms of the non-normative conceptual model, that could be recognized 849 if the IPv6 stack sent a Neighbor Solicitation through the 6bed4 850 Link. 852 If the request is for an address that starts with fe80::/10 or 853 fe80::/64, then a Neighbor Advertisement must be provided by retriev- 854 ing the 6bed4 Link-Local Address from the Interface Identifier. The 855 only exception would be for address fe80::/128, which should be 856 interpreted as a reference to the 6bed4 Router; if it is requested, 857 then the 6bed4 Link-Layer Address of the 6bed4 Router must be pro- 858 vided in a Neighbor Advertisement sent back over the 6bed4 Link. 860 What remains is to process Neighbor Solicitation for remote 6bed4 861 Peers on the 6bed4 Network. The process run to obtain the 6bed4 862 Link-Local Address for these IPv6 addresses is to attempt all candi- 863 date bypasses in turn, by sending a Neighbor Solicitation to the can- 864 didate 6bed4 Address of the bypass. There may be a few attempts for 865 each candidate bypass to compensate for network losses. When a 866 Neighbor Advertisement is received in reply to one of these Neighbor 867 Solicitations, then the 6bed4 Link-Local Address is accepted as the 868 way to contact the requested target address, which is then relayed 869 back in the form of a Neighbor Advertisement to the IPv6 stack over 870 the 6bed4 Link. 872 Multiple bypass routes may be candidates for a single IPv6 target. 873 The search starts with the nearest-by targets, and ends with the far- 874 thest away. 876 The first bypass route is only useful if the local and remote 6bed4 877 Peers exhibit the same IPv4 address, and if the 6bed4 Peer subscribes 878 to (and also sends to) the multicast address 224.0.0.1 and UDP port 879 TBD1 for all 6bed4 nodes on the local network. If these conditions 880 apply, then the first candidate bypass to consider is found by send- 881 ing a Neighbor Solicitation for the target IPv6 address to this mul- 882 ticast address and port. 884 The second bypass route can be used anywhere, even if the local and 885 remote 6bed4 Peer exhibit the same IPv4 address. It is tried by 886 sending a Neighbor Solicitation to the IPv4 address and UDP port as 887 found in the 6bed4 Link-Local Address of the remote 6bed4 Peer. This 888 may work through a Pinhole or a direct connection, but in general it 889 would attempt contact through the outside of any Network Address 890 Translation device used by the remote 6bed4 Peer. Whether this works 891 depends on the types of NAT and Firewall in the path between the 892 6bed4 Peers. If both use symmetric NAT, then it will never work; if 893 only the remote side is symmetrical, then the initiative to find a 894 direct route must be initiated by the remote 6bed4 Peer, and a future 895 Redirect would be needed to restart the Neighbor Solicitation from 896 the local 6bed4 peer. But in many other situations, the direct con- 897 nection is likely to work. 899 Neighbor Advertisements sent in reply are handled as described above; 900 plus, they would cancel the search for bypass routes for the adver- 901 tised target, since a bypass appears to have been found. 903 Only if all bypass routes fail to respond within a reasonable time, 904 would it be necessary for the 6bed4 Peer to fallback to the 6bed4 905 Router. In terms of the non-normative conceptual model, it would 906 send a Neighbor Advertisement over the 6bed4 Link mentioning the 907 6bed4 Link-Local Address of the 6bed4 Router for the targeted remote 908 6bed4 Peer; in terms of that same model, the success in one of the 909 foregoing steps would result in sending a Neighbor Advertisement with 910 the succeeded 6bed4 Link-Layer Address for the targeted remote 6bed4 911 Peer. 913 Depending on the original Neighbor Solicitation, the bypass routes 914 attempted and reporting on it may be varied; for instance, for uni- 915 cast versions it may suffice to attempt only the bypass routes up to 916 and including the nearness of the requested form, and there is no 917 need to report the 6bed4 Router's address. 919 6.12. Handling Neighbor Advertisement from the 6bed4 Link 921 This subsection is an illustration of a possible implementation; it 922 is non-normative. 924 If the IPv6 stack relays a unicast Neighbor Advertisement message 925 over the 6bed4 Link, then the packet must be replicated and sent over 926 the 6bed4 Network. If it is a multicast version, then it may be 927 dropped. 929 6.13. Handling Redirect from the 6bed4 Network 931 It is necessary to send and receive 6bed4 traffic between two 6bed4 932 Peers over the same route; so either both send over the local net- 933 work, or both send to direct 6bed4 Link-Local Addresses, or both send 934 through the 6bed4 Router. This can be achieved by ensuring that the 935 same Metric applies in both directions. 937 If a route is established by one 6bed4 Peer, it knows that traffic 938 can pass bidirectionally, so it can safely assume that the remote 939 6bed4 Peer can use it also. If it receives traffic from a remote 940 6bed4 Peer over a bypass with a higher cost metric, then it SHOULD 941 send a Redirect message to the 6bed4 Peer, instructing it to continue 942 sending over the more direct route. In this Redirect message, it 943 MUST include as much of the causing message as it can fit in. The 944 Destination Address included MUST be made from the fe80::/64 prefix 945 plus the Interface Identifier of the 6bed4 Peer. The message MUST be 946 sent to the 6bed4 Peer over the bypass for which it indicates a pref- 947 erence. 949 Upon receiving a Redirect, as much as possible MUST be verified; the 950 causing packet if possible, the match between the 6bed4 Address over 951 which the packet arrived and the Interface Identifier of the Destina- 952 tion Address; whether the target is currently known to the local 953 6bed4 Peer; and whether the 6bed4 Link-Local Address in the Interface 954 Identifier would actually have been considered as a candidate 6bed4 955 Link-Local Address for the target. If any of these tests fails, then 956 the Redirect MUST be dropped. Otherwise, its processing SHOULD con- 957 sist of sending a Neighbor Solicitation to the proposed 6bed4 958 Address. If this leads to a Neighbor Advertisement that would also 959 have been acceptable to the normal process of Neighbor Discovery, 960 then it MUST be accepted as a replacement of the current 6bed4 Link- 961 Local Address for the target. In terms of the non-normative 962 conceptual model, this may be implemented with a Neighbor Advertise- 963 ment over the 6bed4 Link that has its Override flag set. 965 6.14. Handling Redirect from the 6bed4 Link 967 The 6bed4 Link is part of the non-normative conceptual model. If 968 this interface would generate a Redirect message, it must be ignored. 970 6.15. Dealing with Packet Fragmentation 972 The IPv6 specifications define a minimal MTU that exceeds that of 973 IPv4; as a result, it is always possible for packets on the 6bed4 974 Network to be subjected to fragmentation. The 6bed4 Peer SHOULD NOT 975 set the Don't Fragment flag [RFC791] on IPv4 traffic and it SHOULD be 976 prepared to reconstruct packets from fragments. 978 The 6bed4 Peer MAY reject packets in excess of the 1280 byte MTU for 979 IPv6 traffic; it MUST then respond with an ICMPv6 message of type 2, 980 Packet Too Big. 982 7. Impact of Firewalls and Network Address Translation 984 The 6bed4 mechanism has been carefully designed to work behind any 985 sequence of Firewalls or Network Address Translators. The reason 986 that it handles these well has two causes: First, it uses UDP, which 987 is an opaque carrier that is generally supported by these devices. 988 Second, the traffic is internally initiated, by sending a Router 989 Solicitation to a 6bed4 Router. This is the direction in which both 990 Firewalls and NAT open a hole that permits return traffic. 992 Since UDP is stateless, all holes in Firewalls and NAT are subject to 993 timeouts, and therefore regular traffic is needed to keep such holes 994 open. To this end, a message may be sent to the 6bed4 Router at a 995 regular interval, if no other traffic has been sent. In cases where 996 this fails, an outgoing message will be corrected with a new Router 997 Advertisement revealing the new 6bed4 Link-Local Address of the 6bed4 998 Peer. If this happens, any communication partners would conclude 999 that the 6bed4 Peer had gone offline; regular traffic may be pre- 1000 ferred to avoid this. 1002 It may be beneficial to support 6bed4 on servers or routers, even if 1003 they are connected through native IPv6. This could help to have more 1004 direct connectivity to popular 6bed4 Networks. If server nodes are 1005 located behind a sequence of Firewalls and/or NAT, then Port Forward- 1006 ing may be setup explicitly to fixate an IPv6 address, by avoiding 1007 UDP port changes. When this is done, the IPv6 address could safely 1008 be entered in DNS as a server address. 1010 8. Security Considerations 1012 The 6bed4 protocol uses configuration packets that were designed for 1013 local network use, but it employs them on the public Internet. This 1014 is not a change to be made lightly. Furthermore, 6bed4 is a tunnel 1015 protocol, which itself implies certain responsibilities. 1017 All tunnel protocols should reject forged inner addresses; the 6bed4 1018 Peer and 6bed4 Router tackle this by validating the address informa- 1019 tion upon entry; the IPv6 source address must match with the IPv4 1020 address and UDP port from which the packet originated. The only 1021 exception is the Router Advertisement sent to the 6bed4 Router, but 1022 this is a mindful choice, and the packet is not permitted to travel 1023 beyond the 6bed4 Router. 1025 The link between an IPv4 address (which is hopefully subjected to 1026 egress filtering) and the tunnel's inner IPv6 address means that it 1027 is not easier to forge an IPv6 address than it is to forge an IPv4 1028 address. Furthermore, the use of an IPv4 address as part of the IPv6 1029 address means that network attackers are as traceable on a 6bed4 Net- 1030 work as they are on the IPv4 network. 1032 This specification does not introduce anything that could cause a 1033 6bed4 Peer to contact a wrong 6bed4 Router; the mechanism for deter- 1034 mining the IPv4 address for that service falls outside the scope of 1035 this specification. 1037 Special attention is warranted for the Neighbor Advertisement and 1038 Router Advertisement messages, as these announce information that 1039 influences message redirection of a 6bed4 Peer. These concerns are 1040 addressed by the precaution to validate source addresses. In addi- 1041 tion, the information claimed is validated as per the behavioral 1042 specifications given above. 1044 Another specific concern relates to the ability to send Redirect 1045 packets. Once again, validation on source addresses addresses these 1046 concerns. In addition, the packet is only a hint and not an update 1047 instruction. When it is received, a Neighbor Solicitation process 1048 will only commence if the targeted 6bed4 Peer is already known to the 1049 6bed4 Peer. This process is predictable, so a Neighbor Advertisement 1050 could be crafted ahead of time; however, these Neighbor Advertise- 1051 ments are also subject to matching of the source address. 1053 In summary, the risks caused by the tunneling technique and the use 1054 of Neighbor Discovery style packets on the 6bed4 Network are limited 1055 to situations where it is possible to send traffic from forged IPv4 1056 address. In such situations, the problems are much more general and 1057 serious. 1059 9. IANA Considerations 1061 This specification allocates one resources from one existing reg- 1062 istry. 1064 9.1. Registered UDP port: 6bed4 1066 The registered port for the 6bed4 protocol is TBD1. This port is 1067 used to select 6bed4 traffic sent to a 6bed4 Router, as well as to 1068 the multicast address 224.0.0.1 for all nodes on the local subnet. 1070 [TO BE REMOVED: This UDP-only port number registration should take 1071 place at the following location: http://www.iana.org/assign- 1072 ments/port-numbers -- The port number MUST be an even number. I 1073 would like to request port number 25788 because it shows up in IPv6 1074 addresses as a recognizable ...:be64:...] 1076 10. References 1078 10.1. Normative References 1080 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1081 Address Autoconfiguration", RFC 4862, September 2007. 1083 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1084 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1085 September 2007. 1087 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Con- 1088 trol Message Protocol (ICMPv6) for the Internet Protocol 1089 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1091 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Archi- 1092 tecture", RFC 4291, February 2006. 1094 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1095 (IPv6) Specification", RFC 2460, December 1998. 1097 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1098 Address Translator (Traditional NAT)", RFC 3022, January 1099 2001. 1101 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Defini- 1102 tion of the Differentiated Services Field (DS Field) in 1103 the IPv4 and IPv6 Headers", RFC 2474, December 1998. 1105 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1106 and E. Lear, "Address Allocation for Private Internets", 1107 BCP 5, RFC 1918, February 1996. 1109 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1110 Requirement Levels", BCP 14, RFC 2119, March 1997. 1112 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1113 Networks", RFC 2464, December 1998. 1115 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1116 1981. 1118 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1119 More-Specific Routes", RFC 4191, November 2005. 1121 10.2. Informative References 1123 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Ser- 1124 vices", BCP 126, RFC 4786, December 2006. 1126 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1127 STD 13, RFC 1034, November 1987. 1129 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1130 RFC 2131, March 1997. 1132 Author's Address 1134 Rick van Rein 1135 OpenFortress Digital signatures 1136 Haarlebrink 5 1137 7544 WP Enschede 1138 The Netherlands 1140 email: rick@openfortress.nl