INTERNET DRAFT                                                   Liu Min
<draft-liumin-v6ops-silkroad-01.txt>                          Wu Xianguo
Expires November, 2004                                        Cai Yibing 
                                                        	     ICT
                                                              Jin Mingye
                                                            China Unicom						
                                                               Li Defeng
                                                                  HUAWEI 
                                                                
                                   		               May, 2004






     Tunneling IPv6 with private IPv4 addresses through NAT devices

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

   The growth of IPv6 networks started mainly using the transport
   facilities offered by the current Internet. This led to the
   development of several techniques to manage IPv6 over IPv4 tunnels.
   However, classic tunneling methods do not work when the IPv6
   candidate node is isolated behind a Network Address Translator (NAT)
   device. We propose here a service, called Silkroad, to enable nodes
   located behind one or several IPv4 NATs to obtain IPv6 connectivity.
   It can provide IPv6 connectivity through all existing NAT types and
   does not require any update of them. In addition, Silkroad does not
   need special IPv6 addressing prefix and can provide the users with
   permanent/temporary IPv6 addresses. 



                       Expires November,2004                    [Page 1]

Internet-Draft    	      Silkroad              	       May 2004



Table of Contents:

   1 Introduction.....................................................3
   2 Silkroad Terminology.............................................4
   2.1 Silkroad Client (SC)...........................................4
   2.2 Silkroad Access Router (SAR)...................................4
   2.3 Silkroad Navigator (SN)........................................4
   2.4 Silkroad UDP port..............................................4
   3 Background.......................................................5
   3.1 What is NAT?...................................................5
   3.2 Types of NAT...................................................5
   3.3 Traversal of User Datagram Protocol (UDP) Through NATs.........5
   4 Silkroad Description.............................................6
   4.1 Silkroad Model.................................................6
   4.1.1 Silkroad Client (SC).........................................7
   4.1.2 Silkroad Access Router (SAR).................................7
   4.1.3 Silkroad Navigator (SN)......................................7
   4.2 Silkroad Operation.............................................8
   4.2.1 Determining the SAR..........................................8
   4.2.2 Obtaining IPv6 Address.......................................9
   4.2.3 Determining the Type of NAT.................................10
   4.2.4 Packet Transmission from a SC to a Regular IPv6 Node........10
   4.2.5 Packet Transmission from a Regular IPv6 Node to a SC........12
   4.2.6 Exchanges Between Two Silkroad Clients......................14
   4.3 Deployment Model..............................................15
   4.3.1 Silkroad Access Router Deployment...........................16
   4.3.2 Silkroad Navigator Deployment...............................16
   5 Route Optimization..............................................18
   5.1 Exchanges Between two Silkroad Clients........................18
   5.2 Exchanges Between two Silkroad Clients on the Same Link.......19
   6 Message Formats.................................................22
   7 Other Issues of the Solution....................................23
   7.1 Lifetime of NAT Mappings......................................23
   7.2 Lifetime of Silkroad Tunnel...................................23
   7.3 Silkroad in the Post Era of IPv6..............................23
   7.4 Difference between Silkroad and Teredo........................23
   8 Security Consideration..........................................25
   9. IANA Considerations ...........................................25
   10.Acknowledgments................................................25
   References........................................................26
   Authors' Addresses................................................27

   









                       Expires November,2004                    [Page 2]

Internet-Draft    	      Silkroad              	        May 2004



1.	Introduction

   The growth of IPv6 networks started mainly using the transport
   facilities offered by the current Internet. Complete upgrades of
   current Internet from IPv4 to IPv6 will take a long time. Thus the
   key to a successful IPv6 transition is compatibility with the large
   installed base of IPv4 hosts and routers.  Maintaining compatibility
   with IPv4 while deploying IPv6 will streamline the task of
   transition of the Internet to IPv6. This led to the development of
   several techniques to manage IPv6 over IPv4 tunnels. Classic
   tunneling methods designed for IPv6 transition operate by sending
   IPv6 packets as payload of IPv4 packets. However, these methods do
   not work when the IPv6 candidate node is isolated behind a Network
   Address Translator (NAT) device. The reason is that usually NATs will
   perform ingress filtering and refuse to allow the transmission of
   many payload types.

   In this memo, we propose a service, called Silkroad, to enable nodes
   located behind one or several IPv4 NATs to obtain IPv6 connectivity
   with the help of "Silkroad navigator" and "Silkroad access routers".
   It provides connectivity for clients located behind all existing NAT
   types, including symmetric NAT. Silkroad does not need special IPv6
   addressing prefix and can provide the users with permanent IPv6
   address. Silkroad approach is expect to be useful to stimulate the
   growth of IPv6 and to allow early IPv6 network providers to provide
   easy access to their IPv6 network. When IPv6 is quite widespread and
   IPv4 hosts are just small isolated sites on the IPv6 Internet, the
   process of Silkroad will be much simpler and the "Silkroad avigator"
   can be omitted.  
   
   This document is intended to present a framework describing the
   guidelines for the provision of a Silkroad service within the
   Internet. It details the general architecture of the proposed
   approach and also outlines a set of viable implementation. The memo
   is organized as follows. Section 2 contains the definition of the
   terms used in the memo. Section 3 introduces the background
   information. Section 4 provides an overall description of the
   Silkroad model. Section 5 presents the route optimization of Silkroad
   in certain scenarios. Section 6 contains the format of the messages.
   Section 7 is a discussion of some other issues of this solution.
   Section 8 and Section 9 contain a security discussion and IANA
   consideration.










                       Expires November,2004                    [Page 3]

Internet-Draft    	      Silkroad              	       May 2004



2.	Silkroad Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This section defined other terminology used with Silkroad:

2.1	Silkroad Client (SC)

   A dual stack node that has some access to the IPv4 Internet and that
   wants to gain access to the IPv6 Internet.


2.2	Silkroad Access Router (SAR)

   A dual stack router that has access to the IPv4 Internet through a
   globally registered address. It will be used to help Silkroad clients
   to gain IPv6 connectivity.

2.3	Silkroad Navigator (SN)

   A node that has access to the IPv4 Internet, and that is used to
   help SCs to choose appropriate SAR and help SARs to route between 
   each other. It may also be IPv6 addressable, but this is not
   mandatory.
  
2.4	Silkroad UDP port
  
   The UDP port number at which Silkroad Access Routers are waiting for
   packets. The value of this port is TBD. In this memo, we use port 
   5188 temporarily.




















                       Expires November,2004                    [Page 4]

Internet-Draft    	      Silkroad              	       May 2004



3.      Background

3.1	What is NAT?

   The need for IP address translation arises when a network's internal
   IP addresses can not be used outside the network either because they
   are invalid for use outside, or because the internal addressing must
   be kept private from the external network.

   Network Address Translation(NAT)is a method by which IP addresses are
   mapped from one realm to another. It is often used to connect an
   isolated address realm with private unregistered addresses to an
   external realm with globally unique registered addresses. [2]
   describes the operation of NAT devices and the associated
   considerations in general.

   Typically, NATs are not programmed to allow the transmission of
   arbitrary payload types. As a result, many existing tunnel techniques 
   for IPv6 transition operation, which send IPv6 packets as payload of
   IPv4 packets, can not work if the user is using private IPv4 address
   behind a NAT box.

3.2	Types of NAT

   It is assumed that the reader is familiar with NATs.  It has been
   observed that NAT devices can adopt widely different strategies among
   implementations.  Four treatments observed in implementations are
   described in [5], which are Full Cone NAT, Restricted Cone NAT, Port
   Restricted Cone NAT and Symmetric NAT.

   Silkroad can provide IPv6 connectivity for clients located behind all
   these four NAT types. However, determining the type of NAT will be
   important when we want to optimize the transmission performance of
   Silkroad.

3.3	Traversal of User Datagram Protocol (UDP) Through NATs

   Experience shows that TCP and UDP are the only protocols guaranteed
   to cross the majority of NAT devices. Although transporting IPv6
   packets as the payload of TCP packets would be possible, it often
   result in a very poor QoS (Quality-of-Service). What's more, it is
   hard for applications to enforcing their own control on the
   transmission rate in TCP. As a result, current traversal techniques
   through NATs are generally based on UDP. Like Teredo, Silkroad also
   transports IPv6 packets as the payload of UDP packets. 







                       Expires November,2004                    [Page 5]

Internet-Draft    	      Silkroad              	       May 2004



4	Silkroad Description

   Silkroad communication procedures are based on assumptions on NAT
   treatment of UDP; such assumptions may prove invalid when new NAT
   devices are deployed.

   Silkroad is designed to robustly enable IPv6 traffic through NATs,
   and the price is a reasonable amount of overhead, due to UDP
   encapsulation. Thus Silkroad SHOULD NOT be used except when the
   direct IPv6 connectivity is not locally available and the node can
   not use a global IPv4 address.

4.1	Silkroad Model

   The typical model of Silkroad is shown in Figure 1.
                                    +------+
                                  / |      |
                                 /  | SAR  |
                                /   |      |
                               /    +------+
       +------+     +------+  /     +------+
       |      |     |      |        |      |
       |  SC  |<--->|  SN  |<------>| SAR  |
       |      |     |      |        |      |
       +------+     +------+  \     +------+
                               \    +------+               +------+      
    tunnel end-point            \   |      |               |      |
          /\                     \  | SAR  |<------------->| SAR' |
          ||                      \ |      |               |      |
          ||                        +------+               +------+
          ||                                                  /\
   -------||------NAT             tunnel  end-point           ||
          ||                           /\                     ||
          ||                           ||                     \/
          ||                           ||                  +------+
          ||                           ||                  | IPv6 |
          |+---------------------------+|                  | Node |
          +-----------------------------+                  |      |
                    UDP tunnel                             +------+


                      Figure 1: The Silkroad model

   As can be seen from Figure 1, the Silkroad service requires the 
   cooperation of three kinds of entities: Silkroad clients, who want to
   use IPv6 despite being located behind a NAT; Silkroad access routers,
   who provide for the interconnection between the Silkroad client and
   the existing IPv6 Internet; Silkroad navigators, who will facilitate
   the Silkroad client to find the appropriate SAR and help the SAR to
   forward packets.


                       Expires November,2004                    [Page 6]

Internet-Draft    	      Silkroad              	       May 2004



4.1.1	Silkroad Client (SC)

   A SC is a node that has some access to the IPv4 Internet and that
   wants to gain access to the IPv6 Internet despite being located
   behind a NAT. It mainly has the following functions:

     -  Connect to SN to search the list of available SARs, and choose
        the appropriate SAR to create UDP tunnel

     -  Manage UDP tunnel with SAR

         Create, modify or delete tunnel;
         Determining the type of NAT;
         Optimize routes;

     -  Security control with SN and SAR

     -  Ingress filtering

     -  Provide transparent Silkroad support for applications
 
4.1.2	Silkroad Access Router (SAR)

   A SAR is a dual-stack (IPv4 & IPv6) router that has access to the
   IPv4 Internet through a globally routable address. It mainly has the
   following functions:

      -  Connect to the SN to register its information, such as:

         Its IPv4 addresses (a SAR may have several IPv4 addresses);
         A name to be used for the registration in the DNS;
         The location information of the SAR;

      -  Manage UDP tunnel:

         Create, modify or delete tunnel;
         Determining the type of NAT;       
         Maintain usage statistics for every active tunnel;

      -  Connect to SN to search the IPv4 addresses of SARs that can
         forward IPv6 packets to a specific IPv6 network
        
      -  IPv6 address assignment and management
        
      -  Forward packets in IPv6/IPv4 networks
    
      -  Access control and security control

4.1.3	Silkroad Navigator (SN)



                       Expires November,2004                    [Page 7]

Internet-Draft    	      Silkroad              	       May 2004



   In order to enable the service, the Silkroad navigator MUST be IPv4
   addressable.  It MAY also be IPv6 addressable, but this is not
   mandatory.  A SN mainly has the following functions:

      -  Provide the list of available SARs to allow SC to choose the
         appropriate one

      -  Provide the list of SARs that can forward IPv6 packets to a
         specific IPv6 network and the IPv4 addresses of these SARs

      -  Assist SAR administrators to configure static routes or
         tunnels between each other

4.2	Silkroad Operation

4.2.1	Determining the SAR

   The first phase of Silkroad operation is determining an appropriate
   SAR to provide Silkroad service to the SC. To do this, the SC should
   connect to SN to search the list of available SARs, and select an
   appropriate SAR. This assigned SAR's information will be   
   automatically saved in the SC's configuration file. This SAR will
   become the SC's default SAR, unless the SC explicitly changes its
   configuration.

   The interaction between the SC and the SN could be based on http. In  
   this way, the SN should maintain a web page to provide the list of  
   the available SARs to allow SCs to choose.

   During this process, the SC MAY be asked to provide the relevant
   information by filling up some forms on the Web page.  Then the SN
   could respond with an html page displaying all the relevant
   information of SARs.
   
   Of course, a SC can determine the address or domain name of a SAR
   through other means. For example, the SC could get the address of
   SAR by sending Router Solicitation message over UDP to the SN. The SN
   replies with a Router Advertisement over UDP containing the address
   of available SAR. The SC can also get the SAR's information from its
   administrator, or broadcast an Route Solicitation to wait for the
   SAR's reply.

   These packets may have the following format:

   +------+-----+---------------------+
   | IPv4 | UDP | Router Solicitation |
   +------+-----+---------------------+

   +------+-----+----------------------+
   | IPv4 | UDP | Router Advertisement |
   +------+-----+----------------------+

                       Expires November,2004                    [Page 8]

Internet-Draft    	      Silkroad              	       May 2004



4.2.2	Obtaining IPv6 Address

   In order to obtain an IPv6 address, SC sends the assigned SAR a   
   Router Request message over UDP. The SAR replies with a Router
   Response containing the assigned IPv6 address; the message also
   contains a "Control Option" domain that specifies the IPv4 address
   and port number from which the SAR received the Router Request. In
   fact, when a Router Request arrives at the SAR, it may have passed
   through one or more NATs between the SC and the SAR. As a result, the
   source address of the request received by the SAR will be the mapped
   address created by the NAT closest to the SAR. The SAR copies that
   source IP address and port into the "Control Option" domain and sends
   it back to the source IP address and port of the Router Request.  For
   all of the NAT types mentioned above, this response will arrive at
   the SC.

   These packets will have the following format:

   +------+-----+----------------+
   | IPv4 | UDP | Router Request |
   +------+-----+----------------+

   +------+-----+----------------+-----------------+
   | IPv4 | UDP | Control Option | Router Response |
   +------+-----+----------------+-----------------+

   The IPv6 addresses assigned to SCs must be global IPv6 addresses
   belonging to the IPv6 addressing space managed by the SAR. These
   addresses could be assigned to the SC permanently. In this way,
   SC could preserve a permanent (static) IPv6 address even though its
   IPv4 address is dynamic.  

   Similarly, SCs can also request for temporary addresses. These
   addresses will be assigned a lifetime and removed after its
   expiration unless an explicit lifetime extension request is submitted
   by the SC. The lifetime of these IPv6 addresses should be
   relatively longer than the lifetime of the IPv4 connection of the
   SC.  This is to allow the SC to get semipermanent IPv6 addresses even
   though it is connected to the Internet with dynamically assigned
   IPv4 addresses through DHCP.
  
   Moreover, if the SC is an IPv6 router willing to provide IPv6
   connectivity to several hosts, it should provide some information
   about how many IPv6 addresses are required.  This allows the SAR to
   allocate the SC an IPv6 prefix that fits its address needs.

   Once a SAR has assigned an IPv6 address to a SC, this SAR will make
   an address binding in its mapping table, in which the assigned IPv6
   address is associated with the mapped IPv4 address and mapped port of
   the SC. Address binding MAY be dynamic with dynamic IPv4 address of


                       Expires November,2004                    [Page 9]

Internet-Draft    	      Silkroad              	       May 2004



   SCs. Once the binding between two addresses is in place, all
   subsequent sessions originating from or to this host will use the
   same binding for packet disposal. In addition, the SAR will maintain
   the management information about this UDP tunnel.

4.2.3	Determining the Type of NAT

   The previous section presented a simple address assignment procedure.
   When the SC receives the Router Response, it compares the IP address
   and port in Control Option with the local IP address and port it
   bound to when the request was sent.  If these do not match,the SC is
   behind one or more NATs; otherwise, the SC need not use the Silkroad
   service.

   For better transmission efficiency, the SC could choose to determine
   the type of NAT behind which it is located with the help of SAR. To
   determine that, the SC uses additional Router Requests. The procedure
   May generally work as in [5] (Of course, the exact implementation
   will be flexible).

4.2.4	Packet Transmission from a SC to a Regular IPv6 Node

   The exchange of packets between a SC and a regular IPv6 node is
   presented in the following figure, in which "A" is a SC located
   behind the NAT "N", "R1" is the SAR chosen by "A", "B" is a regular
   IPv6 node, and "R2" is a SAR close to "B" in the IPv6 Internet
   topology.

              UDP tunnel1     UDP tunnel2          
     +------+     |    +------+          +------+          +------+
     |      |     |    |      |          |      |          |      |
     |  A   |<-------->|  R1  |<-------->|  R2  |<-------->|   B  |
     |      |     |    |      |          |      |          |      |
     +------+     |    +------+          +------+          +------+
                  |             \      /      
                  N              \    /
                                  \  /
                                   \/
                                +------+ 
                                |      |                          
                                |  SN  |
                                |      |    
                                +------+     
     
     Figure 2: Packet transmission from a SC to a regular IPv6 node

   We assume that A has already gotten its IPv6 address from R1. And in
   this example, we do not consider any route optimization based on
   different NAT types. We also assume that the address of each entity
   is the following:


                       Expires November,2004                   [Page 10]

Internet-Draft    	      Silkroad              	       May 2004



   - A's private IPv4 address and port are: 1.0.0.1:1234
   - A's mapped IPv4 address and port are: 2.0.0.2:5678
   - A's IPv6 address is: 3ffe:8330:1::1234
   - R1's IPv4 address and port are: 3.0.0.3:5188
   - R2's IPv4 address and port are: 4.0.0.4:5188
   - B's IPv6 address is: 2001:250:f006:1::5678

   A wants to transmit an IPv6 packet to B. A's first action is to
   encapsulate this IPv6 packet in a UDP Datagram within IPv4, and send
   it from source address and port 1.0.0.1:1234, to the address of R1:
   3.0.0.3:5188. We call it Silkroad packet. This packet will have the
   following format:

   +------+-----+----------------+-------------+
   | IPv4 | UDP | Control Option | IPv6 packet |
   +------+-----+----------------+-------------+


   The packet is received by the NAT "N". N uses the existing mapping
   for 1.0.0.1:1234, and replaces the UDP source address and port by the
   mapped values 2.0.0.2:5678, before forwarding the packet.

   The packet is received over IPv4 UDP tunnel1 by R1. R1 takes out the
   IPv6 destination and checks the local route table to forward this
   packet. If R1 has direct tunnel to the destination IPv6 network or
   has direct access to the IPv6 Internet, R1 will find the route and
   forward this packet. If R1 has never forwarded an packet towards this
   IPv6 destination address and has no route information in its local
   route table, it will connect to SN to search the list of SARs that
   can forward IPv6 packets to the specific IPv6 network and get the
   IPv4 addresses of these SARs. The search process is like the disposal
   process of DNS (Domain Name System). The default route in SN will be
   a SAR connected to IPv6 Internet, that means if R1 can not find an
   appropriate SAR that can forward IPv6 packets to the specific IPv6
   address directly, this packet will be forwarded to IPv6 Internet and
   then follows IPv6 routing rules.

   After determining the address of R2, which is the SAR close to B in
   the IPv6 Internet topology. R1 will tunnel the IPv6 packet together
   with the Control Option to the address of R2: 4.0.0.4:5188. The
   transmission between R1 and R2 may follow different ways. It can
   manage IPv6 packet over another UDP tunnel, like UDP tunnel2 in
   Figure 2. The advantage of this method is that the disposal of R1
   before forwarding will be simple, just replacing the UDP source
   address and port by the values 3.0.0.3:5188 and replacing the UDP
   destination address and port by the values 4.0.0.4:5188. However, the
   price is a reasonable amount of overhead, due to UDP encapsulation.
   Silkroad can also send IPv6 packets between SARs as payload of IPv4
   packets just like traditional tunnels. But this method does not
   support Control Option between SARs. In this way, the packet will


                       Expires November,2004                   [Page 11]

Internet-Draft    	      Silkroad              	       May 2004



   have the following format:

   +-------------+-------------+------------------------+------+
   | IPv4 Header | IPv6 Header | Transport Layer Header | Data |
   +-------------+-------------+------------------------+------+

   Using this method, R1 must unencapsulate the packet and reencapsulate
   it before forwarding. Anyway, the SC can specify the transmission 
   method in Control Option domain. The default disposal is that when 
   there is Control Option in the packet, SAR will take UDP tunnel to
   forward it; otherwise, traditional tunnel will be used. In fact,
   Control Option generally only appears in the foremost several 
   packets in one session. As a result, SARs need to "listen" to both,
   UDP and IP encapsulation. But no matter what transmission method is
   token between SARs, SCs only need to support UDP encapsulation.
   
   The Control Option used to choose the transmission method between R1
   and R2 will be discarded by R1 after the corresponding disposal, that
   means R1 will not carry such a Control Option in the UDP packet
   forwarded to R2. Contrarily, other types of Control Option should be
   tunneled together with the IPv6 packet to R2.
   
   For simplification, in the following description, we assume SARs
   always take UDP tunnel to forward packets between each other.

   When R2 receives the packet, if it finds that B is a SC serviced by
   itself, it will follow the forwarding process in section 4.2.6.
   Otherwise, it will discard the IPv4 and UDP header and Control Option
   domain, and forward other content of the packet over IPv6 to the
   address of B: 2001:250:f006:1::5678. This packet will be received by
   B, and which will appear to come from A's address, 3ffe:8330:1::1234.
   
   Note that R1 and R2 may be the same SAR if it can reach both A and B.
   In this way, UDP tunnel2 may be elided.

4.2.5	Packet Transmission from a Regular IPv6 Node to a SC

   The exchange of packets between a regular IPv6 node and a SC is
   presented in the following figure, in which "A" is a SC located
   behind the NAT "N", "R1" is the SAR chosen by "A", "B" is a regular
   IPv6 node, and "R2" is a SAR close to "B" in the IPv6 Internet
   topology.










                       Expires November,2004                   [Page 12]

Internet-Draft    	      Silkroad              	       May 2004



                               UDP tunnel2      UDP tunnel1
     +------+          +------+          +------+    |     +------+
     |      |          |      |          |      |    |     |      |
     |  B   |<-------->|  R2  |<-------->|  R1  |<-------->|   A  |
     |      |          |      |          |      |    |     |      |
     +------+          +------+          +------+    |     +------+
                                \      /             |
                                 \    /              N
                                  \  /
                                   \/
                                +------+ 
                                |      |                          
                                |  SN  |
                                |      |    
                                +------+     
     
     Figure 3: Packet transmission from a regular IPv6 node to a SC

   We assume that A has already gotten its IPv6 address from R1. And in
   this example, we do not consider any route optimization based on
   different NAT types. We also assume that the address of each entity
   is the following:

   - A's private IPv4 address and port are: 1.0.0.1:1234
   - A's mapped IPv4 address and port are: 2.0.0.2:5678
   - A's IPv6 address is: 3ffe:8330:1::1234
   - R1's IPv4 address and port are: 3.0.0.3:5188
   - R2's IPv4 address and port are: 4.0.0.4:5188
   - B's IPv6 address is: 2001:250:f006:1::5678

   When B wants to transmit an IPv6 packet to A, B simply follows IPv6
   rules. The packet will be forwarded to one SAR close to B in the IPv6
   Internet topology, R2, over IPv6. R2 will takes out the IPv6
   destination address and checks local route table to forward this
   packet. If R2 has no route information in its local route table, it
   will connect to SN to search the IPv4 address of the SAR that can
   forward IPv6 packets to the specific IPv6 address. Because the IPv6
   address assigned to A is a global IPv6 addresses belonging to the
   IPv6 addressing space managed by R1. R2 will get the IPv4 address of
   R1 in the search process. Then R2 will encapsulate the packet and
   send it to the address of R1: 3.0.0.3:5188.

   The packet is received over IPv4 UDP tunnel2 by R1. R1 will find that
   the IPv6 destination address is belonging to its address space. Thus
   it will check the address binding in its mapping table, in which it
   will find that the IPv6 address 3ffe:8330:1::1234 is associated with
   A's mapped IPv4 address and port: 2.0.0.2:5678. Thus R1 will replace
   the UDP source address and port by the values 3.0.0.3:5188 and
   replace the UDP destination address and port by the values
   2.0.0.2:5678, then forward the packet in UDP tunnel1.


                       Expires November,2004                   [Page 13]

Internet-Draft    	      Silkroad              	       May 2004



   The NAT "N" will receive this message. It will use the existing
   mapping to rewrite 2.0.0.2:5678 to 1.0.0.1:1234, and forward the
   packet to A. Then the packet will be received over IPv4 UDP tunnel1
   by A.

   Note that R1 and R2 may be the same SAR if it can reach both A and B.
   In this way, UDP tunnel2 may be elided.

4.2.6	Exchanges Between Two Silkroad Clients

   The following figure shows two SCs,"A" and "B", connected through the 
   NATs "N1" and "N2". "R1" is the SAR chosen by "A" and "R2" is the SAR  
   chosen by "B".

             UDP tunnel1       UDP tunnel2      UDP tunnel3
     +------+    |     +------+          +------+    |     +------+
     |      |    |     |      |          |      |    |     |      |
     |  A   |<-------->|  R1  |<-------->|  R2  |<-------->|   B  |
     |      |    |     |      |          |      |    |     |      |
     +------+    |     +------+          +------+    |     +------+
                 |              \      /             |
                 N1              \    /              N2
                                  \  /
                                   \/
                                +------+   
                                |      |                            
                                |  SN  | 
                                |      |      
                                +------+       
     
          Figure 4: Packet transmission between two SCs

   We assume that A and B have already gotten their IPv6 addresses from
   R1 and R2 respectively. And in this example, we do not consider any
   route optimization based on different NAT types. We also assume that
   the address of each entity is the following:

   - A's private IPv4 address and port are: 1.0.0.1:1234
   - A's mapped IPv4 address and port are: 2.0.0.2:5678
   - A's IPv6 address is: 3ffe:8330:1::1234
   - R1's IPv4 address and port are: 3.0.0.3:5188
   - R2's IPv4 address and port are: 4.0.0.4:5188
   - B's private IPv4 address and port are: 5.0.0.5:1234
   - B's mapped IPv4 address and port are: 6.0.0.6:5678
   - B's IPv6 address is: 2001:250:f006:1::5678

   A has learnt B's address, for example from the DNS, and starts
   communication with B. The data packets will be sent from A's IPv6  
   address (3ffe:8330:1::1234) to B's IPv6 address
   (2001:250:f006:1::5678). The transmission process from A to R2 is the


                       Expires November,2004                   [Page 14]

Internet-Draft    	      Silkroad              	       May 2004



   same as explained in section 4.2.4.

   When R2 receives the packet over IPv4 UDP tunnel2, it will find that
   B is a SC serviced by itself, and the address binding in its mapping
   table shows that the IPv6 destination address 2001:250:f006:1::5678
   is associated with B's mapped IPv4 address and port: 6.0.0.6:5678.
   Thus R2 will replace the UDP source address and port by the values
   4.0.0.4:5188 and replace the UDP destination address and port by the
   values 6.0.0.6:5678, then forward the packet in UDP tunnel3.

   The NAT "N2" will receive this message. It will use the existing
   mapping to rewrite 6.0.0.6:5678 to 5.0.0.5:1234, and forward the
   packet to B. Then the packet will be received over IPv4 UDP tunnel3
   by B.

   Note that R1 and R2 may be the same SAR if it can reach both A and B.
   In this way, UDP tunnel2 may be elided.

4.3	Deployment Model

   As we all know, public IPv4 addresses is a scarce resource,
   especially for the mobile operators. As a result, NAT devices are
   widely deployed to connect a realm with private unregistered
   addresses to a realm with globally unique registered addresses.
   However, traditional tunneling methods do not work when the IPv6
   candidate is located behind some NAT device. Silkroad is designed to
   enable IPv6 traffic through NATs.
   
   There are many scenarios that need Silkroad deployment. For example, 
   although the user equipments can be dual stack, current existing GPRS
   operators already have IPv4 backbone networks deployed. What have
   been currently deployed in commercial networks are Mobile IPv4 and
   Simple IPv4 modes. A majority of current existing commercial networks
   only support IPv4 in the Serving GPRS Support Node (SGSN), the
   Gateway GPRS Support Node (GGSN) and the Home Location Register(HLR).
   In addition, the GGSN usually allocates private IPv4 addresses to
   user equipments. In this way, the GGSN acts as a NAT. Then how can
   the dual stack user equipment with a private IPv4 address access the
   IPv6 Internet through IPv4 GPRS backbone? Before the ISPs deploy 
   basic IPv6 support by making upgrades in their network elements, they
   can take Silkroad service to provide early easy access to IPv6
   networks.
    
   The deployment model of Silkroad makes two assumptions:

   - That all Silkroad clients and Silkroad access routers will be
   cognizant of the Silkroad port;

   - That all Silkroad clients and Silkroad access routers will know the
   IPv4 address of the Silkroad navigator.


                       Expires November,2004                   [Page 15]

Internet-Draft    	      Silkroad              	       May 2004



4.3.1	Silkroad Access Router Deployment

   In the simplest case, when the Silkroad clients are very few, one SAR
   may be enough, only if the SAR has connected to IPv6 Internet. Every
   time the SAR receives the IPv6 packet encapsulated in a UDP Datagram
   from a SC and the IPv6 destination address is also belonging to its
   address space, it will check the address binding in its mapping table
   and forward the packet in UDP tunnel. Otherwise, it will discard the
   IPv4 and UDP header, and forward the content of the packet over IPv6.
   In this case, the destination address must be connected to IPv6 
   Internet. Otherwise, the SAR must have direct tunnel to the specific 
   IPv6 network. Contrarily, every time the SAR receives an IPv6 packet
   to its client, it will encapsulate it in a UDP Datagram and forward
   it to the corresponding SC. In the simplest instance, even the SN can
   be omitted.

   However, in the emerging IPv6 Internet, it is expected that many
   users will need to access IPv6 by the current Internet with the large
   installed base of IPv4 hosts and routers. Thus it is impossible to
   provide Silkroad service to all these hosts only by one SAR. What's
   more, many destination nodes may not connect to IPv6 Internet and the
   only SAR can not have direct tunnels to all destination IPv6
   networks.

   Consequently, it is expected that many Silkroad access routers will
   be available so that the user will just have to pick the appropriate
   one. There will be at least one SAR connected to IPv6 Internet. All
   SARs could configure static routes between each other with the help
   of SN. 

   Silkroad access routers may be deployed either as part of an ISP, 
   or as an enabler for an application that requires direct IPv6
   communication between client hosts. SARs are expected to perform some
   amount of access control. 

4.3.2	Silkroad Navigator Deployment

   In the simplest case, when the Silkroad clients and Silkroad access
   routers are very few, there is no need to configure Silkroad
   navigator. However, when the scale of Silkroad service is relatively
   large, it may be necessary to configure Silkroad navigator to help 
   Silkroad clients to choose appropriate SAR and to help SARs to route 
   between each other.

   The only deployment requirement for Silkroad navigator is IPv4
   connectivity. It may also be IPv6 addressable, but this is not
   mandatory.

   In the initial deployment of the Silkroad service, we expect to find
   a globally accessible Silkroad navigator. However, along with the


                       Expires November,2004                   [Page 16]

Internet-Draft    	      Silkroad              	       May 2004



   increase in the size of the route database in SN and frequency of
   updates, it may demand a distributed manner with local caching to
   improve performance. But at this time, it is recommended to offer
   native IPv6 instead of deploying many SNs. In fact, when all SARs
   have easy access to IPv6 Internet, SN could be omitted.















































                       Expires November,2004                   [Page 17]

Internet-Draft    	      Silkroad              	       May 2004



5	Route Optimization


   For better transmission efficiency, we can do some route optimization
   in certain scenarios. Route optimization is optional.

5.1	Exchanges Between Two Silkroad Clients

   As described in 4.2.6, Figure 5 shows two SCs,"A" and "B", connected
   through the NATs "N1" and "N2". "R1" is the SAR chosen by "A" and
   "R2" is the SAR chosen by "B". As we have mentioned above, R1 and R2
   may be the same SAR if it can reach both A and B. In this way, UDP
   tunnel2 may be elided.

                          direct communication      
        +------------------------------------------------------+
        |+----------------------------------------------------+|
        ||                                                    ||
        ||                                                    ||
        \/   UDP tunnel1       UDP tunnel2      UDP tunnel3   \/
     +------+    |     +------+          +------+    |     +------+
     |      |    |     |      |          |      |    |     |      |
     |  A   |<-------->|  R1  |<-------->|  R2  |<-------->|   B  |
     |      |    |     |      |          |      |    |     |      |
     +------+    |     +------+          +------+    |     +------+
                 |              \      /             |
                 N1              \    /              N2
                                  \  /
                                   \/
                                +------+ 
                                |      |                          
                                |  SN  |
                                |      |    
                                +------+

                   Figure 5: Exchanges between two SCs
    
   In fact, A and B can communicate with each other directly, unless N1
   and N2 are both Symmetric NAT. Of course, they need the help of R1
   and R2 to exchange some parameters at first.

   Assume that A wants to communicate with B. Firstly, A should obtain
   an IPv6 address from R1 as described in section 4.2.2. When A
   receives the Router Response from R1, it compares the IP address
   and port in Control Option with the local IP address and port it
   bound to when the request was sent. If these do not match, A knows
   that it is behind one or more NATs; otherwise, A need not use the
   Silkroad service and can choose other tunnel technologies.

   For better transmission efficiency, A could choose to determine the


                       Expires November,2004                   [Page 18]

Internet-Draft    	      Silkroad              	       May 2004



   type of NAT behind which it is located with the help of R1. To
   determine that, A uses additional Router Requests as described in
   4.2.3. Then A will include its mapped address and mapped port
   together with its type of NAT in the Control Option in the first
   encapsulated packet to B. If both N1 and N2 are Full Cone NAT, B will
   reply IPv6 packets encapsulated in UDP directly to A, with Control
   Option indicating its mapped address and mapped port. Then A and B
   will communicate with each other directly through UDP tunnel. If both
   N1 and N2 are Symmetric NAT, A and B can not transmit packets to each
   other without the help of SAR. In other case, A and B must generate
   some control packets to establish corresponding mapping at the
   Restricted Cone NAT/Port Restricted Cone NAT/Symmetric NAT before
   they can transmit packets directly to each other. In this case, it is
   recommended that A and B choose to do route optimization only if they
   want to transmit large bulk traffic. If they only want to transmit a
   few of messages, there is no need to send control packets to make
   route optimization.
  
   If B is a regular IPv6 node, the Control Option domain in the first
   encapsulated packet to B will be discarded by R2. Thus no route
   optimization will be made.
  
5.2	Exchanges Between Two Silkroad Clients on the Same Link

   The following figure shows two Silkroad Clients, A and B, connected
   to the same link, which is connected to the Internet through the NAT
   N1. The exchanges between A and B will use the SAR,R1. We are not
   making any assumption about the type of N1. This scenario explains
   how the exchanges between clients on the same link can be optimized
   to avoid routing all packets through R1 and N1.






















                       Expires November,2004                   [Page 19]

Internet-Draft    	      Silkroad              	       May 2004



                              +------+
                              |      |
                 +----------->|  R1  |<-----------+
                 |            |      |            |
                 |            +------+            |
                 |               |                |
                 |               |                |
                 |               |                |
    UDP tunnel1  |               |                |  UDP tunnel2
                 |            +------+            |
                 |            |      |            |   
                 |            |  N1  |            |
                 |            |      |            |   
                 |            +------+            |
                 |             /    \             |
                 |            /      \            |           
                 |           /        \           |
                 |          /          \          |
                 |   +------+          +------+   |
                 |   |      |          |      |   |
                 +-->|   A  |<-------->|   B  |<--+
                     |      |          |      |
                     +------+          +------+
                        direct communication

     Figure 6: Packet transmission between two SCs on the same link

   We assume that A and B have already gotten their IPv6 addresses from
   R1 respectively. We also assume that the address of each entity is
   the following:

   - A's private IPv4 address and port are: 1.0.0.1:1234
   - A's mapped IPv4 address and port are: 2.0.0.1:5678
   - A's IPv6 address is: 3ffe:8330:1::1234
   - R1's IPv4 address and port are: 3.0.0.3:5188
   - B's private IPv4 address and port are: 1.0.0.2:3456
   - B's mapped IPv4 address and port are: 2.0.0.2:5678
   - B's IPv6 address is: 3ffe:8330:1::5678

   Of course, A and B are possibly located behind the same NAT, if they
   are both using the same mapped IPv4 address. However, even if the
   mapped IPv4 addresses are different, they are also possibly located
   behind the same NAT. On the other hand, even if they are behind the
   same NAT, it is possible that they can not communicate with each
   other directly. Thus they have to take some actions to confirm that
   they are directly reachable.

   There are several ways to gain this end. Here we only give a viable
   alternative to implement it.



                       Expires November,2004                   [Page 20]

Internet-Draft    	      Silkroad              	       May 2004



   If A wants to discover whether it and B are on the same link, it can
   include its private address in the Control Option in the packet
   sent to B through N1 and R1. When B receives this packet, it will
   reply encapsulated packets including its private address to R1's
   address (3.0.0.3:5188) and A's private address (1.0.0.1:1234)
   simultaneously. If A receives both packets, it will confirm that it
   and B are on the same link and they are directly reachable. Then the
   packets will be sent directly on the local link, avoiding the loop
   through R1 and N1.











































                       Expires November,2004                   [Page 21]

Internet-Draft    	      Silkroad              	       May 2004



6	Message Formats

   As mentioned in 4.2, the message type can be Router Solicitation, 
   Router Advertisement, Router Request, Router Response, or Silkroad 
   packet.

   In this section, we will introduce Silkroad packet in details. The
   main intention is to explain how the Control Option can be used to
   optimize routes and make individual choices.

   Silkroad packets are transmitted as the payload of UDP packets [3]
   within IPv4 [4]. In order to control and optimize the transmission,
   Control Option may be inserted in the first bytes of the UDP payload:

   +------+-----+----------------+-------------+
   | IPv4 | UDP | Control Option | IPv6 packet |
   +------+-----+----------------+-------------+

   The Control Option encapsulation is a variable length-element, with
   the following format:

         0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                 |                       |     |
   |    Option Type  |      Option Length    |flag |
   |                 |                       |     |
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |                                               |
   |                 Option Content                |
   |                                               |
   +-----+-----+-----+-----+-----+-----+-----+-----+

   Option Type is 3 bits, which indicates the content type of this
   option. We have already defined 5 types as follows:   

          111 - Mapped address and port
          110 - private address and port
          101 - Type of NAT
          100 - Transmission method
          011 - The control option is empty
          010 - unused
          001 - unused
          000 - unused
   
    Option Length is 4 bits, which indicates the length of this option
    content in unit of byte.

    The 1 bit flag is used to indicate whether there are other options
    following this option in this packet. It means the Control Option
    domain in one packet could carry more than one type of option.


                       Expires November,2004                   [Page 22]

Internet-Draft    	      Silkroad              	       May 2004



7	Other Issues of the Solution

7.1	Lifetime of NAT Mappings

   Regardless of their types, NAT mappings are not kept forever.
   Generally, if no traffic is observed on the specified port for a
   "lifetime" period, the corresponding mapping will be removed. The
   Silkroad client that wants to maintain a mapping open in the NAT will
   have to send some "keep alive" traffic before the lifetime expires.
   

7.2	Lifetime of Silkroad Tunnel

   As mentioned in 4.2.2, IPv6 addresses can be assigned to the SC
   permanently. In this way, SC could preserve a permanent (static) IPv6
   address even though its IPv4 address is dynamic. Similarly, SC can
   also request for temporary addresses. The lifetime of these temporary
   IPv6 addresses should be relatively longer than the lifetime of the
   IPv4 connection of the SC.
  
   In addition, there should be keep-alive mechanism on SARs.In this
   case, if no "refresh" traffic is observed on the assigned address for
   a duration that exceeds a refresh interval, the Silkroad tunnel will
   be canceled and the address binding will be removed.
   
7.3	Silkroad in the Post Era of IPv6

   In the post era of IPv6, when IPv4 hosts are just small isolated
   sites on the IPv6 Internet. The disposal of SARs will be simpler.
   Every time one SAR receives the IPv6 packet encapsulated in a UDP
   Datagram from a SC, it will discard the IPv4 and UDP header, and
   forward the content of the packet over IPv6. Then the packet
   transmission will follow IPv6 rules. Contrarily, every time the SAR
   receives an IPv6 packet to its client, it will encapsulate it in a
   UDP Datagram and forward it to the corresponding SC. In this
   instance, SN can be omitted.

   
7.4	Difference between Silkroad and Teredo

   A service, called Teredo[6], has been presented to enable nodes
   located behind IPv4 NATs to obtain IPv6 connectivity with the help of
   "Teredo servers" and "Teredo relays". Teredo addresses need special
   IPv6 addressing prefix. What's more, in order to minimize the
   fraction of traffic that has to be routed through the servers, the
   Teredo addresses will incorporate the IPv4 address and UDP port
   through which a Teredo client can be reached. This creates an
   implicit limit on the stability of the Teredo addresses, which can
   only remain valid as long as the underlying IPv4 address and UDP port
   remains valid. In fact, although Teredo can minimize the fraction of


                       Expires November,2004                   [Page 23]

Internet-Draft    	      Silkroad              	       May 2004



   traffic routing through the servers, it need Teredo relays in every
   IPv6 network to receive traffic destined to Teredo clients and 
   forward it using the Teredo service, which needs to update the 
   existing infrastructure. In addition, Teredo does not provide
   connectivity for clients located behind a symmetric NAT, which is 
   common in large enterprises.
   
   Silkroad is also a tunnel service to enable nodes located behind IPv4 
   NAT devices to obtain IPv6 connectivity over IPv4 UDP. However,it can
   provide connectivity for clients located behind all existing NAT
   types, including symmetric NAT. Moreover, Silkroad does not need
   special IPv6 addressing prefix and can provide the users with
   permanent IPv6 address. Silkroad has no special requirement for
   infrastructure and easy to deploy in existing network. Of course, the
   route optimization May be more complicated in Silkroad than in
   Teredo, because there is no information about the IPv4 address and
   UDP port through which a Silkroad client can be reached in its IPv6
   address.


































                       Expires November,2004                   [Page 24]

Internet-Draft    	      Silkroad              	       May 2004



8	Security Consideration

   All the interactions between the functional elements of the Silkroad
   model need to be secured. The security techniques adopted for each of
   these interactions are dependent on the concrete implementation.

   For the interaction between SN and SAR, secure SNMP could be adopted
   [7,8,9]. In addition, if a simpler approach based on RSH commands is
   used, standard IPsec mechanisms can be applied [10].

   For the interaction between SC and SAR, a loss of confidentiality may
   occur whenever a SC disconnects from the Internet without tearing
   down the tunnel previously established through the SAR.  As a result,
   the SAR will keep tunneling the IPv6 traffic addressed to that user
   to its old IPv4 address. However, the fact may be that this IPv4
   address has already been dynamically assigned to another user.  This
   problem could be solved by implementing on every tunnel the 
   keep-alive mechanism as mentioned in section 7.2. In this way, the
   SAR will immediately stop IPv6 traffic forwarding towards
   disconnected users.

   On the other hand, the SC must ensure that the Silkroad tunnels that
   it uses remain valid. It does so by checking that packets are
   regularly received from the SAR.

   What's more, the SAR must implement protections against denial of
   service attacks which may occur whenever a malicious user exhausts
   all the resources available on the SAR and spoofs a SAR and sends
   improper information to the client.

9       IANA Considerations

   This memo requests an allocation of a "privileged" UDP port (TBD).  

10      Acknowledgments

   The authors would like to thank Li Zhongcheng, Shi Jinglin and Ma 
   Jian for their comments, and Zhang Tianle for initial 
   implementations.













                       Expires November,2004                   [Page 25]

Internet-Draft    	      Silkroad              	       May 2004



Normative References

   [1] P. Srisuresh and K. Egevang, "Traditional IP Network Address
   Translator (Traditional NAT)", RFC3022, Jan 2001.
      
   [2] P. Srisuresh and M. Holdrege, "IP Network Address Translator
   (NAT) Terminology and Considerations", RFC2663, Aug 1999.
   
   [3] J. Postel, "User Datagram Protocol", RFC 768, August 1980.
   
   [4] J. Postel, "Internet Protocol", RFC 791, September 1981.

Informative References

   [5] J. Rosenberg, J. Weinberger, C. Huitema and R. Mahy, "STUN -
   Simple Traversal of User Datagram Protocol (UDP) Through Network
   Address Translators (NATs)", RFC 3489, March 2003.
   
   [6] C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs", 
   draft-huitema-v6ops-teredo-01.txt (Work in Progress), February 2004.

   [7] B. Wijnen, D. Harrington and R. Presuhn, "An Architecture for
   Describing SNMP Management Frameworks", RFC 2571, April 1999.

   [8] U. Blumenthal and B. Wijnen, "User-based Security Model (USM)
   for version 3 of the Simple Network Management Protocol (SNMPv3)",
   RFC 2574, April 1999.

   [9] B. Wijnen, R. Presuhn and K. McCloghrie, "View-based Access
   Control Model (VACM) for the Simple Network Management Protocol
   (SNMP)", RFC 2575, April 1999.

   [10] S. Kent and R. Atkinson, "Security Architecture for the
   Internet Protocol", RFC 2401, November 1998.
   
   [11] A. Durand, P. Fasano, I. Guardini and D. Lento, "IPv6 Tunnel
   Broker", RFC 3053, January 2001.
         

                       Expires November,2004                   [Page 26]

Internet-Draft    	      Silkroad              	       May 2004



Authors' Addresses

   Liu Min
   Institute of Computing Technology
   Chinese Academy of Sciences
   Box 2704, Beijing, 100080 PRC	
   Email: liumin@ict.ac.cn

   Wu Xianguo
   Institute of Computing Technology
   Chinese Academy of Sciences
   Box 2704, Beijing, 100080 PRC	
   Email: xgwu@ict.ac.cn
   
   Cai Yibing
   Institute of Computing Technology
   Chinese Academy of Sciences
   Box 2704, Beijing, 100080 PRC	
   Email: cyb@ict.ac.cn
   
   Jin Mingye
   China Unicom
   No.133A, Xidan North Street, Xicheng
   Beijing,100032 PRC
   Emailú¦jinmy@chinaunicom.com.cn
   
   Li Defeng
   HUAWEI Technologies Co., LTD.
   Hua Wei Bld., No.3 Xinxi Rd.,
   Shang-Di Information Industry Base,
   Hai-Dian District, Beijing, 100085 PRC
   Email: 77cronux.leed0621@huawei.com

   
Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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.
   
                       Expires November,2004                   [Page 27]