INTERNET DRAFT C. Huitema Microsoft Expires January 12, 2001 July 12, 2001 Shipworm: Tunneling IPv6 over UDP through NATs Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract We propose here a service that would enable nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Shipworm service. The establishment of the tunnel is automatic, and does not require any configuration parameters on the client. Running the service requires the help of "Shipworm servers" and "Shipworm relays"; the Shipworm servers are stateless, and only have to manage a small fraction of the traffic between Shipworm clients; the Shipworm relays act as IPv6 routers between the Shipworm service and the "native" IPv6 Internet. 1 Introduction Classic tunneling methods envisaged for IPv6 transition operate by sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal proposes automatic discovery in this context. A problem with these methods is that they don't work when the IPv6 candidate node is isolated behind a Network Address Translation device: NAT are typically not programmed to allow the transmission of arbitrary payload types; even when they are, the local address cannot be used in a 6to4 scheme. 6to4 will work with NAT if the NAT and 6to4 router functions are in the same box; we want to cover the relatively frequent case when the NAT cannot be readily upgraded to provide a 6to4 router function. Huitema [Page 1] INTERNET DRAFT Shipworm July 12, 2001 A possible way to solve the problem is to rely on a set of "tunnel brokers." There are however limits to any solution that is based on such brokers: the quality of service is not very good, since the traffic follows a "dog leg" route from the source to the broker and then the destination; the broker has to provide sufficient transmission capacity to relay all packets and thus suffers a high cost. For these two reasons, we tend to prefer solutions that allow for "automatic tunneling", i.e. let the packets follow a direct path to the destination. The automatic tunneling requirement is indeed at odds with some of the specificities of NATs. Establishing a direct path supposes that the IPv6 Candidate can retrieve a "globally routable" address that results from the translation of its local address by one or several NATs; it also supposes that we can find a way to bypass the various "per destination protections" that many NATs implement. In this memo, we will explain how IPv6 candidates located behind NATs can enlist the help of "v6 UDP routers" to learn their "global address" and to obtain connectivity. 2 Definitions 2.1 Shipworm service The transmission of IPv6 packets over UDP, as defined in this memo. 2.2 Shipworm Client A node that has some access to the IPv4 Internet and that wants to gain access to the IPv6 Internet. This node may behave either as an IPv6 host or as an IPv6 router. 2.3 Shipworm Server A node that has access to the IPv4 Internet through a globally routable address, and that is used as a helper to provide IPv6 connectivity to Shipworm Client. The node is also reachable through the Shipworm IPv4 anycast address. 2.4 Shipworm relay router An IPv6 router that can receive traffic destined to Shipworm clients and forward it using the Shipworm service. 2.5 Shipworm IPv6 service prefix A 16 bit IPv6 addressing prefix, whose value is XXXX::/16. (TBD IANA) Huitema [Page 2] INTERNET DRAFT Shipworm July 12, 2001 2.6 Shipworm IPv4 anycast prefix An IPv4 address prefix, whose value is x.x.x.0/24. (TBD IANA) This prefix is announced in the IPv4 routing tables. 2.7 Shipworm IPv4 anycast address An IPv4 address whose value is x.x.x.y, where "x.x.x" is the 24 bit Shipworm IPv4 anycast prefix. (TBD IANA) IPv4 Packets sent to this address are directed to the nearest Shipworm server. 2.8 Shipworm UDP port An UDP port number at which Shipworm Servers are waiting for packets. The value of this port is PPPP. (TBD IANA) 2.9 Shipworm bubble A packet sent over UDP by a Shipworm agent in order to trigger a side effect in the NAT. 2.10 Shipworm Discard port An UDP port number that is used as the destination of Shipworm bubbles. The normal value for that port number is 9, i.e. the port number reserved by IANA for the discard service. 2.11 Shipworm service port The port over which the Shipworm client sends Shipworm packets. This port is attached to one of the client's IPv4 interfaces. The IPv4 address may or may not be globally routable, as the client may be located behind one or several NAT. 2.12 Shipworm mapped address and Shipworm mapped port A global IPv4 address and a UDP port that results from the translation by one or several NAT of the IPv4 address and UDP port of a client's Shipworm service port. The client learns these values through the Shipworm protocol described in this memo. 2.13 Shipworm IPv6 client prefix A global scope 64 bit IPv6 prefix composed from the Shipworm IPv6 service prefix, the Shipworm mapped address and Shipworm mapped port. 2.14 Shipworm IPv6 address A Shipworm IPv6 address obtained by combining a Shipworm IPv6 client Huitema [Page 3] INTERNET DRAFT Shipworm July 12, 2001 prefix and a 64 bit node identifier. 2.15 Shipworm IPv6 anycast address A global scope IPv6 address obtained by combining the Shipworm IPv6 service prefix, the Shipworm IPv4 anycast address, the Shipworm port and a null 64 bit node identifier (i.e., all zeroes). 3 Model, requirements The Shipworm service requires the cooperation of three kinds of actors: Shipworm clients, who want to use IPv6 despite being located behind a NAT, Shipworm servers who will facilitate the service, and Shipworm relays that provide for the interconnection between the service and the "native IPv6 Internet." In order to enable the service, the Shipworm servers must have an unencumbered IPv4 connection, i.e. they must have a global IPv4 address. In fact, these servers must be dual homed, capable of receiving packet on a specific, topology dependent, IPv4 address, and also of receiving packets on the generic "Shipworm anycast IPv4 address." The Shipworm routers must be connected to the IPv6 Internet and must participate in IPv6 routing; they must be able to announce reachability over IPv6 of the "Shipworm service IPv6 prefix." They must then be able to relay packets over IPv4 UDP towards Shipworm clients. It is very sensible to combine the functions of Shipworm server and Shipworm relay in a single box. The Shipworm service is designed primarily for robustness: packets are carried over UDP in order to cross as many NAT implementations as possible. The servers are designed to be stateless, which means that they can easily be replicated. We expect indeed to find many such servers replicated at multiple Internet locations. The primary role of the servers is to enable the NAT traversal. The service is designed in such a way that, as soon as NAT traversal is guaranteed, packets can flow on a direct path between source and destination, without necessarily involving a relay by a Shipworm server. 4 Description of the solution The Shipworm service is realized by having clients interact with "Shipworm servers" through the Shipworm service protocol. The Shipworm server is designed to be stateless. It waits for Shipworm requests or test requests on the Shipworm service and Shipworm test ports, and processes by sending a response to the adequate address and port; it waits for IPv6 packets on the Shipworm Huitema [Page 4] INTERNET DRAFT Shipworm July 12, 2001 relay port, and forwards them to the adequate IPv4 address and UDP port. 4.1 Message formats 4.1.1 Shipworm IPv6 addresses Shipworm IPv6 addresses comprise four components: +------+------------+----+-----------------------------+ |Prefix|IPv4 address|Port| Node identifier | +------+------------+----+-----------------------------+ The 16 bit prefix is the "Shipworm IPv6 Prefix." The next 32 bits contain a globally routable IPv4 address. The next 16 bits contain a port number associated with that address. The last 64 bits contain a node identifier. 4.1.2 Shipworm IPv6 packets encapsulation Shipworm IPv6 packets are transmitted as UDP packets [13] within IPv4 [14]. The source and destination IP addresses and UDP port take values that are specified in this section. 4.1.3 Maximum Transmission Unit Since Shipworm uses UDP as an underlying transport, a Shipworm Maximum Transfer Unit (MTU) could potentially be as large as the payload of the largest valid UDP datagram (65527 bytes). However, since Shipworm packets can travel unto unpredictable path over the Internet, it is best to contain this MTU to a small size, in order to minimize the effect of packet fragmentation and reassembly. The default link MTU assumed by a host, and the link MTU supplied by a Shipworm server during Router Advertisement SHOULD normally be set to the minimum IPv6 MTU size of 1280 bytes [5]. Shipworm implementations SHOULD NOT set the "do not fragment" (DF) bit of the encapsulating IPv4 header. 4.1.4 Shipworm bubble A Shipworm bubble is a minimal UDP packet sent to a specific destination to "prime" a NAT for later accepting packets from this destination. The bubble has the following parameter: - IPv4 source address: the Shipworm mapped address of the sender - IPv4 destination address: the IPv4 address of the target Huitema [Page 5] INTERNET DRAFT Shipworm July 12, 2001 - UDP source port: the Shipworm mapped port of the sender - UDP destination port: the Shipworm Discard Port. - UDP payload: the string "Shipworm." 4.2 Shipworm Client specification A Shipworm client expects to exchange IPv6 packets through an UDP port, the Shipworm service port. The client will maintain the following variables that reflect the state of the Shipworm service: - Shipworm connectivity status, - Mapped address and port number of the Shipworm service port, - Shipworm IPv6 prefix associated with the Shipworm service port, - Shipworm IPv6 address or addresses derived from the prefix, - Date and time of the last interaction with the Shipworm server, - List of recent Shipworm peers. Before sending any packets, the client must perform the Shipworm qualification procedure, which determines the Shipworm connectivity status, the mapped address and port number, and the Shipworm IPv6 prefix. If the qualification is successful, the client may use the Shipworm service port to transmit and receive IPv6 packets, according to the transmission and reception procedures; these procedures use the "list of recent peers". The client must regularly perform the maintenance procedure in order to guarantee that the Shipworm service port remains usable; the need to use this procedure or not depend on the delay since the last interaction with the Shipworm server. 4.2.1 Qualification procedure The purpose of the qualification procedure is to establish the status of the local IPv4 connection, and to determine the Shipworm IPv6 client prefix of the local Shipworm interface. The procedure starts when the service is in the "initial" state, and results in a "qualified" state if successful, in an "off-line" or "bad-NAT" stage if unsuccessful. Huitema [Page 6] INTERNET DRAFT Shipworm July 12, 2001 /---------\ | Initial | \---------/ | +----+----+ | Start |<------+ +----+----+ | | | v | /---------\ Timer | |Starting |-------+ N attempts /----------\ \---------/--------------------->| Off-line | | Response \----------/ | +----+----+ | Test |<------+ +----+----+ | | OK | v | /---------\ Timer | | Testing |-------+ N attempts /----------\ \---------/--------------------->| Bad-NAT | | Response \----------/ V /---------\ |Qualified| \---------/ Initially, the Shipworm connectivity status is set to "Initial". When the interface is initialized, the system first performs the "start action" by sending a Router Solicit packet. The IPv6 destination of the RS is the Shipworm IPv6 anycast address; the IPv6 source is the unspecified address; the packet will be sent over UDP to the Shipworm anycast address and Shipworm service port. The connectivity status moves then to "Starting". In the starting state, the client waits for a router advertisement from the Shipworm server. If no response comes within a time-out, the client should repeat the start action, by resending the Router Solicit packet. If no response has arrived after N=4 repetitions, the client concludes that it cannot use UDP, and that the Shipworm service is not available; the status is set to "Off-line." If a response arrives, the client checks that the router advertisement contains exactly one advertised address prefix. This prefix should be a valid Shipworm IPv6 client prefix: - the first 16 bits contain the Shipworm service TLA, - the next 32 bits are the client's Shipworm mapped address, Huitema [Page 7] INTERNET DRAFT Shipworm July 12, 2001 - the next 16 bits are the client's Shipworm mapped port. The source address of the Router Advertisement is the Shipworm IPv6 address of the Shipworm server. This address must be built using an IPv4 unicast address of the server, and a port number at which the server is waiting for packets. If the response is a valid router advertisement, from a valid Shipworm source address, and containing a valid Shipworm address prefix, the client should build a Shipworm IPv6 address using the Shipworm IPv6 client prefix learned from the RA and locally selected identifier. The client will then initiate the test of the connection. It does so by sending first a Shipworm bubble whose target is the IPv4 unicast address of the server, as learned from the IPv6 source address of the RA, and then by sending IPv6 ICMP echo request whose IPv6 source address is the client's Shipworm IPv6 address, and whose IPv6 destination is the server's Shipworm IPv6 address, i.e. the source address of the RA; the echo request is sent over IPv4 UDP to the Shipworm IPv4 anycast address and Shipworm UDP port. The client is now in the "testing" state, and waits for the ICMP echo response from the Shipworm server. If no response comes within a time-out, the client should repeat the test action, by resending the Shipworm bubble and the Shipworm ICMP echo request. If no response has arrived after N=4 repetitions, the client concludes that the NAT cannot be reliably traversed, and that the Shipworm service is not available; the status is set to "Bad-NAT." If the echo response arrives, the address is qualified, and the client can start using the Shipworm service. 4.2.2 Packet reception The Shipworm client receives packet over the Shipworm interface. The role of the packet reception procedure, besides receiving packets, is to maintain the date and time of the last interaction with the Shipworm server, and the "list of recent peers." Each entry in the list contains an IPv4 address, a UDP port, and a date and time. When a UDP packet is received, the Shipworm client examines the IPv4 source address and port number from which the packet is received. If these values match the Shipworm IPv4 anycast address and Shipworm port, the client updates the "date and time of the last interaction with the Shipworm server" to the current data and time. The Shipworm client will then examine the IPv6 source address of the encapsulated packet. If the source IPv6 address is a Shipworm IPv6 address, the client extracts the "peer IPv4 address" and "peer UDP port" corresponding to that address. If the address and port pair are already represented in the "list of recent peers", the client updates the data and time associated to that list entry. If the pair Huitema [Page 8] INTERNET DRAFT Shipworm July 12, 2001 is not yet represented, the client creates a new list entry for the pair, associated with the current data and time. The list of peers is used to "optimize" the transmission of IPv6 packets by using a "direct path" for the recently active peers. The list of peers could grow over time. Clients should implement a list management strategy, such as for example deleting the least recently used entries. Clients should make sure that the list has a sufficient size, so that most traffic goes over the "direct path." 4.2.3 Packet transmission When a Shipworm client has to transmit a packet over a Shipworm interface, it examines the destination IPv6 address. If the destination is not a Shipworm IPv6 address, the packet is posted over UDP to the Shipworm IPv4 anycast address and Shipworm UDP port. If the destination is a Shipworm IPv6 address, the client extracts the "peer IPv4 address" and "peer UDP port" corresponding to that address. If there is an entry for this address and port pair in the List of recent Shipworm peers for this address and port pair, the packet should be sent over UDP directly to the specified "peer IPv4 address" and "peer UDP port". If there is no entry in the list, the client should first send a Shipworm bubble to the "peer IPv4 address". It should then send the IPv6 packet over IPv4 UDP to the Shipworm IPv4 anycast address and Shipworm UDP port. 4.2.4 Maintenance The Shipworm client must ensure that the mappings that it uses remain valid. It does so by checking that packets are regularly received from the Shipworm server. At regular intervals, the client must check the "date and time of the last interaction with the Shipworm server", to ensure that at least one packet has been received in the last 30 seconds. If this is not the case, the client shall send a router solicitation to the Shipworm IPv6 Anycast address. When the router advertisement is received, the client checks that the advertised prefix corresponds to the current Shipworm service prefix. If this is not the case, the mapping has changed; the client must check that the new prefix is valid, as specified in the qualification procedure. It should then invalidate the addresses derived from the old prefixes. 4.3 Shipworm Server specification The Shipworm server is designed to be stateless. The Shipworm server waits for incoming UDP packets at the Shipworm Relay Port. The Huitema [Page 9] INTERNET DRAFT Shipworm July 12, 2001 incoming packets may be sent to either the Shipworm IPv4 Anycast Address, or to the specific unicast address of the Shipworm Server. The Shipworm server acts as an IPv6 router. As such, it will receive Router Solicitation packets, to which it will respond with router advertisement packets as explained in the "router solicitation" procedure; it may also receive other packets, for example ICMP packets; ICMP echo request packets must be processed according to the "echo request" procedure. 4.3.1 Processing of Shipworm IPv6 packets Upon reception of a packet on the Shipworm port, the Shipworm server will first check that the UDP payload contains a valid IPv6 packet; if this is not the case, the packet will be silently discarded. The Shipworm server will then check the IPv6 destination address of the encapsulated IPv6 packet. If the IPv6 destination address is either the Shipworm IPv6 anycast address or the Shipworm IPv6 address associated to the local interface, the Shipworm server processes the packet; it may in particular have to process "router solicitation" and "echo request" packets according to the corresponding procedures. If the IPv6 destination address is a valid Shipworm IPv6 address, the Shipworm server encapsulates the IPv6 packet in a new UDP datagram, in which the following parameters are set: - The destination IPv4 address is derived from the IPv6 destination. - The source IPv4 address is the Shipworm IPv4 anycast address. - The destination UDP port is derived from the IPv6 destination. - The source UDP port is set to the Shipworm Relay Port. If the destination address is not a Shipworm IPv6 address, the packet should be relayed to the IPv6 Internet using IPv6 routing. Before relaying packets, the Shipworm server MAY perform the security tests suggested in section 7. 4.3.2 Processing of router solicitations When the Shipworm server receives a router solicitation (RS), it retains the IPv4 address and UDP port from which the solicitation was received; these become the Shipworm mapped address and Shipworm mapped port of the client. The router uses these values to compose a Shipworm IPv6 Prefix. The Shipworm server responds to the router solicitation by sending a Router Advertisement. The router advertisement must advertise the Huitema [Page 10] INTERNET DRAFT Shipworm July 12, 2001 Shipworm IPv6 prefix composed from the mapped address and mapped port. The IPv6 destination address is normally set to the IPv6 source address of the RS; if that address was the unspecified address, the IPv6 destination should be set to the Shipworm IPv6 anycast address. The Router Advertisement must be sent over UDP to the Shipworm mapped address and Shipworm mapped port of the client; the IPv4 source address and UDP source port should be set to the Shipworm IPv4 anycast address and Shipworm Port. 4.3.3 Processing of echo requests When the Shipworm server receives an echo request over the Shipworm port, it prepares an ICMP echo reply. If the IPv6 source address of the echo request is a Shipworm address, the IPv6 source address of the response must be set to the Shipworm IPv6 address of the server; the IPv4 destination address and UDP destination port should be set to the value derived from the Shipworm IPv6 address of the client; the IPv4 source address and UDP source address should be set to the values derived from the Shipworm IPv6 address of the server. 4.3.4 Processing of bubbles Shipworm servers may receive Shipworm Discard messages on a discard port; these messages are silently discarded. 4.4 Shipworm Relay specification Shipworm relays are IPv6 routers that advertise reachability of the Shipworm service IPv6 prefix. Shipworm relays will receive IPv6 packets bound to Shipworm clients. Shipworm routers can transmit Shipworm packets in one of two ways, depending of whether or not the local configuration allows them to use the Shipworm IPv4 anycast address as the source address of UDP packets. If the Shipworm Relay can use the Shipworm IPv4 anycast address as a source address, it should transmit the IPv6 packets directly to the target Shipworm client: the IPv4 destination address and UDP destination port are derived from the destination Shipworm IPv6 address; the IPv4 source address and UDP source port are set to the Shipworm IPv4 anycast address and Shipworm UDP port. If the Shipworm Relay cannot use the Shipworm IPv4 anycast address as a source address, it should transmit the IPv6 packets through the nearest Shipworm server: the IPv4 destination address and UDP destination port are set to the Shipworm IPv4 anycast address and Shipworm UDP port; the IPv4 source address and UDP source port are set to a local interface address and local port number on the relay. It is obviously desirable to combine the functions of Shipworm relay and Shipworm server, but this is not mandatory. Huitema [Page 11] INTERNET DRAFT Shipworm July 12, 2001 5 Discussion of the solution 5.1 Why do we have bubbles and lists of peers? Experience shows that the implementers of NAT products can adopt widely different treatments of UDP packets: 1. Some implement the simplest solution, which is to map an internal UDP port, defined by an internal address and a port number on the corresponding host, to an external port, defined by a global address managed by the NAT and a port number valid for that address. In this simple case, the mapping is retained as long as the port is active, and is removed after an inactivity timer. As long as the mapping is retained, any packet received by the NAT for the external port is relayed to the internal address and port. 2. Some implement a more complex solution, in which the NAT not only establishes a mapping for the UDP port, but also maintains a list of external hosts to which traffic has been sent from that port. The packets originating from third party hosts to which the local host has not yet sent traffic are rejected. 3. Instead of keeping just a list of authorized hosts, some NAT implementations keep a list of authorized host and port pairs. UDP packets coming from remote addresses are rejected if the internal host has not yet sent traffic to the outside host and port pair. 4. Finally, some NAT map the same internal address and port pair to different external address and port pairs, depending on the address of the remote host. Measurement campaigns and studies of documentations have shown that most NAT implement either option 1 or option 2. The combination of "bubbles" and "list of peers" allows us to cross these types of NAT; it is not strictly required for the NAT of type 1, but it does not hurt either. 5.2 Why do we test with ICMP? The purpose of the ICMP test is to check that the client is capable of receiving UDP packets on a mapped port, from a different server than the one which performed the address mapping - i.e. to verify that the NAT is of type 1 or 2, not 3 or 4. The ICMP request will trigger a "triangle": 1) ICMP request sent by the client to the Shipworm IPv4 anycast address, 2) Local transmission on the server between the anycast address and the unicast interface, Huitema [Page 12] INTERNET DRAFT Shipworm July 12, 2001 3) ICMP response sent from the unicast address of the server. This test, combined with the transmission of a bubble, is sufficient to check that the same mapping can be used independently of the IPv4 address of the peer. 5.3 Why do we need an anycast address? The use of an IPv4 anycast address to locate the Shipworm server has many advantages. An obvious one is that it solves configuration issues, making it very easy for the Shipworm client to locate the nearest server. A less obvious one is the interaction with the NAT. The type 2 NAT check that the packet comes from a source with which the local client already interacted; by using a single unicast address as the source address of all UDP packets coming from all Shipworm servers, we guarantee that the "pin-hole in the NAT" can be use by all of these servers. The use of an anycast address is facilitated by the stateless implementation of Shipworm servers: since the service is performed in exactly the same way by any server, it does not matter whether anycast routing carries the packet to a specific server or another. The only dependency that we have is during the qualification phase: it is important that the echo packet be processed by the same server for which we have sent a bubble. However, since the IPv6 destination address of the echo request specifies a specific server address, we know that even the anycast packet was routed to another server, the normal routing rule will ensure that the packet is relayed from there to the intended server. The consequences of the use of anycast addresses on access control, scaling, and failover are discussed in [RFC3068] in the context of the "6to4" service. 5.4 When to use Shipworm? Shipworm is designed to robustly enable IPv6 traffic through NAT, and the price of robustness is a reasonable amount of overhead, due to UDP encapsulation, transmission of bubbles, and relaying of packets through the Shipworm servers. Nodes that want to connect to the IPv6 Internet should only use the Shipworm service as a "last resort" option: they should prefer using direct IPv6 connectivity if it is locally available, and they should prefer using the less onerous "6to4" encapsulation if they can use a global IPv4 address. 5.5 What about firewalls? The Shipworm service is not designed to "transparently traverse firewalls." A local administrator can decide to allow or disallow the service, by programming the local firewall to authorize or deny traffic on the Shipworm UDP port. Huitema [Page 13] INTERNET DRAFT Shipworm July 12, 2001 5.6 Why do we use the name Shipworm? A "Shipworm" is a little saltwater critter that is common in the harbors of warm seas and that digs holes in immersed wood pieces, such as boat hulls or posts. The animal is not an actual worm - it is a mollusk. The Shipworm service also digs holes, albeit in NATs, not in wood. On one hand, one may think that the shipworm is a pretty nasty animal. On the other hand, the animal only survives in relatively clean and unpolluted water; its recent comeback in several Northern American harbors is a testimony to their newly retrieved cleanliness. The Shipworm service should, in turn, contribute to a newly retrieved transparency of the Internet. 6 Future Work Obviously a lot - this is a first draft. 7 Security Considerations The security consideration for using a dynamic encapsulation of IPv6 over UDP are very similar to the implications of "6to4" [RFC3056], which we partially reproduce here. Implementors should be aware that, in addition to possible attacks against IPv6, security attacks against IPv4 must also be considered. Use of IP security at both IPv4 and IPv6 levels should nevertheless be avoided, for efficiency reasons. For example, if IPv6 is running encrypted, encryption of IPv4 would be redundant except if traffic analysis is felt to be a threat. If IPv6 is running authenticated, then authentication of IPv4 will add little. Conversely, IPv4 security will not protect IPv6 traffic once it leaves the Shipworm service. Therefore, implementing IPv6 security is required even if IPv4 security is available. By default, Shipworm traffic will be accepted and decapsulated from any source from which regular IPv4 traffic is accepted. If this is for any reason felt to be a security risk (for example, if IPv6 spoofing is felt to be more likely than IPv4 spoofing), then additional source address based packet filtering could be applied. A possible plausibility check is whether the encapsulating IPv4 address is consistent with the encapsulated Shipworm IPv6 address. If this check is applied, exceptions to it must be configured to admit traffic from Shipworm relays and Shipworm servers. In any case, any Shipworm traffic whose source or destination address embeds a mapped IPv4 address which is not in the format of a global unicast address MUST be silently discarded by both Shipworm clients and Shipworm servers. Specifically, this means that IPv4 addresses defined in [RFC 1918], broadcast, subnet broadcast, Huitema [Page 14] INTERNET DRAFT Shipworm July 12, 2001 multicast and loopback addresses are unacceptable. 8 IANA Considerations This memo documents a request to IANA to allocate a Shipworm IPv6 service prefix, a Shipworm IPv4 anycast prefix, a Shipworm IPv4 anycast address and a Shipworm UDP port. 9 Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society July 12, 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 10 Intellectual Property The following notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights Huitema [Page 15] INTERNET DRAFT Shipworm July 12, 2001 might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 11 Acknowledgements Many of the ideas in this memo are the result of discussions between the author and Microsoft colleagues, notably Brian Zill and Rick Rashid. Several encapsulation details are inspired from early work by Keith Moore. 12 References [RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3068] C. Huitema, "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. 13 Authors' Addresses Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: huitema@microsoft.com Huitema [Page 16]