INTERNET DRAFT                                              C. Huitema
<draft-ietf-ngtrans-shipworm-01.txt>                         Microsoft
Expires March 5, 2002                                September 5, 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 enables 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.

A possible way to solve the problem is to rely on a set of "tunnel

Huitema                                                      [Page  1]


INTERNET DRAFT               Shipworm                September 5, 2001

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

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 [RFC2119].

This specification uses the following 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

Huitema                                                      [Page  2]


INTERNET DRAFT               Shipworm                September 5, 2001

IANA)

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


Huitema                                                      [Page  3]


INTERNET DRAFT               Shipworm                September 5, 2001

A Shipworm IPv6 address obtained by combining a Shipworm IPv6 client
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).

2.16    Shipworm Refresh Interval

The interval during which a Shipworm IPv6 Address is expected to
remain valid in the absence of "refresh" traffic. For a client
located behind a NAT, the interval depends on configuration
parameters of the local NAT, or in fact of the combination of NATs
on the path to the Shipworm server. By default, clients assume an
interval value of 30 seconds; a longer value may be determined by
local tests, described in section 4.

2.17    Shipworm secondary port

A UDP port used to determine the appropriate value of the refresh
interval, but not used to carry any Shipworm traffic.

2.18    Random link-local address

An IPv6 link-local address chosen at random, as specified in section
4.1.5.


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.


Huitema                                                      [Page  4]


INTERNET DRAFT               Shipworm                September 5, 2001

The primary role of the servers is to enable the NAT traversal. The
service is designed in such a way that, when NAT traversal is
guaranteed, packets can flow on a direct path between source and
destination, without necessarily involving a relay by a Shipworm
server.

3.1     Robustness requirement

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.

3.2     Protection against denial of service attacks

Shipworm servers will act as a relay for IPv6 packets. Improperly
designed packet relays can be used by denial of service attackers to
hide their address, making the attack untraceable. The shipworm
service must include adequate protection against such misuse.

3.3     Non-requirement of permanent addresses

Our design objective is that any node that has obtained a legitimate
IPv4 connection, even behind a NAT, can obtain a globally reachable
IPv6 address. We want to achieve this objective in the most
automatic manner, without requiring any explicit configuration:
explicit configuration is easy to manage by sophisticated users, but
the experience shows that it can be an insurmountable hurdle for
novice users.

The absence of explicit configuration excludes another potential
requirement, that nodes obtain a "permanent" address: such permanent
assignments require that nodes provide explicit credentials when
they connect to the network, which in turn implies explicit
management of these credentials.

The absence of permanent addresses can be palliated by "name
services" or "rendezvous services" through which the node can
publish its address of the moment to its peers; for example, the
nodes can be reached through a SIP proxy server, or could use
dynamic DNS updates to publish their current address. When permanent
addresses are required, they can be obtained and managed by other
means; in particular, the Shipworm Address can be used as a "care
of" address in a Mobile IPv6 service.

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

Huitema                                                      [Page  5]


INTERNET DRAFT               Shipworm                September 5, 2001

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
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 are composed of 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 [RFC768] within
IPv4 [RFC791].  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 [RFC2640].

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 parameters:

- IPv4 source address: the Shipworm mapped address of the sender

Huitema                                                      [Page  6]


INTERNET DRAFT               Shipworm                September 5, 2001

- IPv4 destination address: the IPv4 address of the target

- UDP source port: the Shipworm mapped port of the sender

- UDP destination port: the Shipworm mapped port of the target

- UDP payload: a minimal IPv6 packet, as follows

- IPv6 source: the Shipworm IPv6 address of the sender

- IPv6 destination: the Shipworm IPv6 address of the target

- IPv6 payload type: 59 (No Next Header, as per [RFC2460])

- IPv6 payload length: 0

4.1.5   Random link local address

The Shipworm client uses a random link local address as the IPv6
source address of the router solicitation messages used in the
qualification and maintenance procedure. The random link local
address is an IPv6 source address composed of The 64 bit link local
prefix: FE80::/64, and of a 64 bit node identifier picked at random.

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,
- Random link local address,
- Date and time of the last interaction with the Shipworm server,
- Shipworm Refresh Interval,
- Randomized Refresh Interval,
- 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". For each peer, the list
contains:

- The mapped IPv4 address and mapped UDP port of the peer,
- The date and time of the last reception from the peer,

Huitema                                                      [Page  7]


INTERNET DRAFT               Shipworm                September 5, 2001

- The date and time of the last transmission to the peer,
- The number of bubbles transmitted to the peer.

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."

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. The refresh procedure takes as
a parameter the "shipworm refresh interval". This parameter is
initially set to 30 seconds; it can be updated as a result of the
optional "interval determination procedure." The randomized refresh
interval is set to a value randomly chosen between 75% and 100% of
the refresh interval.

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" stage if
unsuccessful.

          /---------\
          | Initial |
          \---------/
               |
          +----+----+
          | Start   |<------+
          +----+----+       |
               |            |
               v            |
          /---------\ Timer |
          |Starting |-------+ N attempts   /----------\
          \---------/--------------------->| Off-line |
               | Response                  \----------/
               |
               V
          /---------\
          |Qualified|
          \---------/

Initially, the Shipworm connectivity status is set to "Initial". At
this point, the client will choose a random link local address, as
defined in 4.1.5.


Huitema                                                      [Page  8]


INTERNET DRAFT               Shipworm                September 5, 2001

When the interface is initialized, the system first performs the
"start action" by sending a Router Solicitation Message, as defined
in [RFC2461]. 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 response is a
valid router advertisement as defined in [RFC2461], that the IPv6
destination address is equal to the random link local address picked
used in the router solicitation, and that it contains exactly one
advertised Prefix Information parameter. 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,

- 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, with a matching destination 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 is
qualified, and can start using the Shipworm service.

4.2.2   Packet reception

The Shipworm client receives packets 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 over the Shipworm service port, the
Shipworm client checks that it contains a valid IPv6 packet as
specified in [RFC2460]; if this is not the case, the packet is

Huitema                                                      [Page  9]


INTERNET DRAFT               Shipworm                September 5, 2001

silently discarded. Then, 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.

If the values are different, the client examines the IPv6 source
address of the encapsulated packet. If the IPv6 source address is
not a valid Shipworm IPv6 address, or if the IPv4 address embedded
in the Shipworm address is not in the format of a global unicast
address, the packet MUST be silently discarded. 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
these addresses and port don't match the source IP address and
source UDP port of the packet, the packet MUST be silently
discarded; if they match the client has received a direct packet
from a peer. If the address and port pair are already represented in
the "list of recent peers", the client MUST update the data and time
of last reception from this peer. If the pair is not yet
represented, the client MUST create a new list entry for the pair,
setting the last reception date do the current date and time, the
last transmission date to 30 seconds before the current date, and
the number of bubbles to zero.

Whatever the IPv4 source address and UDP source port, the client
that receives an IPv6 packet from a Shipworm IPv6 source address MAY
start sending a Shipworm Bubble towards that target, as specified in
section 4.2.5.

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. Before sending the packet, the Shipworm Client MUST check
that the IPv4 destination address is in the format of a global
unicast address; if this is not the case, the packet MUST be
silently discarded.

If there is an entry for this address and port pair in the list of
recent Shipworm peers, and if the date and time associated with that
list entry is less that 30 seconds from the current time the packet
SHOULD be send over UDP directly to the specified "peer IPv4
address" and "peer UDP port", and the transmission date for that
list entry should be set to the current time.

If there is no entry in the list, or if the date and time associated
to the entry is too old, the client should then send the IPv6 packet

Huitema                                                      [Page 10]


INTERNET DRAFT               Shipworm                September 5, 2001

over IPv4 UDP to the Shipworm IPv4 anycast address and Shipworm UDP
port; the client MAY start sending a Shipworm Bubble towards the
destination IPv6 address, as specified in section 4.2.5.

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 Randomized Shipworm
Refresh Interval. If this is not the case, the client SHOULD select
a new randomized link local address and use this address to send a
router solicitation message to the Shipworm IPv6 Anycast address.

When the router advertisement is received, the client should check
its validity as specified in 4.2.1; invalid advertisements are
silently discarded. If the advertisement is valid, the client MUST
check 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 prefix.

After sending receiving a router advertisement, the Randomized
Shipworm Refresh Interval is reset to a new value, randomly chosen
between 75% and 100% of the Shipworm Refresh Interval.

4.2.5   Sending Shipworm Bubbles

The Shipworm client may decide to send a bubble towards another
Shipworm client, either after a packet reception or after a
transmission attempt, as explained in sections 4.2.1 and 4.2.2.

When a Shipworm client attempts to send a bubble, it extracts the
mapped IPv4 address and mapped UDP port from the Shipworm IPv6
address of the target. It then checks whether there is already an
entry for this address and port pair in the current list. If the
pair is not yet represented, the client MUST create a new list entry
for the pair, setting the last reception date and the last
transmission date to 30 seconds before the current date, and the
number of bubbles to zero.

The client MUST NOT send a bubble if the last transmission date and
time is less than 10 seconds before the current date and time, or if
the number of transmitted bubbles is larger than 4 and the last
reception date and time is less than 300 seconds before the current
date and time. In the other cases, the client MAY proceed with the
transmission of the bubble, which MUST be composed as specified in
section 4.1.4. When transmitting the bubble, the client MUST update

Huitema                                                      [Page 11]


INTERNET DRAFT               Shipworm                September 5, 2001

the last transmission date and time to that peer, and must also
increment the number of transmitted bubbles.

4.2.6   Optional Refresh Interval Determination Procedure

In addition to the regular client resources described in the
beginning of this section, the refresh interval determination
procedure uses an additional UDP port, the Shipworm secondary port,
and the following variables:

- Shipworm secondary connectivity status,
- Mapped address and port number of the Shipworm secondary port,
- Shipworm secondary IPv6 prefix associated with the secondary port,
- Shipworm secondary IPv6 address derived from this prefix,
- Date and time of the last interaction on the secondary port,
- Maximum Shipworm Refresh Interval.
- Candidate Shipworm Refresh Interval.

The secondary connectivity status, mapped address and prefix are
determined by running the qualification procedure on the secondary
port. When the client uses the interval determination procedure, the
qualification procedure MUST be run for the secondary port
immediately after running it on the service port. If the secondary
qualification fails, the interval determination procedure will not be
used, and the interval value will remain to the default value, 30
seconds. If the secondary qualification succeeds, the maximum refresh
interval is set to 960 seconds, and the candidate shipworm refresh
interval is set to 60 seconds, i.e. twice the shipworm refresh
interval. The procedure is then performed at regular intervals, until
it concludes:

1) wait until the candidate refresh interval is elapsed after the
last interaction on the secondary port;

2) send a Shipworm Bubble to the Shipworm secondary IPv6 address,
through the service port.

3) wait for reception of the bubble on the secondary port. If a timer
of 2 seconds elapses without reception, repeat step 2 at most three
times. If there is still no reception, the candidate has failed; if
there is a reception, the candidate has succeeded.

4) if the candidate has succeeded, set the shipworm refresh interval
to the candidate value, and set a new candidate value to the minimum
of twice the new refresh interval, or the average of the refresh
interval and the maximum refresh interval.

5) if the candidate has failed, set the maximum refresh interval to
the candidate value. If the current refresh interval is larger than
or equal to 75% of the maximum, the determination procedure has
concluded; otherwise, set a new candidate value to the average of the
refresh interval and the maximum refresh interval.

Huitema                                                      [Page 12]


INTERNET DRAFT               Shipworm                September 5, 2001

6) if the procedure has not concluded, perform the maintenance
procedure on the secondary port, which will reset the date and time
of the last interaction on the secondary port, and may result in the
allocation of a new Shipworm secondary IPv6 address; this would not
affect the values of the refresh interval, candidate interval or
maximum refresh interval.

The secondary port MUST NOT be used for any other purpose than the
interval determination procedure. If a spurious packet is received on
the secondary port, the client SHOULD repeat the maintenance
procedure on this port and reset the date and time of the last
interaction on the secondary port.

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
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 messages, 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, which are processed according to the IPv6 specification.

The Shipworm service may be made available to neighboring Autonomous
Systems by advertising the Shipworm IPv4 Anycast prefix in the IPv4
EGP, as specified in 4.3.4. The domain managers must be ready to
perform fault isolation as specified in 4.3.5.

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.

Before processing the packet, the Shipworm server MUST check the
validity of the encapsulated IPv6 source address, the IPv4 source
address and the UDP source port:

1)      If the IPv4 source address does not belong to a range of IPv4
addresses for which the Shipworm server is providing service, the
server MAY silently discard the packet.

2)      If the IPv4 source address is not in the format of a global
unicast address, the packet MUST be silently discarded.

3)      If the IPv6 source address is the IPv6 unspecified address or an
IPv6 link local address, the IPv6 destination address is either
the Shipworm IPv6 anycast address or the Shipworm IPv6 address

Huitema                                                      [Page 13]


INTERNET DRAFT               Shipworm                September 5, 2001

associated to the local interface, and the packet contains an
ICMPv6 "router solicitation", the packet MUST be accepted.

4)      If the IPv6 source address is a Shipworm IPv6 address, and if the
IPv4 address and UDP port embedded in that address match IPv4
source address and the UDP source port, the packet MUST be
accepted.

5)      If the IPv4 source address is the Shipworm IPv4 anycast address,
and if the IPv6 destination is either the Shipworm IPv6 anycast
address or the Shipworm IPv6 address associated to the local
interface, the packet MUST be accepted.

6)      In all other cases, the packet MUST be rejected.

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" messages.

If the IPv6 destination address is a valid Shipworm IPv6 address,
the Shipworm Server MUST check that the IPv4 destination address is
in the format of a global unicast address; if this is not the case,
the packet MUST be silently discarded. If the address is valid, 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 IPv6 address is not a global scope IPv6 address,
the packet MUST be silently discarded. In the other cases, if the
destination address is not a Shipworm IPv6 address, the packet
should be relayed to the IPv6 Internet using regular IPv6 routing.

4.3.2   Processing of router solicitations

When the Shipworm server receives a router solicitation message (RS,
[RFC2641]), 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

Huitema                                                      [Page 14]


INTERNET DRAFT               Shipworm                September 5, 2001

Router Advertisement [RFC2641]. The router advertisement MUST
advertise the Shipworm IPv6 prefix composed from the mapped address
and mapped port. The IPv6 source address must be set to the Shipworm
IPv6 address associated to the local interface. 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. Before sending the packet, the Shipworm Router
MUST check that the IPv4 destination address is in the format of a
global unicast address; if this is not the case, the packet MUST be
silently discarded.

4.3.3   Processing of bubbles

Shipworm servers may receive Shipworm Bubbles; these messages are
silently discarded.

4.3.4   Advertising of the Shipworm IPv4 anycast prefix

If the managers of an IPv4 autonomous domain that includes Shipworm
servers want to provide the Shipworm service to neighbor Autonomous
Systems, they MAY advertise reachability of the Shipworm IPv4
anycast prefix using the EGP of their IPv4 autonomous system, as if
it where a connection to an external network. When this
advertisement is done using BGP, the initial AS path MUST contain
the AS number of the announcing AS.  The AS path should also include
an indication of the actual router providing the service; there is a
suggestion to perform this function by documenting the specific IPv4
address of the Shipworm server in the BGP aggregator attribute of
the path; further work is needed on this point.

Any Shipworm server corresponding to this specification SHOULD
include a monitoring function, to check that the Shipworm service is
operational.  The route leading to the Shipworm IPv4 anycast prefix
MUST NOT be announced if the service is not operational.

4.3.5   Fault isolation

When an error is reported, e.g., by a user, the domain manager
should be able to find the specific Shipworm Server that is causing
the problem.

The first step of fault isolation is to retrieve the specific IPv4
address of the server used by the user.  If the server is located
within the domain, this information will have to be retrieved from
the IGP tables.  If the service is obtained through a peering
agreement with another domain, the information will be retrieved
from the EGP data, e.g., the BGP path attributes.


Huitema                                                      [Page 15]


INTERNET DRAFT               Shipworm                September 5, 2001

The second step is obviously to perform connectivity tests using the
specific IPv4 address.

4.4     Shipworm Relay specification

Shipworm relays are IPv6 routers that advertise reachability of the
Shipworm service IPv6 prefix through the IPv6 routing protocols.
Shipworm relays will receive IPv6 packets bound to Shipworm clients.
Shipworm routers MUST be able to use the Shipworm IPv4 anycast
address as the source address of UDP packets.

By definition, the Shipworm relays will only process IPv6 packets
whose IPv6 destination address is a valid Shipworm IPv6 address.
Before processing these packets, the Shipworm Server MUST check that
the IPv4 destination address embedded in the Shipworm IPv6 address
is in the format of a global unicast address; if this is not the
case, the packet MUST be silently discarded. If the address is
valid, 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.

It is obviously desirable to combine the functions of Shipworm relay
and Shipworm server, but this is not mandatory.

5       Discussion of the solution

5.1     How can we learn the address?

In order to explain how Shipworm works, we will use an hypothetical
example: a shipworm client is located at the private IP address
10.0.0.2 in a private network; the NAT connecting this network to
the public Internet responds to the local address 10.0.0.1 and is
visible as the public address 9.0.0.1.













Huitema                                                      [Page 16]


INTERNET DRAFT               Shipworm                September 5, 2001

                                          .-----------------------
                                          |  Private network
                .--.      ____          .-----.     .----------.
               (IPv4)  src=9.0.0.1:4096 | NAT |     | Shipworm |
             (Internet)<--------------  | BOX | <-- |  Client  |
               (    )   (UDPv4 tunneled |     |     '----------'
                '--'         IPv6)      '-----'       10.0.0.2:1234
                 |                9.0.0.1 | 10.0.0.1
                 |                        |
                 |                        |
                 V                        |
          .--------------.                '-----------------------
          |   Shipworm   |
          |   Server     |
          '--------------'
            [IPv4-anycast]

When the Shipworm client is turned up, it sends an IPv6 router
solicitation over UDP to the IPv4 anycast address of the Shipworm
server, using the source address and ports 10.0.0.2:1234. The NAT
captures the packet, establishes a mapping, and changes the source
address and port to 9.0.0.1:4096. (These values are indeed just
examples.)

The Shipworm receives the packet and notes the source address. It
uses it to construct a Shipworm IPv6 client prefix:

         PREF:0900:0001:2860::/64

In this prefix, "PREF" is the 16 bit Shipworm IPv6 service prefix;
"0900:0001" is the hexadecimal notation of the IPv4 mapped address
"9.0.0.1"; and "2860" is the hexadecimal notation of the mapped port
"4096".

The router sends the router advertisement back over UDP to the
mapped IPv4 address 9.0.0.1:4096. The IPv4 packet is received by the
NAT, which has presumably remembered the mapping between this
external address and the private address and port pair,
10.0.0.2:1234; the NAT forwards the packet to the Shipworm client.
Further packets coming from the Internet will use the same mapping.

5.2     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,

Huitema                                                      [Page 17]


INTERNET DRAFT               Shipworm                September 5, 2001

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 all types of NAT,
including those of type 3 and 4; we optimize the direct transmission
between NAT of types 1 and 2.

5.3     Could we make do with fewer bubbles?

It is true that if we knew the type of the NAT at each end, we could
diminish the amount of bubbles that we send. For example, a Shipworm
client behind a type-1 NAT never needs to send or receive bubbles:
the NAT will let packet through from any destination. Similarly, a
Shipworm client behind a type 3 NAT should not bother sending
bubbles, since these bubbles will never have any effect on the NAT.
On the other end, bubbles are useful for type-2 NAT, which according
to our sample represent about half the implementations.

A problem with any "smart" approach is that it requires a
"characterization" procedure for the local NAT, which is complex and
possibly error prone. More importantly, any smart approach
introduces failure modes. A particularly nasty problem arises when
two clients are located behind the same NAT; this can happen when
the NAT is installed by an ISP. In this case, even if the NAT is
"type-1", we may have a problem, as exposed in the following
diagram:









Huitema                                                      [Page 18]


INTERNET DRAFT               Shipworm                September 5, 2001

                                          .-----------------------
                                          |  Private network
                .--.   src=9.0.0.1:4096 .-----.     .----------.
               (IPv4)  src=9.0.0.1:4097;| NAT |     | Shipworm |
             (Internet)<--------------  | BOX | <-- | Client-1 |
               (    )   (UDPv4 tunneled |     | <.  '----------'
                '--'         IPv6)      '-----'  |    10.0.0.2:1234
                 |                9.0.0.1 |      |  .----------.
                 |                        |      |  | Shipworm |
                 |                        |      '- | Client-2 |
                 V                        |         '----------'
          .--------------.                |           10.0.0.3:1234
          |   Shipworm   |                '-----------------------
          |   Server     |
          '--------------'
            [IPv4-anycast]

The first client uses the private address and port 10.0.0.2:1234,
which is mapped to 9.0.0.1:4096 by the NAT; the second client uses
10.0.0.3:1234, mapped to 9.0.0.1:4097. If the first client tries to
send a direct packet to the second client, that packet will be
routed to the address 9.0.0.1:4097, i.e. to the external IP address
of the local NAT. What happens next is everybody's guess: some NAT
may do the right thing, some may drop the packet.

Our algorithm is designed to privilege robustness: unless the client
knows otherwise, the packets will always be sent through a Shipworm
server, and will always be received through the single "pin-hole"
that allows communication between the Shipworm client and the
Shipworm anycast address. The packets will only be sent on the
direct path if the client actually received a packet or a bubble on
that direct path, demonstrating the existence of a chain of mappings
on all the NAT located between the Shipworm peers.

The algorithm for sending bubbles is designed to be conservative: we
only send bubbles when necessary, and limit the transmission rate
when we suspect that the sending of the bubbles is useless. In a
type 3 NAT, we will send at most four bubbles to a destination, and
then we will observe a silence period of 300 seconds.

5.4     Do we need the Refresh Interval Determination Procedure?

When the client is initialized, the Shipworm Refresh Interval is set
to 30 seconds. This value is lower than the minimum interval found
necessary in a measurement campaign conducted by a Microsoft team in
January 2001; the measured values ranged between 45 seconds and more
than 15 minutes. There is always a risk that some NAT manufacturers
program some ever smaller time to live intervals for their mappings,
but doing so would break many applications and would probably
generate uproar from Internet users. By picking a conservatively
small value, we guarantee that the service will work with most NATs.

Huitema                                                      [Page 19]


INTERNET DRAFT               Shipworm                September 5, 2001

On the other hand, picking a conservative value increases the
maintenance traffic and the load on the Shipworm servers. We know
that in many cases interval as large as 5 or 10 minutes would be
adequate. The determination procedure is designed to quickly find
whether a larger value is adequate. The parameters have been chosen
for rapid convergence, i.e. at most 5 iterations between the initial
value of 30 seconds and the maximum value of 960 seconds or 16
minutes.

5.5     Why do we use a Randomized Refresh Interval?

We specify in the maintenance procedure that the interval between
successive refresh must be a random value chosen between 75% and
100% of the Shipworm Refresh Interval. This randomization procedure
is meant to avoid the possible risk of synchronization that is
inherent to any periodic refresh mechanism; if synchronization
occurred, all shipworm clients would send their router solicitation
messages quasi simultaneously to the shipworm server, which would
overwhelm the server. A synchronization phenomenon caused by
periodic messages is studied in [SYNCHRO]; the 75%-100% interval is
meant to meet the guidelines developed in this reference
publication.

5.6     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 and type 3 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 used 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.

5.7     Scaling, failover and access control

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.

Using an anycast address and stateless servers has beneficial
consequences on scaling. It is possible to start deployment with a
small number of Shipworm servers, reachable across the Internet. It
is then possible to deploy more servers across the Internet, as
demand increases.

Huitema                                                      [Page 20]


INTERNET DRAFT               Shipworm                September 5, 2001

Shipworm packets will be naturally forwarded to the nearest server,
as specified in the IPv4 routing tables. If a Shipworm server
somehow breaks, or loses connectivity to the v6 Internet, it will
cease to advertise reachability of the Shipworm IPv4 prefix prefix.
At that point, the local IGP will automatically compute a route
towards the "next best" Shipworm server.  We expect that adequate
monitoring tools will be used to guarantee timely discovery of
connectivity losses.

Only those ASes that run Shipworm Servers and are willing to provide
access to the v6 network announce a path to the Shipworm IPv4
anycast prefix.  They can use the existing structure of peering and
transit agreements to control to whom they are willing to provide
service, and possibly to charge for the service.

5.8     Why do we use a randomized link-local address?

The qualification and maintenance procedure could possibly be
affected by a denial of service attack in which a malevolent third
party sends a spoofed router advertisement to a Shipworm Client,
containing an IP address and UDP port different from the actual
mapped IP address and mapped UDP port of the client. The attacker
could learn the real values of the mapped address and port from the
Shipworm IPv6 Address used by the client; it could either predict
the time at which the Shipworm Client will issue a router
solicitation or send relatively frequent advertisement messages.

The use of a randomized link-local address in the router
solicitation messages provides some protection against this attack:
a router advertisement whose destination address does not match the
expected value will be silently discarded. The randomized address is
used only once, which makes it hard to learn by a third party.
Implementers should however make sure that the random values that
they use are not easily guessable; it would be a good idea to use a
secure random number generator, as discussed in [RFC1750].

5.9     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.10    What about firewalls?

The Shipworm service is not designed to "transparently traverse
firewalls." A local administrator can decide to allow or disallow

Huitema                                                      [Page 21]


INTERNET DRAFT               Shipworm                September 5, 2001

the service, by programming the local firewall to authorize or deny
traffic on the Shipworm UDP port.

5.11    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, contributes to a
newly retrieved transparency of the Internet.

6       Future Work

Some - this is a second draft.

7       Security Considerations

The security considerations 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.

In contrast with the 6to4 default, Shipworm traffic will not be
accepted and decapsulated from any source from which regular IPv4
traffic is accepted: the service is designed to prevent malevolent
agent from using Shipworm servers for "laundering" a denial of
service attack. Shipworm packets are always sent from either the
Shipworm IPv4 anycast address, or from an IPv4 address and UDP port
that is strictly consistent with the encapsulated IPv6 source
address; this MUST be checked by servers and clients, as specified
in sections 4.2.2 and 4.3.1. We expect that only routers controlled
by Internet Service Providers will be authorized to use the anycast
address as a source address for UDP packets.

There is a possible denial of service attack against the address

Huitema                                                      [Page 22]


INTERNET DRAFT               Shipworm                September 5, 2001

mapping service, which we discuss in section 5.8. In order to
protect against this attack, we use a randomized link local address
as source of router solicitations and check that the same random
value is present in router advertisements.

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 Shipworm
clients, servers, and routers as specified in sections 4.2.2, 4.2.3,
4.3.1, and 4.4.  Specifically, this means that IPv4 addresses
defined in [RFC1918], broadcast, subnet broadcast, 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.


Huitema                                                      [Page 23]


INTERNET DRAFT               Shipworm                September 5, 2001

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
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, John Miller
and Rick Rashid. Several encapsulation details are inspired from
early work by Keith Moore. The example in section 5.1 and a number
of security precautions were suggested by Pekka Savola, and the
discussion in 5.3 by Art Shelest.

12      References

[RFC768] J. Postel, "User Datagram Protocol", RFC 768, August 1980.


[RFC791] J. Postel, "Internet Protocol", RFC 791, September 1981.

[RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot,
E. Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996.

[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.

[RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.


Huitema                                                      [Page 24]


INTERNET DRAFT               Shipworm                September 5, 2001

[RFC2461] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.

[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.

[RFC1750] D. Eastlake, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.

[SYNCHRO] S. Floyd, V. Jacobson, "The synchronization of periodic
routing messages", ACM SIGCOMM'93 Symposium, September 1993.

13      Authors' Addresses

Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399

Email: huitema@microsoft.com






























Huitema                                                      [Page 25]