INTERNET-DRAFT Rick van Rein Intended Status: Proposed Standard OpenFortress Expires: January 26, 2012 July 25, 2011 IPv6 Tunneling for Embedded Systems (6bed4) draft-vanrein-v6ops-6bed4-00 Abstract Given the limited resources available to a lot of embedded systems, dual-stack solutions are not always feasible for such hosts. A mechanism that supports a direct transition from IPv4-only to IPv6-only may prove beneficial in getting the smallest hosts to make a transition to IPv6 at a much earlier stage than would otherwise be possible. This calls for tunnels, but no current tunnel technique appears to be optimal for embedded systems. This specification details an IPv6 tunneling technique over UDP and IPv4. The technique is specifically designed to benefit embedded systems, and to work without end user configuration. The working principle for obtaining a routable IPv6 address is through stateless autoconfiguration from an anycast tunnel service. 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Van Rein Expires January 26, 2012 [Page 1] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Well-known Addresses. . . . . . . . . . . . . . . . . . . . 3 2. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Rationale - Why Embedded Systems are Different . . . . . . 4 2.2. Solution - IPv6-only on Any Network . . . . . . . . . . . 4 2.3. Requirements - Specifically for Embedded Systems . . . . . 6 2.4. Design - Choices Made . . . . . . . . . . . . . . . . . . 7 3. Link-local profile . . . . . . . . . . . . . . . . . . . . . . 8 4. Tunneling Traffic . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Sending Traffic Up the Tunnel . . . . . . . . . . . . . . 9 4.2. Sending Traffic Down the Tunnel . . . . . . . . . . . . . 10 4.3. Bouncing Traffic on the Tunnel's IPv4 Side . . . . . . . . 11 5. Tunnel Service Profiles . . . . . . . . . . . . . . . . . . . 11 5.1. Public Tunnel Service Profile . . . . . . . . . . . . . . 11 5.2. Local Tunnel Service Profile . . . . . . . . . . . . . . . 12 5.3. En-route Translation Profile . . . . . . . . . . . . . . . 12 6. NAT-traversal Issues . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Van Rein Expires January 26, 2012 [Page 2] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 1. Introduction The 6bed4 mechanism is a tunnel that encapsulates IPv6 packets in UDP and IPv4. The mechanism assumes a remote tunnel service at a well- known IPv4 address and UDP port, effectively making the tunnel independent of DNS [RFC1034], and capable of traversing NAT [RFC2766]. The local IPv4 address is acquired through traditional techniques such as DHCPv4 [RFC2131] or manual IPv4 configuration, and the local UDP port can be chosen in any way that makes sense locally. The tunnel service can be implemented at many locations simultaneously, each announcing a route to their well-known IPv4 address over BGP [RFC4271], following the anycast [RFC4786] principle. The routing infrastructure will cause tunnel traffic to be relayed to a nearby instance of the 6bed4 service. In addition to classically routed service, the well-known tunnel service address enables en-route translation. Embedded systems obtain a routable IPv6 address over the tunnel through stateless autoconfiguration [RFC4862]. The router, always with interface identifier 0, can be reached over the tunnel on the fixed link-local IPv6 address fe80:: or on the all-routers address ff02::2 or on the all-nodes address ff02::1. The tunnel client, being the only other participant in the tunnel, can choose non-zero interface identifiers at will to complete autoconfiguration. The routable prefix offered by the 6bed4 tunnel service includes the IPv4 address and UDP port as seen from the Internet. Any NAT layer crossed by the tunnel may influence the client-side IPv4 address and UDP port, which is why the tunnel service must provide this data. Autoconfiguration serves to assign an IPv6 address to the tunnel client that incorporates the way it looks from the perspective of the Internet. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Well-known Addresses This specification allocates a number of well-known numbers for addressing. These numbers can be fixated into an embedded system, and serve to address an anycast-published tunnel as a fallback for local IPv6 facilities. Van Rein Expires January 26, 2012 [Page 3] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 IPv4 address for the remote tunnel service: TBD1 IPv6 prefix for the remote tunnel service: TBD2::/64 UDP port for the remote tunnel service: TBD3 The IPv4 address and UDP port are used to refer to the anycasted tunnel service. The IPv6 prefix is the default prefix for 6bed4 service, although local implementations MAY sometimes use another prefix. The IPv6 prefix is configured as a /64 on tunnel servers, composed of an IANA-registerd /48 and 16 zero bits. 2. Design Overview The most important desktop systems of today support IPv6 as well as IPv4, and have IPv6 enabled by default. This means that the Internet as a whole can now make the transition to IPv6, without the risk that users will be thrown out. Indeed, this is gradually happening. Embedded systems however, show a vastly different situation. The support for IPv6 is lagging behind, and numerous manufacturers are not even considering support. 2.1. Rationale - Why Embedded Systems are Different As long as a majority of Internet users still use IPv4, at least some parties may see no serious economic incentive to migrate to IPv6. Considering that IPv4 is not scheduled to be deprecated anytime soon, this situation may persist for many years to come. This limited incentive to transit to IPv6 applies equally to all host implementations, and will usually be weighed with other arguments. Specifically for embedded systems, a second force applies. The resources available to such systems are often limited; not only technical limitations such as available memory space, but also economic limitations such as lack of development time and the cost efficiency of support on more complicated implementations. The possible lack of an economic incentive to adopt IPv6, combined with limited resources, may lead to a situation where embedded systems are the last ones to support IPv6. This is probably aggravated by the fragmented market for embedded systems, compared to the desktop and router markets. 2.2. Solution - IPv6-only on Any Network The 6bed4 tunnel was created to answer to the specific situation on Van Rein Expires January 26, 2012 [Page 4] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 the market of embedded systems. To resolve any problems related to limited resources, the proposed transition is to go directly from IPv4-only to IPv6-only. The resulting setup can lead to simpler embedded code than in a dual-stack system; it can even save effort otherwise spent on NAT-traversal issues. Finally, any infrastructure built around IPv6-only devices is likely to be simpler than a dual- stack infrastructure; specifically peer-to-peer infrastructure may benefit greatly from the transparency of IPv6 addressing. We expect these motivations to lead to a faster adoption of IPv6 in embedded systems. If embedded systems are to operate in IPv6-only mode, they should be able to do that on any network, including IPv4-only networks. That calls for a tunneling technique. Several tunnels have been defined, but none would be very useful to convince programmers of embedded systems to transit from IPv4-only to IPv6-only. Because of this, 6bed4 is introduced as an alternate tunneling technique for this specific application area. The following code fragment shows a procedure for automatic network bootstrapping over IPv6 if it is locally available, with a tunnel fallback based on IPv4 if this is needed. Not shown are alternate options, such as manually configured local IPv4 addresses. The simplicity of this network bootstrapping code means that only minor resources are needed to make a networking application always run on (an illusion of) an IPv6-only network. // Redistribution and use in source and binary forms, with // or without modification, are permitted provided that the // following conditions are met: // // * Redistributions of source code must retain the above // copyright notice, this list of conditions and the // following disclaimer. // // * Redistributions in binary form must reproduce the // above copyright notice, this list of conditions and // the following disclaimer in the documentation and/or // other materials provided with the distribution. // // * Neither the name of Internet Society, IETF or // IETF Trust, nor the names of specific contributors, // may be used to endorse or promote products derived // from this software without specific prior written // permission. // // THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND // CONTRIBUTORS _AS_IS_ AND ANY EXPRESS OR IMPLIED Van Rein Expires January 26, 2012 [Page 5] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 // WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED // WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A // PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL // THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY // DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR // CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, // PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF // USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) // HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER // IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING // NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE // USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE // POSSIBILITY OF SUCH DAMAGE. err = try_autoconfig6 (&cfg); if ((err != 0) || managed_flag_dhcp6 (&cfg)) { err = try_dhcp6 (&cfg); if (err != 0) { err = try_dhcp4 (&cfg); if (err == 0) { use_tunnel (&cfg); err = try_autoconfig6 (&cfg); } if (err) { panic (); } } } 2.3. Requirements - Specifically for Embedded Systems Following is a list of criteria for tunneling techniques that are necessary to make IPv6 workable for embedded environments; no previously designed tunnel is able to fulfill them all yet: Standard. A tunneling approach requires interoperability between tunnel clients and servers; therefore, open standards must be followed. Simple. To support embedded systems with limited resources, the tunnel should be as simple as possible. Combined with the addressing transparency of IPv6, the transition to IPv6 can actually be eas- ier than using IPv4, and thus attractive for newly created or upgraded firmware. Any router. A tunnel technique that works for embedded systems should not make Van Rein Expires January 26, 2012 [Page 6] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 any assumptions about the routers on its path; in other words, it should pass through any type of router, including those who rely on symmetrical NAT. Zero configuration. Any requirement to manually configure a tunnel will seriously impair the possibilities of rolling out an embedded system to end users. As a result, such a tunnel would not be used in many prod- ucts. Only if IPv6 works straight out of the box, without manual configuration, is it likely to enter mainstream devices. In tech- nical terms, this means that the tunnel mechanism cannot rely on device or end user credentials. Traceable. Even without configurable credentials, a tunnel should not become a portal for network abuse. It should therefore be possible to isolate a misbehaving network node and take corrective measures. One way of making IPv4-registered users traceable in IPv6 is by revealing their IPv4 address as part of their IPv6 address. Stateless. If possible, a stateless mechanism for the tunnel service would be ideal. This would make it easy to handle downtime on an instance, because traffic can be diverted elsewhere. Also, there is no need to pass through the same server on bidirectional traffic; this perfectly matches the stateless routing properties of IP-level traffic. Anycast. If possible, it would be ideal to have well-known addresses for the tunnel service, so they can be anycasted over BGP4. This leads to a network service that is resilient and that can roughly spread the load over instances. A requirement for this to work would be that the tunnel service is stateless. 2.4. Design - Choices Made Following is the train of thought that explains how the 6bed4 tun- neling mechanism can implement all requirements from the previous subsection: Not anonymous. The tunnel user should not be anonymous so abusers can be traced. This is easily achieved by incorporating a public IPv4 address in any IPv6 addresses that is usable through the tunnel. No registration. Given that a tunnel user can always be traced back through their Van Rein Expires January 26, 2012 [Page 7] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 IPv4 address, it is possible to handle tunnel requests without registration of user accounts, or login. The tunnel service will not aggravate problems of address spoofing if it verifies that the IPv6 addresses sent out do indeed match the sender's IPv4 address. That way, egress filtering on IPv4 applies to the IPv6 addresses as well. Stateless. Given that there is no registration, a check on traffic from the IPv4 side to the IPv6 side is needed, and a reconstruction of IPv4 and UDP headers when traffic returns from IPv6 to IPv4. If the UDP information (notably, the client-side UDP port on what will often be a NAT router) is also present in the IPv6 addresses used, then the tunnel service has no need for storing any state about the tunnel. It is a stateless, packet-at-a-time translation ser- vice. Anycast. Stateless services that only perform simple translations of head- ers can easily be made into anycast services. Indeed, allocating a /64 on the IPv6 side and a /24 on the IPv4 side suffices. Broadcasting these routes from multiple BGP speakers and hosting them in multiple autonomous systems should not be any problem. 3. Link-local Profile The 6bed4 tunnels add detail with respect to the autoconfiguration mechanism described in RFC 4862. Most importantly, the parameter N for the number of bits in the interface identifier is 16. The preceding 112 bits are filled with a /64 prefix for the IPv6-side of the tunnel service, 32 bits worth of IPv4 address and 16 bits of UDP port number: 0 63 95 111 127 +-------------------------------+---------------+-------+-------+ | IPv6-side /64 PREFIX | Public v4addr |UDPport| if-id | +-------------------------------+---------------+-------+-------+ Or, as seen from the tunnel client perspective: 0 111 127 +-------------------------------------------------------+-------+ | IPv6-side /112 PREFIX | if-id | +-------------------------------------------------------+-------+ The interface identifier (if-id) for the router is always 0 and only 0, which means that it can always be reached at its link-local Van Rein Expires January 26, 2012 [Page 8] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 address fe80::/128. The tunnel client can choose its own interface identifier(s) at will from the range 1 to 65535 inclusive. The tun- nel client MAY fixate interface identifiers in its firmware. The point-to-point nature makes it possible for tunnel clients and servers to ignore the interface identifier altogether without mal- functioning. Upon sending however, a node MUST use a valid interface identifier to accommodate peers that do check it. The value of DupAddrDetectTransmits defaults to 0 for this kind of link, meaning that no neighbor discovery is required for 6bed4 links. This is possible because of the static allocation of interface iden- tifiers to endpoint. Note that RFC 4862 requires the tunnel client and server provide a facility for overriding this setting. For this reason, the tunnel endpoints MUST support neighboring requests. 4. Tunneling Traffic The following describes how to pass traffic down from the IPv6-side of the tunnel to the IPv4-tunneled side; how to pass it up in the opposite direction; and, as an optimisation, how a tunnel may directly connect two tunnels by bouncing traffic to the other side. 4.1. Sending Traffic Up the Tunnel The embedded system can send IPv6 packets through a tunnel as soon as it has an assigned IPv6 address. To do this, it will prefix a UDP header with the well-known UDP port as a destination and the UDP port used locally for the tunnel as a source. It will then prefix an IPv4 header, containing the well-known IPv4 address of the tunnel as des- tination, and the classically obtained local IPv4 address as the sender. This is shipped over the IPv4 network, may pass NAT routers, and will arrive on the tunnel server with possibly altered sender information in the IPv4 and UDP headers. When traffic is sent to the all-routers multicast address ff02::2, the all-nodes multicast address ff02::1 or to the router's link-local address fe80::/128 it is subject to local handling according to RFC 4861 and RFC 4862. If however, the time-to-live is not 255, the packet MUST be dropped or rejected with Time Exceeded error sent with ICMPv6. Specifically, router solicitation will result in sending a router advertisement, and neighbor solicitation is handled as usual. Before passing traffic through the tunnel, the time-to-live in the IPv6 packet MUST be decremented. If this is not possible because it Van Rein Expires January 26, 2012 [Page 9] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 is already 0, then the packet MUST be rejected and a Time Exceeded error sent over ICMPv6 in response. The tunnel server then verifies the correctness of the sending IPv6 address: The first 64 bits should match the fixed prefix assigned to the tunnel server; the following 32 bits should match the IPv4 address according to the incoming message; the following 16 bits should match the UDP port from which the incoming message came; the final 16 bits with the interface identifier may not be zero, as that is always the tunnel server's address. If the match is good, the IPv6 payload will be taken out of its IPv4/UDP wrapper, and forwarded as normal traffic over the IPv6 net- work. In doing so, the DiffServ field SHOULD be preserved. A few exceptional forms of delivery are handled in later sections of this specification. If the match is false, the tunnel server will send back an unso- licited router advertisement to the origin from which the failing tunnel traffic came, assuming that a 6bed4 endpoint is listening behind that address/port combination. This advertisement will revoke the prefix that the tunnel client tried to use by setting its pre- ferred and valid lifetimes to 0. In the same message, it will adver- tise the new prefix that holds the external IPv4 address and UDP port of the client, and assign it an infinite preferred and valid lifetime value 0xffffffff. Upon reception of a router advertisement, the tunnel client MUST immediately update its IPv6 addresses and it MUST NOT send out any further messages using an outdated IPv6 prefix. It MAY resend any unacknowledged messages that are being processed. 4.2. Sending Traffic Down the Tunnel Traffic that is to be sent down through the tunnel, is routed to a tunnel server by routing to its IPv6 /64 prefix. If this is the well-known prefix, then many BGP speakers may be announcing it; the routing infrastructure would then find a suitable tunnel server nearby the IPv6 sender. If an entering IPv6 packet has a destination address with a different /64 prefix than the prefix setup for the tunnel, then that packet MUST be dropped or rejected with an ICMPv6 message. If an IPv6 packet is passed down through the tunnel, its time-to-live MUST be decremented. If this is not possible because the time-to- live is already 0, then the packet MUST be rejected with a Time Exceeded ICMPv6 error message. Van Rein Expires January 26, 2012 [Page 10] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 The IPv6 address to which the message is sent contains an IPv4 address right after its /64 prefix, followed by 16 bits of client UDP port. The destination side of a UDP header and IPv4 header can be reconstructed from that, and the source side can be filled with the well-known values that have been defined for 6bed4. The DiffServ field of the incoming IPv6 header SHOULD be replicated in the newly constructed IPv4 header. At some point before shipping this message, the last 16 bits of the address, holding the interface identifier, MUST be checked to be non-zero. If the value is zero, the incoming traffic MUST be silently dropped. 4.3. Bouncing Traffic on the Tunnel's IPv4 Side If a tunnel receives a tunneled package destined for an IPv6 address that begins with the well-known IPv6 /64 prefix for 6bed4 or perhaps a locally used alternative prefix for 6bed4, then it MAY optimize the flow of traffic by forwarding it as tunneled traffic to the IPv4 address and UDP port found in the remainder of the IPv6 destination address. In doing so, it MUST NOT bypass the comparison of the IPv6 prefix, IPv4 address and UDP port as mentioned in the source IPv6 address. If this comparison fails, the traffic MUST be treated as traffic try- ing to pass up through the tunnel with an incorrectly set IPv6 address. 5. Tunnel Service Profiles Three different service profiles are expected to be useful for this tunnel mechanism. The first is public, available to users anywhere in the World. The second profile is local, intended to serve only a part of the Internet, such as the network of a particular provider. The third profile focusses on translation in routers through which the 6bed4-encapsulated traffic happens to flow. 5.1. Public Tunnel Service Profile This profile describes the situation of a service made publicly available in the spirit of supporting the transition of embedded sys- tems as proposed in this specification. Such services are announced over BGP, which SHOULD be done for both the IPv4-side and IPv6-side addresses. Given the stateless nature of Internet routing, the upstream and downstream routes may well go through different services, and there can even be situation where traffic is evenly spread over more than one target. For this reason, the addresses announced MUST be the well-known address TBD1/24 for Van Rein Expires January 26, 2012 [Page 11] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 the IPv4 side and TBD2::/48 for the IPv6 side. Public Tunnel Service providers MUST register their tunnel service with their Regional Internet Registry, to support finding the Autonomous System that supports the 6bed4 service. 5.2. Local Tunnel Service Profile This profile describes the situation of a local administrator at any scale from a home or company network to an ISP, offering 6bed4 ser- vice to hosts internal to the network. Such services are announced over interior gateway routing protocols. On the IPv4 side, the well-known address TBD1/24 SHOULD be announced, to provide service any embedded device that was equipped to deal with standard 6bed4 facilities. On the IPv6 side a non-standard address range MUST be used, namely one that routes to the locally available 6bed4 service. The reason that a local 6bed4 service MAY use a non-standard IPv4 address is that it may be desirable to support other applications than embedded systems, for instance desktops or routers, which MUST NOT put pressure on the public 6bed4 infrastructure. Using another IPv4 address however, releases the pressure that such applications would bring if the locally supported systems switch to external Internet access mechansims. Next to such alternative local use of 6bed4 it is still possible to run a normal 6bed4 service on TBD1/24, using any of the profiles sketched here. Local tunnel service providers SHOULD register their IPv6 /64 range with their Regional Internet Registry, and MAY refer to this specifi- cation in abuse-handling comments. 5.3. En-route Translation Profile This profile describes routers that translate 6bed4 traffic while it happens to pass through them. This can be done by any router that has both IPv4 and IPv6 connectivity, and that decides to terminate either TBD1/24 or the IPv6-side address range. En-route translation need not be announced publicly, but it may help to direct traffic to such routers if there would otherwise be alter- nate paths around it. For example, if all gateways of an Internet Service Provider implement 6bed4 in an en-route profile, then it may not be necessary to announce this service on the local network or on the Internet at large. A few variations exist regarding the prefix used on the IPv6 side of Van Rein Expires January 26, 2012 [Page 12] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 en-route translation. If all upstream traffic (for a targeted net- work) is guaranteed to pass through a router that performs en-route 6bed4 translation, then the IPv6 side SHOULD use an IPv6 address that routes to the local network, but it MAY use TBD2::/64 if downstream 6bed4 service is not locally available. On the other hand, if not all upstream traffic (for the target network) passes through an en- route translating router, then its IPv6 side MUST use the well-known prefix TBD2::/64 so that alternate routes and the en-route transla- tion cannot be distinguished from the end user's perspective. The major advantage of en-route translation is that it can avoid diversion of traffic through a third-party 6bed4 tunnel server. Instead of routing the traffic in two legs, going through an interme- diary, it can be kept on the fastest route available, which is good for the routing budget of the Internet as a whole. It may even cause the IPv6 traffic to remain on the local network of the Internet Ser- vice Provider. En-route translation providers SHOULD register their IPv6 /64 range with their Regional Internet Registry, and MAY refer to this specifi- cation in abuse-handling comments. 6. NAT-traversal Issues Very often, a 6bed4 tunnel will have to pass through a layer of net- work address translation, or NAT. Even if 6bed4 recovers the trans- parency of network connections at the IPv6 level, there may still be simpler problems to resolve at an underlying IPv4 level. NAT will rewrite IPv4 and UDP-over-IPv4 source addresses. Handling these translations has been designed into 6bed4. A remaining concern with NAT is that UDP has no connection status, and its translation must therefore be flushed at some point. Although the 6bed4 tunnel will quickly recover when that happens, the higher protocols may not be as accommodating; notably, TCP connec- tions over IPv6 would break if the translation changed suddenly. For this reason, it may be necessary to send messages for the purpose of keeping the address translation active in any on-route NAT routers. This can either be achieved by an actively communicating protocol, or by explicit keep-alive messages. Any such messages SHOULD NOT be sent if there is no application need for keeping the same IPv6 address on which the tunnel client can be reached. Keep-alive messages MUST NOT be sent more often than once in 25 seconds. Furthermore, randomization of the keep-alive message interval is important so as to offload the tunnel server from Van Rein Expires January 26, 2012 [Page 13] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 synchronization of keep-alive messages after things like power out- ages. Instead of sending keep-alive messages, a device MAY use other means to achieve the longevity of an open link. If it can communicate its wish for an open UDP port directed to its local endpoint directly, this is a much simpler method. The only disadvantage of this approach is usually that it cannot be relied upon as a general mecha- nism; but if it does, it will save energy and bandwidth, so it is certainly recommended. Van Rein Expires January 26, 2012 [Page 14] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 7. Security Considerations Any party that can convince a network of being the router for a given range of addresses will be able to attract the traffic for 6bed4 tun- nels. This could open up such protocols for man-in-the-middle attacks. The foreseeable means of doing this are either through BGP advertise- ments on the Internet, or through router advertisements on a local network. The issue of BGP advertisements is a general problem and is not commonly thought of as being hazardous; notwithstanding that, work is being done to solve the general problem at that general level. When done at the local level using an interior gateway routing proto- col, the attack is not much different from DHCP hijacking, a risk that is usually dealt with locally by monitoring client nodes to not exhibit server behavior, or by strict control over network access. Although symmetric signatures are possible over neighbor discovery protocols, this is not usable for the 6bed4 system, because it is a global protocol and includes too many parties to be able to protect the shared secret keys. Any signature mechanism for 6bed4 would have to be asymmetrical. 8. IANA Considerations This document allocates three resources from existing registries. First, the well-known IPv4 address TBD1 under its own /24 prefix, to be registered in the IPv4 Special Purpose Address Registry. Although only a single address is required, the choice of a /24 inte- grates better with BGP routing practices. [TO BE REMOVED: 192.64.64.1/24 or 192.6.4.1/24 would be nice!] [TO BE REMOVED: This registration should take place at the following location: http://www.iana.org/assignments/iana-ipv4-special-registry/iana- ipv4-special-registry.xml] Second, the well-known IPv6 prefix TBD2::/48, to be registered in the IANA IPv6 Special Purpose Address Registry. Although only a /64 pre- fix is needed, the choice of a /48 integrates better with BGP routing practices. The additional bits to come to a /64 prefix are filled with zeroes. [TO BE REMOVED: The address can be taken from 2001:0000::/23] [TO BE REMOVED: 2001:6:bed4::/48 would be nice!] [TO BE REMOVED: This registration should take place at the following location: http://www.iana.org/assignments/iana-ipv6-special-reg- istry/iana-ipv6-special-registry.xml] Van Rein Expires January 26, 2012 [Page 15] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 Thirdly, the well-known UDP port TBD3, to be registered in the Port Numbers Registry. [TO BE REMOVED: Suggest to share 3653 for compara- ble & interoperable TSP from RFC 5572; draft author contacted Marc Blanchet with this sharing proposal] [TO BE REMOVED: This registra- tion should take place at the following location: http://www.iana.org/assignments/port-numbers] 9. References 9.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. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Bor- der Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Ser- vices", BCP 126, RFC 4786, December 2006. [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. 9.2. Informative References [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Transla- tion - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", Van Rein Expires January 26, 2012 [Page 16] INTERNET DRAFT IPv6 for Embedded Systems (6bed4) July 25, 2011 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 January 26, 2012 [Page 17]