INTERNET-DRAFT Rick van Rein Intended Status: Proposed Standard OpenFortress Expires: September 12, 2012 March 11, 2012 6bed4: Peer-to-Peer IPv6 on Any Internetwork draft-vanrein-v6ops-6bed4-01 Abstract The intention of 6bed4 is to support IPv6-only applications, even on IPv4-only networks. A specific area of concern is that of peer-to- peer protocols such as SIP or document exchange during a chat session. Such protocols are designed to run in any environment, which means that they cannot rely on IPv6 for themselves, or their peers. The 6bed4 tunnel mechanism ensures that IPv6 can be assumed on all peers, without a need to configure it explicitly. The 6bed4 mechanism is meant as a fallback mechanism for IPv6 connectivity on networks that do not support it natively, by running a tunnel over UDP and IPv4. The IPv4 address is used to support traceability of the traffic originator, which means that no user account or other configuration is needed. The tunnel mechanism builds on existing IPv6 mechanisms; it employs Stateless Address Autoconfiguration [RFC4862] to setup an IPv6 address on a 6bed4 Peer, and Neighbor Discovery [RFC4861] to find the most direct route to a remote 6bed4 Peer. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html Van Rein Expires September 12, 2012 [Page 1] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Conceptual Model for a 6bed4 node . . . . . . . . . . . . . . 6 4. Link-Local Profile for 6bed4 . . . . . . . . . . . . . . . . . 9 5. 6bed4 Router Behavior . . . . . . . . . . . . . . . . . . . . 10 5.1. Address Information . . . . . . . . . . . . . . . . . . . 11 5.2. Relaying Plain Unicast Traffic . . . . . . . . . . . . . . 11 5.3. Relaying Plain Multicast Traffic . . . . . . . . . . . . . 12 5.4. Handling Router Solicitation from the 6bed4 Network . . . 12 5.5. Handling Router Advertisement from the 6bed4 Network . . . 13 5.6. Handling Neighbor Solicitation from the 6bed4 Network . . 13 5.7. Handling Neighbor Advertisement from the 6bed4 Network . . 13 5.8. Handling Redirect from the 6bed4 Network . . . . . . . . . 13 5.9. Handling Empty UDP Packets from the 6bed4 Network . . . . 14 5.10. Dealing with Packet Fragmentation . . . . . . . . . . . . 14 6. 6bed4 Peer Behavior . . . . . . . . . . . . . . . . . . . . . 14 6.1. Filtering Incoming Traffic . . . . . . . . . . . . . . . . 14 6.2. 6bed4 Tunnel and Link-Layer Address Setup . . . . . . . . 15 6.3. Relaying Plain Unicast Traffic . . . . . . . . . . . . . . 16 6.4. Relaying Plain Multicast Traffic . . . . . . . . . . . . . 16 6.5. Handling Router Solicitation from the 6bed4 Network . . . 17 6.6. Handling Router Advertisement from the 6bed4 Network . . . 17 6.7. Handling Router Solicitation from the 6bed4 Link . . . . . 18 6.8. Handling Router Advertisement from the 6bed4 Link . . . . 18 6.9. Handling Neighbor Solicitation from the 6bed4 Network . . 18 6.10. Handling Neighbor Advertisement from the 6bed4 Network . 18 6.11. Handling Neighbor Solicitation from the 6bed4 Link . . . 19 6.12. Handling Neighbor Advertisement from the 6bed4 Link . . . 21 Van Rein Expires September 12, 2012 [Page 2] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 6.13. Handling Redirect from the 6bed4 Network . . . . . . . . 21 6.14. Handling Redirect from the 6bed4 Link . . . . . . . . . . 22 6.15. Dealing with Packet Fragmentation . . . . . . . . . . . . 22 7. Impact of Firewalls and Network Address Translation . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9.1. Registered UDP port: 6bed4 . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 Van Rein Expires September 12, 2012 [Page 3] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 1. Introduction The 6bed4 mechanism is a fallback for networks that have no support for IPv6. It is designed to work without configuration on any network that is not secured beyond common defaults. It works behind any sequence of Network Address Translating (NAT) devices and Firewalls, and it does not require support (such as protocol 41) from any of those devices. The local network may or may not support IPv6 already; and also upstream network providers may or may not support IPv6. The 6bed4 traffic does not mingle with local IPv6 traffic, so it will never raise alarms that monitor native local IPv6 traffic for potential IPv6-specific attacks. All traffic on the 6bed4 Network is embedded in UDP and IPv4. The 6bed4 Network is thereby layered on top of the IPv4 Internet. Common default configurations for NAT and firewalls support UDP [RFC3022] [RFC4787], as long as the communication is initiated internally. This is precisely what 6bed4 does. This traffic is exchanged between 6bed4 Peers, which are the endpoints in the communication. They may pass their traffic through a 6bed4 Router. A 6bed4 Router recognizes 6bed4 traffic because it is received on the standard UDP port TBD1, and it recognizes IPv6 addresses as 6bed4 addresses because they start with the /64 prefix that it has dedicated to 6bed4. Such IPv6 prefixes are paired to the IPv4 address and UDP port of the 6bed4 Router. The IPv4 address and UDP port as seen from the Internet are combined to form a link-layer address, from which an Interface Identifier is constructed in the same way as for Ethernet Networks [RFC2464]. This implies that the IPv4 address and UDP port are shown as part of the IPv6 address. This supports traceback of a traffic originator in case of abuse, without a need to register accounts or login to them. Every 6bed4 Router validate that the IPv4 address and UDP port in the IPv6 address against the actual traffic, so the properties of egress filtering on IPv4 packets are inherited by the 6bed4 Network. The simplest mode of communication between to 6bed4 Peers is to communicate through a 6bed4 Router. This service relays between 6bed4 traffic and native IPv6 or, if both IPv6 addresses are IPv6 addresses under the same 6bed4 prefix, then a 6bed4 Router relays the traffic between the 6bed4 Peers, using its own IPv4 address and UDP port when forwarding a packet over 6bed4 to the destination. Traffic intended for addresses that the 6bed4 Router does not handle as 6bed4 prefixes are relayed as IPv6 over normal IPv6 routes. It is normal for a 6bed4 Peer to attempt to bypass the 6bed4 Router by contacting remote peers directly. One such bypass that every Van Rein Expires September 12, 2012 [Page 4] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 6bed4 Peer MUST attempt is to contact 6bed4 Peers at the IPv4 address and UDP port contained in their Interface Identifier. Other bypassing mechanisms may also be tried; the success or failure of each bypass method depends on co-operation of intermediate network nodes. Rather than devising a model of these intermediate nodes, 6bed4 Peers simply try to send Neighbor Solicitation over a candidate bypass, and when the remote 6bed4 Peer replies with a matching Neighbor Advertisement, then the bypass is fit for use. If the reply does not arrive, the 6bed4 Peer can still fallback to the 6bed4 Router for that remote 6bed4 Peer. Information about bypasses to a 6bed4 Peer should be cached for some time. A good place to do this is the Neighbor Cache, which retains such information for tens of seconds [RFC4861]. This happens automatically if the IPv6 stack that uses a 6bed4 Link for IPv6 connectivity is used to relay link-layer addresses for the 6bed4 Network; such link-layer addresses would be composed of the IPv4 address and UDP port needed to contact the 6bed4 Peer over the 6bed4 Network. Whenever the IPv6 stack sends a Neighbor Solicitation down the 6bed4 Link, the 6bed4 Peer will know that it should try a number of bypasses for that route, once again using Neighbor Discovery. When no bypasses work, then the link-local address of the 6bed4 Router is passed back up to the IPv6 stack. [TO BE REMOVED: Code demonstrating this specification is, or will soon be, available on http://devel.0cpm.org/6bed4/ -- please contact the author for details, information and feedback] 2. Definitions The following definitions will be used throughout this document. A 6bed4 Router is a network node connected to both IPv4 and IPv6 networks, which supports the translation of a particular IPv6 /64 prefix to 6bed4 and back. The IPv6 prefix forms a pair with the router's IPv4 address and UDP port for 6bed4. A 6bed4 Router may translate traffic bidirectionally, or in the case of more advanced routing topologies, it could rest on the assumption that another 6bed4 Router to perform the reverse translation for the same pair of IPv6 prefix and IPv4/UDP coordinates. A 6bed4 Peer is a communication endpoint that uses 6bed4 to embed IPv6 packets in UDP and IPv4. It has a relationship to one 6bed4 Router which serves as its default router and as a fallback for remote 6bed4 Peers that cannot be connected to directly. A bypass or bypass route is a connection between two 6bed4 Peers that Van Rein Expires September 12, 2012 [Page 5] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 does not run through a 6bed4 Router. A 6bed4 Network comprises of the 6bed4 Router(s) and all 6bed4 Peers. This may include bypass routes that connect over a local network, even using private IPv4 addresses [RFC1918]. The identity of a 6bed4 Network is its IPv6 /64 prefix as supplied by its 6bed4 Router(s). A 6bed4 Link is a (virtual) network interface that is offered to an IPv6 stack that wants to use it to link to IPv6 nodes. This term is non-normative; it is introduced below as part of the conceptual model for a 6bed4 Peer. A 6bed4 Tunnel is the connection between a 6bed4 Link and the 6bed4 Network. This term is non-normative; it is introduced below as part of the conceptual model for a 6bed4 Peer. A 6bed4 Address is a pair of an IPv4 address and UDP port that can be used as an endpoint on the 6bed4 Network, at the very least to its 6bed4 Router and possibly through Bypass Routes from other 6bed4 Peers as well. The IPv4 address and UDP port are the values as seen by the public Internet. This is a conceptual notion, free from any representation in network packets. A 6bed4 Link-Local Address is a particular representation of a 6bed4 Address. It is employed in network packets for Neighbor Discovery, Router Discovery and Redirect messages. Plain traffic is defined as IPv6 traffic that is not one of the special ICMPv6 [RFC4443] types Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement or Redirect. The Metric, or Communication Cost Metric, of communicating to a given 6bed4 Address is an indication of the relative cost of a number of possible routes; a bypass route to a local subnet ranks as Low, a bypass route directly to the UDP port and IPv4 address of a remote 6bed4 Peer ranks as Medium and a route to the 6bed4 Router ranks as High. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Conceptual Model for a 6bed4 node A 6bed4 node is a network node that acts as a 6bed4 Router or a 6bed4 Peer. This conceptual model for a 6bed4 nodes is non-normative; the Van Rein Expires September 12, 2012 [Page 6] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 terms and layers it introduces are intended for illustration purposes, but any equivalent implementation would be equally suitable. The conceptual model of the internal structure of a 6bed4 node is based on what is called a tunnel in many operating systems; this is a structure which acts as a network interface on one end, and gives programmatic control over packet handling on the other end. An IPv6 stack can access the 6bed4 services through a 6bed4 Link. The 6bed4 Link is the network side of a 6bed4 Tunnel. This 6bed4 Link acts as a level 2 service to an IPv6 stack. The programmatic side of the 6bed4 Tunnel uses the level 4 service of a UDP/IPv4 stack. The function of the 6bed4 Tunnel is to translate packets between these two interfaces. : : | IPv6 stack | +-------++-------+ || <-- 6bed4 Link || Layer 2 transport: IPv6 over a link-layer protocol \/ +-------++-------+ | 6bed4 Tunnel | +-------++-------+ || || Layer 4 transport: IPv6 over UDP/IPv4 \/ +-------++-------+ | UDP/IPv4 stack | <-- 6bed4 Network : : The translation of plain traffic is a matter of adding or removing headers into which an IPv6 packet is embedded. On the IPv6 end, some form of header information revealing the 6bed4 Link-Local Address of the next-hop destination must be present, and on the IPv4 end there are UDP/IPv4 headers. Since 6bed4 Link-Local Addresses incorporate the destination's UDP port and IPv4 address, a complete translation between these two prefixed headers is possible. This is what is done with plain traffic. An exception is made for Router Discovery, Neighbor Discovery and Redirect messages. These were designed for local use, and should therefore be treated differently; the messages are exchanged between the IPv6 stack and the 6bed4 Tunnel, and somewhat independently between the 6bed4 Tunnel and the 6bed4 Network. relayed through a tunnel. These messages are therefore handled explicitly by the 6bed4 Tunnel. Van Rein Expires September 12, 2012 [Page 7] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 The link-layer address of a 6bed4 Link is not normally known as soon as the 6bed4 Link is created, as it relies on observations made on the Public Internet. To obtain this link-layer address, the 6bed4 Tunnel will send a Router Solicitation to its 6bed4 Router. The 6bed4 Router responds with a Router Advertisement containing the 6bed4 Peer's Interface Identifier as the IPv6 destination address. From this address, the 6bed4 Peer's link-layer address is derived and assigned to the 6bed4 Link; this also serves as the 6bed4 Link-Layer Address when communicating on the 6bed4 Network. This information is usually be exchanged prior to bringing up the 6bed4 Link. The prefix information from the Router Advertisement is held back until the IPv6 stack on top of the 6bed4 Link sends a Router Solicitation. In response to that, a Router Advertisement is sent to the IPv6 stack that holds the prefix. The IPv6 stack is assumed to reconstruct the Interface Identifier from the link-layer address, prefix it with the Router Solicitation's prefix and assign the resulting address to the 6bed4 Link. Any attempts to perform Neighbor Discovery on its own address should be dropped in the 6bed4 Tunnel, as it is safe to assume that no competition for the link- layer address and its derived full address exists. The 6bed4 Link is now configured with a /64 prefix and a default route through the 6bed4 Router. Any IPv6 addresses starting with the /64 prefix handled by the 6bed4 Router are treated by the IPv6 stack as local traffic to be contacted through the 6bed4 Link, and any other IPv6 traffic may be forwarded to the 6bed4 Router. Whenever the IPv6 stack needs to find either the 6bed4 Router or a 6bed4 Peer with the same /64 prefix, it will perform Neighbor Discovery on the 6bed4 Link. The 6bed4 Tunnel handles these especially, in an attempt to create a bypass when possible. To this end, it will first try one or more bypasses before falling back to the 6bed4 Router. The 6bed4 Tunnel will first try a few times to send Neighbor Solicitation messages with the targeted IPv6 address to the direct IPv4 address and UDP port of the remote 6bed4 Peer. When this results in a matching Neighbor Advertisement, it will relay that knowledge through Neighbor Advertisement to the IPv6 stack, which will note it in its Neighbor Cache. If it fails to receive such a response, but before the IPv6 stack times out on its Neighbor Solicitation, the 6bed4 Tunnel will instead send back a Neighbor Advertisement announcing the 6bed4 Link-Local Address of the 6bed4 Router. Among the possibly found direct routes may be Pinholes, which relay the traffic back to the local network. These Pinholes, as well as Van Rein Expires September 12, 2012 [Page 8] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 any other bypass routes through a hole in a Network Address Translator or Firewall, are subject to timeouts. It is useful to realize that Neighbor Caches tend to hold a Link-Local Address for "tens of seconds" [RFC4861] and then either drop it or revitalize it through another Neighbor Discovery attempt. These delays are smaller than common expiration times of holes in NAT or Firewalls, so no Neighbor Cache parameter changes should normally be needed to sustain a connection between 6bed4 Peers communicating through any of these bypasses. It is even find a better bypass than a Pinhole if a direct connection to a locally connected 6bed4 Peer is possible. This may be considered for contact between 6bed4 Peers that exhibit the same public IPv4 address. Those may be sought through multicasting a Neighbor Solicitation over 6bed4 on the local IPv4 network, by sending to the address for all IPv4 nodes on the current subnet, or 224.0.0.1, using the standard UDP port TBD1 to select 6bed4 Peers. To keep a hole in a Firewall or NAT open while it is in active use, it is generally useful to pass traffic in both directions; this means that two 6bed4 Peers must use the same route to pass traffic between each other. In exceptional cases however, asymmetric routes may be learnt. This may be remedied with a Redirect message that requests a 6bed4 Peer to change to a more efficient bypass. Redirect messages will never be sent to request changing to a route with a higher Metric, but only to a bypass with a lower Metric. In order of rising Metric, the available bypass mechanisms are: o Low: Traffic sent to locally attached private addresses [RFC1918] (Optionally supported) o Medium: Traffic sent to the IPv4 address and UDP port in the 6bed4 Link-Local Address o High: Traffic sent through the 6bed4 Router Note that these variations can be distinguished easily by observing the IPv4 address targeted. Also note that the third routing mecha- nism would not add anything to local networks by supporting publicly routed addresses, as the second mechanism provides sufficient support for optimal bypasses on such networks. 4. Link-Local Profile for 6bed4 Each 6bed4 Link-Local Address contains the UDP port and IPv4 address as observed on the public Internet. This means that it is 6 bytes in Van Rein Expires September 12, 2012 [Page 9] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 size. The format is as follows: 0 47 +-------+-------+-------+-------+-------+-------+ | UDP.1 | UDP.0 |IPv4.0 |IPv4.1 |IPv4.2 |IPv4.3 | +-------+-------+-------+-------+-------+-------+ The UDP port is encoded in two bytes, where UDP.0 UDP.1 would be the network byte order; note that the bytes in the 6bed4 Link-Local Address are included in the reverse of network byte order. The IPv4 address bytes are represented in the network byte order, IPv4.0 IPv4.1 IPv4.2 IPv4.3. The UDP port MUST be an even number. The lowest-valued bit of UDP.1 is reserved to indicate a multicast address, when it is set. In sit- uations where multicast addresses are known to be impossible, the bit may alternately be interpreted as an error indication. The 64 bits of Interface Identifier to follow a /64 prefix can be derived from the 6bed4 Link-Local Address as it is done for 6-byte Ethernet addresses, as follows: 0 63 +-------+-------+-------+-------+-------+-------+-------+-------+ | UDP.1'| UDP.0 |IPv4.0 | 0xff | 0xfe |IPv4.1 |IPv4.2 |IPv4.3 | +-------+-------+-------+-------+-------+-------+-------+-------+ In this representation UDP.1' is UDP.1, bitwise xor-ed with 0x02. The result is the EUI-64 address derivation that is also used for Ethernet Networks [RFC2464]. Multicast addresses for IPv6 are also constructed as for Ethernet, resulting in the following format: 0 47 +-------+-------+-------+-------+-------+-------+ | 0x33 | 0x33 |IPv6.12|IPv6.13|IPv6.14|IPv6.15| +-------+-------+-------+-------+-------+-------+ The bytes IPv6.12 through IPv6.15 are the last four bytes of the IPv6 address sought over multicast. 5. 6bed4 Router Behavior The 6bed4 Router services 6bed4 Peers with Router Solicitation requests, and by relaying any traffic that it cannot automatically direct. The following definitions specify the behavior in detail. Van Rein Expires September 12, 2012 [Page 10] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 The description below assumes that the 6bed4 Router acts bidirection- ally; note that a split of this function over multiple network nodes is thinkable, in which case their combined behavior should match these specifications. 5.1. Address Information A 6bed4 Router offers its services on an IPv4 address and the UDP port TBD1. The IPv4 address varies between 6bed4 Routers, and may be found through various means; it may be hard-coded into 6bed4 Tunnel software, it may be an Anycast address [RFC4786], or it may be found through IPv4 application protocols such as DNS [RFC1034] or DHCP [RFC2131]. The combined IPv4 address and UDP port form its 6bed4 Address, which will sometimes be represented as its 6bed4 Link-Local Address. Traffic arriving at this UDP/IPv4 combination is said to have arrived from the 6bed4 Network. Similarly, whenever the 6bed4 Router sends traffic over the 6bed4 Network, so when addressing a 6bed4 Peer, it MUST send from that same IPv4 address and UDP port. The IPv4 address and UDP port are paired with a IPv6 /64 prefix for which the 6bed4 Router serves as a router. The prefix is assumed to be assigned indefinitely to the 6bed4 Router. 5.2. Relaying Plain Unicast Traffic The 6bed4 Router relays plain unicast traffic between 6bed4 Peers, as well as between 6bed4 Peers and the general IPv6 Internet. This sec- tion describes how this is done. Upon arrival of plain unicast traffic over the 6bed4 Network, the 6bed4 Router MUST validate that the sender's IPv6 address is correct; this means that the /64 prefix MUST match the prefix serviced by the 6bed4 Router, and that the IPv4 address and UDP port as shown in the Interface Identifier MUST match the parameters of the incoming 6bed4 message. This certifies the IPv6 address of the 6bed4 Peer as well as its IPv4 address is certified. The value of the bytes 0xff and 0xfe in the default Interface Identifier MUST NOT be validated, as these may vary when the sending 6bed4 Peer acts as a local router. If only the Interface Identifier fails validation, then the 6bed4 Router MUST proceed as if it had received a Router Solicitation over the 6bed4 Network. The 6bed4 Router MUST drop all other 6bed4 traf- fic that fails validation. The remainder of this section applies only to plain unicast traffic that passed validation. When the destination address starts with the /64 prefix that the Van Rein Expires September 12, 2012 [Page 11] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 6bed4 Router announces to 6bed4 Peers, then the destination is con- sidered to be on the 6bed4 Network. Otherwise, it is considered a general IPv6 address, and MUST be routed through a general IPv6 net- work to which the 6bed4 Router is connected. To route a network packet to the 6bed4 Network, the 6bed4 Router MUST extract the IPv4 address and UDP port from the Interface Identifier part of the IPv6 destination address, and forward the packet over UDP and IPv4 to those coordinates. When relaying traffic to the IPv6 network, the Differentiated Ser- vices field [RFC2474], contained in the Traffic Class in the IPv6 header, SHOULD be retained inasfar as it cannot interfere with normal network operation. When relaying traffic to the 6bed4 network, the Differentiated Services field in the Traffic Class in the IPv6 header SHOULD be used to fill the Type Of Service field in the IPv4 header, inasfar as normal network operation permits. 5.3. Relaying Plain Multicast Traffic This specification places no restrictions on handling of plain multi- cast traffic. As a result, a 6bed4 Router MAY drop all plain multi- cast traffic, but extensions to this specification MAY be implemented to support carrying multicast across uncooperative networks. When relaying traffic to the IPv6 network, the Differentiated Ser- vices field [RFC2474], contained in the Traffic Class in the IPv6 header, SHOULD be retained inasfar as it cannot interfere with normal network operation. When relaying traffic to the 6bed4 network, the Differentiated Services field in the Traffic Class in the IPv6 header SHOULD be used to fill the Type Of Service field in the IPv4 header, inasfar as normal network operation permits. 5.4. Handling Router Solicitation from the 6bed4 Network The 6bed4 Router MUST accept Router Solicitation messages from the 6bed4 Network. In addition, certain validation errors on the origin of plain unicast messages are handled as if a Router Solicitation had been received. In response to a Router Solicitation, the 6bed4 Router MUST send a Router Advertisement, which is sent back to the originator over the 6bed4 Network, so to the IPv4 address and UDP port over which the incoming message arrived. The Router Advertisement sent MUST at least include the Neighbor Discovery Option for Prefix. The Prefix Option communicates the /64 prefix that the 6bed4 Router has paired to the IPv4 address and UDP port combination over which Van Rein Expires September 12, 2012 [Page 12] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 the incoming message was received; the Valid and Preferred Lifetime fields are set to infinite by setting all bits to 1. The IPv6 destination address of the Router Advertisement MUST be set to fe80::/64 plus an Interface Identifier constructed from the UDP port and IPv4 address from which the Router Solicitation was received. If the UDP port from which the Router Solicitation was received is an odd number, then the lowest-value bit of the first byte in the Inter- face Identifier of the IPv6 destination address of the Router Adver- tisement MUST be set as an error indication. This informs the 6bed4 Peer that its UDP port is invalid, and that it should try again from another port. Note that an odd UDP port number on a private address [RFC1918] makes it more likely that an odd UDP port number is assigned on the public Internet, and also that an odd UDP port number can find its way into a 6bed4 Link-Local Address on a bypass route over the local network; for these reason, an odd UDP port number SHOULD be rejected when it is assigned locally, even in a private address range. 5.5. Handling Router Advertisement from the 6bed4 Network The 6bed4 Router MUST drop all Router Advertisements arriving over the 6bed4 Network. 5.6. Handling Neighbor Solicitation from the 6bed4 Network The 6bed4 Router accepts Neighbor Solicitation messages over the 6bed4 Network. Incoming packets are subject to the same validation as before relaying plain unicast traffic, and will be dropped if the validation fails. The only validating Neighbor Solicitation messages to which the 6bed4 Router responds are those directed at its IPv6 address composed of the /64 prefix used for 6bed4 plus its Interface Identifier, its IPv6 address composed of fe80::/64 plus its Interface Identifier, and finally its IPv6 address fe80::/128. To all these, it will respond with a Neighbor Advertisement that provides its 6bed4 Link-Local Address in a Target Link-Local Address Neighbor Discovery Option. 5.7. Handling Neighbor Advertisement from the 6bed4 Network The 6bed4 Router MUST drop all Neighbor Advertisements arriving over the 6bed4 Network. 5.8. Handling Redirect from the 6bed4 Network Van Rein Expires September 12, 2012 [Page 13] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 A 6bed4 Router MUST drop all Redirect messages arriving over the 6bed4 Network. 5.9. Handling Empty UDP Packets from the 6bed4 Network Packets arriving over the 6bed4 Network may consist of nothing but an IPv4 header and a UDP header, so without any UDP data. Such messages may have been sent to keep an open connection to the 6bed4 Router, especially by 6bed4 Peers behind Network Address Translators and/or Firewalls. For this purpose, it is usually the outgoing traffic that keeps a hole open, and no return traffic is required. Therefore, such packets MAY be dropped. 5.10. Dealing with Packet Fragmentation The IPv6 specifications define a minimal MTU that exceeds that of IPv4; as a result, it is always possible for packets on the 6bed4 Network to be subjected to fragmentation. The 6bed4 Router SHOULD NOT set the Don't Fragment flag [RFC0791] on IPv4 traffic and it SHOULD be prepared to reconstruct packets from fragments. The 6bed4 Router MAY reject packets in excess of the 1280 byte MTU for IPv6 traffic; it MUST then respond with an ICMPv6 message of type 2, Packet Too Big. 6. 6bed4 Peer Behavior Every 6bed4 Peer has a single 6bed4 Router that it uses as its gate- way to the general IPv6 network, and possibly to other 6bed4 Peers on the same 6bed4 Network to which it cannot create a bypass route. The 6bed4 Router has a fixed IPv6 /64 prefix setup for its 6bed4 Network. The following details the behavior of the 6bed4 Peer over the 6bed4 Network defined by that prefix, both in its relation to its 6bed4 Router and to other 6bed4 Peers. The following gives some background information about a possible implementation of a 6bed4 Tunnel from the aforementioned conceptual model. This involves the behavior of the 6bed4 Tunnel and its link to the IPv6 stack over the 6bed4 Link. All such information should be considered as non-normative illustrations; any equivalent imple- mentation is acceptable. This specification is normative where it concerns the behavior of the 6bed4 Peer over the 6bed4 Network. 6.1. Filtering Incoming Traffic As a general precaution against spurious senders, the 6bed4 Peer MUST filter traffic reaching it over the 6bed4 Network. The IPv4 address Van Rein Expires September 12, 2012 [Page 14] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 and UDP port over which traffic originates should arrive over an approved (bypass) route: o Traffic from the 6bed4 Router's IPv4 address and UDP port TBD1 are always acceptable; o Traffic with an IPv6 source address under the /64 prefix that is either fe80::/64 or the 64 prefix of the 6bed4 Network is accept- able, provided that the IPv4 address and UDP port from which the 6bed4 Network traffic originated match the Interface Identifier of the IPv6 source address. o Traffic that originated from a directly attached IPv4 subnet MAY be accepted if the implementation and configuration of the 6bed4 Peer support it. Note that the destination address MAY in this case be the multicast address 224.0.0.1 for all nodes on the local subnet, provided that it is used with UDP port TBD1. Any other incoming traffic over the 6bed4 Network MUST be dropped. Since other 6bed4 Peers also implement these tests, sending behavior must match it. Any traffic that a 6bed4 Peer sends over the 6bed4 Network MUST originate from the 6bed4 Link-Local Address, even the Router Solicitation sent to the 6bed4 Router. Normal sending of UDP/IPv4 traffic from a socket would implement that automatically, even if the 6bed4 Peer does not know its origin yet. IPv6 traffic that is not a Router Solicitation MUST additionally use an IPv6 source address comprising of the IPv6 /64 prefix for the 6bed4 Net- work, plus an Interface Identifier derived from the 6bed4 Link-Local Address of the 6bed4 Peer. 6.2. 6bed4 Tunnel and Link-Layer Address Setup 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. To be able to communicate on the 6bed4 Network attached to its 6bed4 Router, the 6bed4 Peer MUST obtain a 6bed4 Link-Local Address. To obtain one, it sends a Router Solicitation to its 6bed4 Router. The 6bed4 Router responds with a Router Advertisement that is processed as specified below, among others to derive the 6bed4 Link-Local Address for the 6bed4 Peer. If this response is not received for Van Rein Expires September 12, 2012 [Page 15] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 some time, then another Router Advertisement SHOULD be attempted, observing an exponential fallback scheme to avoid overloading the 6bed4 Network. In terms of the non-normative conceptual model, an accepted 6bed4 Link-Local Address can be assigned to the 6bed4 Tunnel, and the 6bed4 Link can be brought online. When bringing the 6bed4 Peer online, he 6bed4 Peer MAY setup a default route over the 6bed4 Network with the 6bed4 Router as a default router; in terms of the non-normative conceptual model, the router's address may be setup as fe80::/128 or as fe80::/64 plus the Interface Identifier of the 6bed4 Router. In addition to listening for traffic on the UDP port and IPv4 address from which the 6bed4 Peer sends its traffic, it MAY also subscribe to multicast traffic sent to IPv4 address 224.0.0.1 for all hosts on local subnets, and UDP port TBD1. Subscribing to this port and pro- cessing messages on it as though they arrived over the usual UDP port and IPv4 address is optional, but for reasons of symmetric routing it MUST be done if the 6bed4 Peer wants to be able to setup bypass routes with the Low Metric. 6.3. Relaying Plain Unicast Traffic The 6bed4 Peer relays between the 6bed4 Network and IPv6 stack, such as over the 6bed4 Link proposed in the non-normative conceptual model. When plain unicast traffic passes from IPv6 to the 6bed4 Network, it is assumed that a 6bed4 Link-Local Address is provided as the next hop destination. From this next hop address, the IPv4 address and UDP port are retrieved, and the IPv6 packet is sent to those coordi- nates over the 6bed4 Network. When relaying traffic to the 6bed4 network, the Differentiated Ser- vices field in the Traffic Class in the IPv6 header SHOULD be used to fill the Type Of Service field in the IPv4 header, inasfar as normal network operation permits. 6.4. Relaying Plain Multicast Traffic This specification places no restrictions on handling of plain multi- cast traffic. As a result, a 6bed4 Router MAY drop all plain multi- cast traffic, but extensions to this specification MAY be implemented to support carrying multicast across uncooperative networks. When plain multicast traffic arrives over the 6bed4 Network, the Van Rein Expires September 12, 2012 [Page 16] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 6bed4 Peer MAY accept it for processing; in terms of the non-norma- tive conceptual model, that would mean to relay it over the 6bed4 Link to the IPv6 stack. A 6bed4 Peer MAY also support sending plain multicast traffic; to that end, it MAY utilize the destination address 224.0.0.1 to reach all IPv4 hosts on the local subnet, with UDP port TBD1 to select 6bed4 Peers. Multicast through the 6bed4 Router and to remote 6bed4 Peers are not covered by this specification. When relaying traffic to the 6bed4 network, the Differentiated Ser- vices field in the Traffic Class in the IPv6 header SHOULD be used to fill the Type Of Service field in the IPv4 header, inasfar as normal network operation permits. 6.5. Handling Router Solicitation from the 6bed4 Network The 6bed4 Peer is normally not a router, because that would require a /64 prefix under which to offer addresses. Therefore, incoming attempts of Router Solicitation over the 6bed4 Network are usually a mistake and SHOULD be dropped. There is one possible exception though. A 6bed4 Peer MAY provide leases over an additional protocol, such as DHCPv6. To that end, it would substitute the middle two bytes of the Interface Identifier with other values than the default 0xff,0xfe values and offer a thusly constructed address; it would also serve as a router for any such traffic. To make this possible, the 6bed4 Peer MAY send back Router Advertisements with the Managed Address Configuration flag set. 6.6. Handling Router Advertisement from the 6bed4 Network Incoming Router Advertisement from the 6bed4 Network MUST be dropped if its origin 6bed4 Address is not that of the 6bed4 Router assigned to the 6bed4 Peer. To be accepted, a Router Advertisement must have been sent by the 6bed4 Router, it MUST NOT have a set Managed Address Configuration flag [RFC4861], it MUST have a Prefix Option with a /64 prefix, and it MUST have an IPv6 destination address that starts with fe80::/64 and that has bytes 0xff,0xfe in the middle of the Interface Identi- fier. This Interface Identifier MUST NOT have the lowest-value bit in the first byte set, as that would indicate an error condition; this is usually due to an odd UDP port as seen by the public Inter- net. Since this is not permitted, the 6bed4 Peer SHOULD retry the Router Solicitation if that happens, after switching to another UDP port. It MUST NOT continue to communicate on the 6bed4 Network with Van Rein Expires September 12, 2012 [Page 17] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 an UDP port that flagged this error. 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. When sent by the 6bed4 Router, the message MUST be treated as a new announcement of a prefix and a 6bed4 Link-Local Address, possibly replacing previously set values. The 6bed4 Peer MUST either remove any old settings that do not match the new announcement, or deprecate them and then it SHOULD remove them at a later time. When the 6bed4 Link-Local Address changed, then the hole punched in Network Address Translators and/or Firewalls appears to have changed, so connections through the 6bed4 Router are not likely to be able to continue; but some connections through bypass routes may continue to work. 6.7. Handling Router Solicitation from the 6bed4 Link This subsection is an illustration of a possible implementation; it is non-normative. The assumption in the conceptual model is that the 6bed4 Link has been setup with a 6bed4 Link-Local Address before it is brought online; this information is obtained with Router Discovery initiated by the 6bed4 Peer. As a result, the 6bed4 Link's attempts to Router Discovery are a bit late, but should nonetheless be handled. When a Router Solicitation enters over the 6bed4 Link, it could be responded to with a Router Advertisement holding a Prefix Option with the /64 prefix obtained from the 6bed4 Router. The Default Router Preference Field [RFC4191] may be set to Low, so as to prefer default routing over native links, except for traffic targeted at the /64 prefix offered in this Router Advertisement. 6.8. Handling Router Advertisement from the 6bed4 Link This subsection is an illustration of a possible implementation; it is non-normative. Any Router Advertisement arriving over the 6bed4 Link must be dropped. 6.9. Handling Neighbor Solicitation from the 6bed4 Network When a Neighbor Solicitation destined for one of its IPv6 addresses enters a 6bed4 Peer over the 6bed4 Network, then a reply MUST be for- mulated in the form of a Neighbor Advertisement. In terms of the non-normative conceptual model, the message could be replicated to Van Rein Expires September 12, 2012 [Page 18] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 the IPv6 stack through the 6bed4 Link. 6.10. Handling Neighbor Advertisement from the 6bed4 Network When a Neighbor Advertisement arrives over the 6bed4 Network, then the message will be normally processed; in terms of the non-normative conceptual model, the message would be replicated to the IPv6 stack over the 6bed4 Link. Any work scheduled to find the target in the received Neighbor Adver- tisement MUST be descheduled as a result of processing the Neighbor Advertisement. 6.11. Handling Neighbor Solicitation from the 6bed4 Link This subsection is an illustration of a possible implementation; it is non-normative. Neighbor Solicitation can be used by the IPv6 stack to avoid colli- sions. This is not required on the 6bed4 Network, where addresses are already unique if they are assigned through 6bed4 Link-Local Addresses. Therefore, an attempt to verify the prior existence of an IPv6 address based on this is not required. In terms of the non-nor- mative conceptual model, this means that a Neighbor Solicitation arriving over the 6bed4 Link and inquiring after the 6bed4 Network's /64 prefix plus the Interface Identifier of the 6bed4 Peer should be dropped. In general however, Neighbor Solicitation serves attempts to contact a remote 6bed4 Peer with an unknown 6bed4 Link-Local Address. In terms of the non-normative conceptual model, that could be recognized if the IPv6 stack sent a Neighbor Solicitation through the 6bed4 Link. If the request is for an address that starts with fe80::/10 or fe80::/64, then a Neighbor Advertisement must be provided by retriev- ing the 6bed4 Link-Local Address from the Interface Identifier. The only exception would be for address fe80::/128, which should be interpreted as a reference to the 6bed4 Router; if it is requested, then the 6bed4 Link-Layer Address of the 6bed4 Router must be pro- vided in a Neighbor Advertisement sent back over the 6bed4 Link. What remains is to process Neighbor Solicitation for remote 6bed4 Peers on the 6bed4 Network. The process run to obtain the 6bed4 Link-Local Address for these IPv6 addresses is to attempt all candi- date bypasses in turn, by sending a Neighbor Solicitation to the can- didate 6bed4 Address of the bypass. There may be a few attempts for each candidate bypass to compensate for network losses. When a Van Rein Expires September 12, 2012 [Page 19] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 Neighbor Advertisement is received in reply to one of these Neighbor Solicitations, then the 6bed4 Link-Local Address is accepted as the way to contact the requested target address, which is then relayed back in the form of a Neighbor Advertisement to the IPv6 stack over the 6bed4 Link. Multiple bypass routes may be candidates for a single IPv6 target. The search starts with the nearest-by targets, and ends with the far- thest away. The first bypass route is only useful if the local and remote 6bed4 Peers exhibit the same IPv4 address, and if the 6bed4 Peer subscribes to (and also sends to) the multicast address 224.0.0.1 and UDP port TBD1 for all 6bed4 nodes on the local network. If these conditions apply, then the first candidate bypass to consider is found by send- ing a Neighbor Solicitation for the target IPv6 address to this mul- ticast address and port. The second bypass route can be used anywhere, even if the local and remote 6bed4 Peer exhibit the same IPv4 address. It is tried by sending a Neighbor Solicitation to the IPv4 address and UDP port as found in the 6bed4 Link-Local Address of the remote 6bed4 Peer. This may work through a Pinhole or a direct connection, but in general it would attempt contact through the outside of any Network Address Translation device used by the remote 6bed4 Peer. Whether this works depends on the types of NAT and Firewall in the path between the 6bed4 Peers. If both use symmetric NAT, then it will never work; if only the remote side is symmetrical, then the initiative to find a direct route must be initiated by the remote 6bed4 Peer, and a future Redirect would be needed to restart the Neighbor Solicitation from the local 6bed4 peer. But in many other situations, the direct con- nection is likely to work. Neighbor Advertisements sent in reply are handled as described above; plus, they would cancel the search for bypass routes for the adver- tised target, since a bypass appears to have been found. Only if all bypass routes fail to respond within a reasonable time, would it be necessary for the 6bed4 Peer to fallback to the 6bed4 Router. In terms of the non-normative conceptual model, it would send a Neighbor Advertisement over the 6bed4 Link mentioning the 6bed4 Link-Local Address of the 6bed4 Router for the targeted remote 6bed4 Peer; in terms of that same model, the success in one of the foregoing steps would result in sending a Neighbor Advertisement with the succeeded 6bed4 Link-Layer Address for the targeted remote 6bed4 Peer. Depending on the original Neighbor Solicitation, the bypass routes Van Rein Expires September 12, 2012 [Page 20] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 attempted and reporting on it may be varied; for instance, for uni- cast versions it may suffice to attempt only the bypass routes up to and including the nearness of the requested form, and there is no need to report the 6bed4 Router's address. 6.12. Handling Neighbor Advertisement from the 6bed4 Link This subsection is an illustration of a possible implementation; it is non-normative. If the IPv6 stack relays a unicast Neighbor Advertisement message over the 6bed4 Link, then the packet must be replicated and sent over the 6bed4 Network. If it is a multicast version, then it may be dropped. 6.13. Handling Redirect from the 6bed4 Network It is necessary to send and receive 6bed4 traffic between two 6bed4 Peers over the same route; so either both send over the local net- work, or both send to direct 6bed4 Link-Local Addresses, or both send through the 6bed4 Router. This can be achieved by ensuring that the same Metric applies in both directions. If a route is established by one 6bed4 Peer, it knows that traffic can pass bidirectionally, so it can safely assume that the remote 6bed4 Peer can use it also. If it receives traffic from a remote 6bed4 Peer over a bypass with a higher cost metric, then it SHOULD send a Redirect message to the 6bed4 Peer, instructing it to continue sending over the more direct route. In this Redirect message, it MUST include as much of the causing message as it can fit in. The Destination Address included MUST be made from the fe80::/64 prefix plus the Interface Identifier of the 6bed4 Peer. The message MUST be sent to the 6bed4 Peer over the bypass for which it indicates a pref- erence. Upon receiving a Redirect, as much as possible MUST be verified; the causing packet if possible, the match between the 6bed4 Address over which the packet arrived and the Interface Identifier of the Destina- tion Address; whether the target is currently known to the local 6bed4 Peer; and whether the 6bed4 Link-Local Address in the Interface Identifier would actually have been considered as a candidate 6bed4 Link-Local Address for the target. If any of these tests fails, then the Redirect MUST be dropped. Otherwise, its processing SHOULD con- sist of sending a Neighbor Solicitation to the proposed 6bed4 Address. If this leads to a Neighbor Advertisement that would also have been acceptable to the normal process of Neighbor Discovery, then it MUST be accepted as a replacement of the current 6bed4 Link- Local Address for the target. In terms of the non-normative Van Rein Expires September 12, 2012 [Page 21] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 conceptual model, this may be implemented with a Neighbor Advertise- ment over the 6bed4 Link that has its Override flag set. 6.14. Handling Redirect from the 6bed4 Link The 6bed4 Link is part of the non-normative conceptual model. If this interface would generate a Redirect message, it must be ignored. 6.15. Dealing with Packet Fragmentation The IPv6 specifications define a minimal MTU that exceeds that of IPv4; as a result, it is always possible for packets on the 6bed4 Network to be subjected to fragmentation. The 6bed4 Peer SHOULD NOT set the Don't Fragment flag [RFC791] on IPv4 traffic and it SHOULD be prepared to reconstruct packets from fragments. The 6bed4 Peer MAY reject packets in excess of the 1280 byte MTU for IPv6 traffic; it MUST then respond with an ICMPv6 message of type 2, Packet Too Big. 7. Impact of Firewalls and Network Address Translation The 6bed4 mechanism has been carefully designed to work behind any sequence of Firewalls or Network Address Translators. The reason that it handles these well has two causes: First, it uses UDP, which is an opaque carrier that is generally supported by these devices. Second, the traffic is internally initiated, by sending a Router Solicitation to a 6bed4 Router. This is the direction in which both Firewalls and NAT open a hole that permits return traffic. Since UDP is stateless, all holes in Firewalls and NAT are subject to timeouts, and therefore regular traffic is needed to keep such holes open. To this end, a message may be sent to the 6bed4 Router at a regular interval, if no other traffic has been sent. In cases where this fails, an outgoing message will be corrected with a new Router Advertisement revealing the new 6bed4 Link-Local Address of the 6bed4 Peer. If this happens, any communication partners would conclude that the 6bed4 Peer had gone offline; regular traffic may be pre- ferred to avoid this. It may be beneficial to support 6bed4 on servers or routers, even if they are connected through native IPv6. This could help to have more direct connectivity to popular 6bed4 Networks. If server nodes are located behind a sequence of Firewalls and/or NAT, then Port Forward- ing may be setup explicitly to fixate an IPv6 address, by avoiding UDP port changes. When this is done, the IPv6 address could safely be entered in DNS as a server address. Van Rein Expires September 12, 2012 [Page 22] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 8. Security Considerations The 6bed4 protocol uses configuration packets that were designed for local network use, but it employs them on the public Internet. This is not a change to be made lightly. Furthermore, 6bed4 is a tunnel protocol, which itself implies certain responsibilities. All tunnel protocols should reject forged inner addresses; the 6bed4 Peer and 6bed4 Router tackle this by validating the address informa- tion upon entry; the IPv6 source address must match with the IPv4 address and UDP port from which the packet originated. The only exception is the Router Advertisement sent to the 6bed4 Router, but this is a mindful choice, and the packet is not permitted to travel beyond the 6bed4 Router. The link between an IPv4 address (which is hopefully subjected to egress filtering) and the tunnel's inner IPv6 address means that it is not easier to forge an IPv6 address than it is to forge an IPv4 address. Furthermore, the use of an IPv4 address as part of the IPv6 address means that network attackers are as traceable on a 6bed4 Net- work as they are on the IPv4 network. This specification does not introduce anything that could cause a 6bed4 Peer to contact a wrong 6bed4 Router; the mechanism for deter- mining the IPv4 address for that service falls outside the scope of this specification. Special attention is warranted for the Neighbor Advertisement and Router Advertisement messages, as these announce information that influences message redirection of a 6bed4 Peer. These concerns are addressed by the precaution to validate source addresses. In addi- tion, the information claimed is validated as per the behavioral specifications given above. Another specific concern relates to the ability to send Redirect packets. Once again, validation on source addresses addresses these concerns. In addition, the packet is only a hint and not an update instruction. When it is received, a Neighbor Solicitation process will only commence if the targeted 6bed4 Peer is already known to the 6bed4 Peer. This process is predictable, so a Neighbor Advertisement could be crafted ahead of time; however, these Neighbor Advertise- ments are also subject to matching of the source address. In summary, the risks caused by the tunneling technique and the use of Neighbor Discovery style packets on the 6bed4 Network are limited to situations where it is possible to send traffic from forged IPv4 address. In such situations, the problems are much more general and serious. Van Rein Expires September 12, 2012 [Page 23] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 9. IANA Considerations This specification allocates one resources from one existing reg- istry. 9.1. Registered UDP port: 6bed4 The registered port for the 6bed4 protocol is TBD1. This port is used to select 6bed4 traffic sent to a 6bed4 Router, as well as to the multicast address 224.0.0.1 for all nodes on the local subnet. [TO BE REMOVED: This UDP-only port number registration should take place at the following location: http://www.iana.org/assign- ments/port-numbers -- The port number MUST be an even number. I would like to request port number 25788 because it shows up in IPv6 addresses as a recognizable ...:be64:...] Van Rein Expires September 12, 2012 [Page 24] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 10. References 10.1. Normative References [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Con- trol Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Archi- tecture", RFC 4291, February 2006. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Defini- tion of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. Van Rein Expires September 12, 2012 [Page 25] INTERNET DRAFT 6bed4: Peer-to-Peer IPv6 March 11, 2012 10.2. Informative References [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Ser- vices", BCP 126, RFC 4786, December 2006. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. Author's Address Rick van Rein OpenFortress Digital signatures Haarlebrink 5 7544 WP Enschede The Netherlands email: rick@openfortress.nl Van Rein Expires September 12, 2012 [Page 26]