Internet Engineering Task Force                                    Y. Li
INTERNET DRAFT                                        Bay Networks, Inc.
                                                               W. T. Teo
                                                     National University
                                                            of Singapore
                                                         18 January 1998

               IP Private Address Identification (PAID)
                  draft-yliteo-mobileip-paid-00.txt


Status of this Memo

   This document is a submission to the Mobile-IP Working Group of the
   Internet Engineering Task Force (IETF). Comments should be submitted
   to the mobile-ip@smallworks.com mailing list.

   Distribution of this memo is unlimited.

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

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   This memo proposes a scheme to conserve the IPv4 address space by
   allowing to allocate private instead of public IP addresses for its
   internet hosts. These internet hosts can achieve complete internet
   connectivity between any domains with each private host globally
   identified as a <public, private> address pair. To enable private
   hosts to communicate using these address pairs efficiently, we
   propose a PAID Encapsulation protocol. To acquire a <public, private>
   address pair, we specify a variant registration method derived from
   Mobile IP, using a PAID Registration Request and PAID Registration
   Reply. This approach requires modifications to network sockets and
   enhancements to the domain name system.


Li, Teo                 Expires 17 July 1998                    [Page i]


Internet Draft    IP Private Address Identification      18 January 1998


1. Introduction

   Many enterprises are employing network applications based on the IP
   platform due to the widespread availability of such software. With
   the current exponential growth of Internet hosts, the IPv4 address
   space is rapidly being depleted. Enterprises can however utilize
   private (in contrast to public) IP addresses to run their network
   applications. But private addresses due to their nature restrict the
   network spans to within the enterprises themselves.

   The inaccessibility of private networks with foreign domains is
   because the destination IP address of a datagram generally determines
   the routing path taken. As a private address is not globally unique,
   traffic destined to a private node from beyond the private network
   will be undeliverable.

   To allow a private node access to a foreign host, the IP network
   address translator (NAT [6]) provides a means to convert between
   private addresses and public addresses. However, there are a number
   of limitations to this approach: it requires a sparse end-to-end
   traffic matrix; it increases the probability of mis-addressing; it
   breaks certain applications; it hides the identity of communicating
   hosts.

   Morever, it is not possible for foreign hosts to access a private
   host without the use of application gateways. These methods generally
   requires tunneling, both the routing domains to be known beforehand,
   the private IP addresses between the communicating domains to be
   unique or static configurations at the application gateways to
   deliver the traffic to the private host.

   This document proposes that a private node register its own address
   with a public node. This latter will receive traffic from a public
   IP tunnel over the Internet on behalf of the private node and then
   forward the traffic to the node. Therefore, this <public, private>
   address pair is taken as the identification (PAID) of the private
   node over the global Internet. The public node is called PAID agent.

   To efficiently identify the PAID sources and PAID destination in
   datagrams between private hosts, the document proposes a PAID
   Encapsulation protocol. This encapsulation method also reduces the
   overhead in multiple encapsulations.

   To locate a PAID agent, we specify a PAID agent discovery protocol.
   To acquire a <public, private> address pair, we derive a new variant
   registration method from Mobile IP [1], using a PAID Registration
   Request and PAID Registration Reply. With the registration, a private
   node is able to automatically acquire a global identification.



Li, Teo                 Expires 17 July 1998                    [Page 1]


Internet Draft    IP Private Address Identification      18 January 1998


   Private nodes that only require access to foreign servers but do not
   provide service to foreign clients can continue to employ NAT [6] to
   access domains that do not support PAID. Therefore, internet
   connectivity of the private hosts can expand with PAID deployment
   without sacrificing an organization's access to internet resources.

   The primary advantage in the PAID approach is that all private hosts
   in a domain can be accessed by public or private nodes in other
   domains, and even hosts in different domains but with the same
   private address can communicate with each other. Additionally, PAID
   provides an easy migration path to enable internet connectivity for
   private intranets or the formation of extranets, without the need to
   renumber the network machines.

   Many other benefits can be gained from using private addresses that
   are not allocated by a central registration body. An organization has
   more flexibilty during network deployment and expansion using the
   large number of private addresses available.

   The disadvantage with this approach is that, network applications
   have to be modified, and the domain name system has to be enhanced.

2. Applicability


 =============== WAN ============== Public Internet ======= WAN =======
                . | . . . . . . . . . . .|. . . . . . . . . .| .
       Public   . |            ..........|...................|..........
    192.32.174.44 |            :200.9.1.1| Public   200.9.2.1| .       :
     . . . . .+---------+      :    +----+---+        +------+------+  :
     .+-------| ISP Rtr |--+   :    |Router A|        |   Router B  |  :
     .|       +-+-----+-+  |   :    +----+---+        +--+---+---+--+  :
     .|         |     |    |   :         |               |   | . |     :
     .|         |     |    |   :         |               |   | . |     :
............. ...............  :   .............      ...............  :
:    .      : :             :  :   :           :      :        .    :  :
:  Private  : :   Private   :  :   :  Private  :      :   Private   :  :
:  Network  : :   Network   :  :   :  Network  :      :   Network   :  :
:192.168.0.0: :  10.0.0.0   :  :   :192.168.0.0:      :  10.0.0.0   :  :
:255.255.0.0: :  255.0.0.0  :  :   :255.255.0.0:      :  255.0.0.0  :  :
:           : :             :  :   :           :      :             :  :
:  256x256  : : 256x256x256 :  :   : 256x256   :      : 256x256x256 :  :
: addresses : :  addresses  :  :   : addresses :      :  addresses  :  :
:...........: :.............:  :   :...........:      :.............:  :
                               :                                       :
                               :   Enterprise Virtual Private Network  :
                               :                (VPN)                  :
                               :.......................................:

       Figure 1  Private Nodes Communicate with Each Other Using PAID

Li, Teo                 Expires 17 July 1998                    [Page 2]


Internet Draft    IP Private Address Identification      18 January 1998


   Private Address Identification (PAID) is intended to enable private
   nodes to communicate globally. For example, a private host in an ISP
   network is able to access a public or private HTTP server in an
   enterprise network, and a public or private host outside an ISP
   network can access a private HTTP server in the ISP network.

   Figure 1 is a typical network deployment over the Internet.

   For example, a private host 10.10.10.10 in the ISP network can talk
   to a private host 10.20.20.20 in the enterprise VPN by using an ISP
   address pair <192.32.174.44, 10.10.10.10> and an enterprise address
   pair <200.9.2.1, 10.20.20.20>. To enable this functionality, these
   two private hosts should use PAID encapsulation and decapsulation.
   Also, the ISP router, router A and router B should support the PAID
   encapsulation protocol. All other routers will remain with running
   conventional routing protocols.



































Li, Teo                 Expires 17 July 1998                    [Page 3]


Internet Draft    IP Private Address Identification      18 January 1998


2. Terminology and Definitions

2.1 Private Node

   A node where all its interface addresses are private as specified in
   RFC 1918 [9].

2.2 Public Node

   A node which has at least one public interface address. The public
   address is in contrast to the private address [9].

2.3 Identification of Private Address (PAID)

   A private node, when attempting to enable global communication, can
   register its own address with a public node. The <public, private>
   address pair is called the identification of the private node, or
   PAID for short, over the global Internet.

   In Figure 1, <192.32.174.44, 10.10.10.10> is a PAID of the private
   host 10.10.10.10 in the ISP network, and <200.9.2.1, 10.20.20.20> is
   a PAID of the private host 10.20.20.20 in the enterprise VPN.

2.4 PAID Agent

   A PAID agent is a node that provides private nodes with the public
   portion of the identifications for the private nodes. It will tunnel
   traffic between a private node in the same domain and a node in
   another domain.

   In Figure 1, the ISP router is a PAID agent for the private host
   10.10.10.10 in the ISP network, and the router B is a PAID agent for
   the private host 10.20.20.20 in the enterprise VPN.

   From the standpoint of routing and security, the PAID agent should be
   chosen from domain border routers or backbone routers.

2.5 PAID Agent Address

   A PAID agent address is referred to as an interface address that is
   public.










Li, Teo                 Expires 17 July 1998                    [Page 4]


Internet Draft    IP Private Address Identification      18 January 1998


3. PAID Encapsulation Protocol

   Encapsulation is suggested as a means to alter the normal IP routing
   for datagrams, by delivering them to an intermediate destination that
   would otherwise not be selected by the (network part of the) IP
   Destination Address field in the original IP header.

   The process of encapsulation and decapsulation of a datagram is
   frequently referred to as "tunneling" the datagram, and the
   encapsulator and decapsulator are then considered to be the
   "endpoints" of the tunnel; the encapsulator node is referred to as
   the "entry point" of the tunnel, and the decapsulator node is
   referred to as the "exit point" of the tunnel.

   The Minimal Encapsulation for IP [3] is an encapsulation mechanism
   that eliminates unnecessary duplication required by other
   encapsulation mechanisms, such as IP Encapsulation within IP [2] and
   Generic Routing Encapsulation [8]. However, the minimal encapsulation
   does not really save any space for PAID. Also, with the existing
   encapsulation mechanisms, it is difficult to identify the private
   source, public source, private destination and public destination
   from a received packet.

3.1 PAID Encapsulation

   A PAID forwarding header is defined for datagrams to be originated.
   PAID encapsulation must not be used when an original datagram is
   already fragmented, since there is no room in the PAID forwarding
   header to store fragmentation information.  To encapsulate an IP
   datagram using PAID encapsulation, the PAID forwarding header is
   inserted into the datagram, as follows:


   +---------------------------+       +---------------------------+
   |                           |       |                           |
   |         IP Header         |       |     Modified IP Header    |
   |                           |       |                           |
   +---------------------------+ ====> +---------------------------+
   |                           |       |   PAID Forwarding Header  |
   |                           |       +---------------------------+
   |         IP Payload        |       |                           |
   |                           |       |                           |
   |                           |       |         IP Payload        |
   +---------------------------+       |                           |
                                       |                           |
                                       +---------------------------+





Li, Teo                 Expires 17 July 1998                    [Page 5]


Internet Draft    IP Private Address Identification      18 January 1998


   The IP header of the original datagram is modified, and the PAID
   forwarding header is inserted into the datagram after the IP header,
   followed by the unmodified IP payload of the original datagram (e.g.,
   transport header and transport data).  No additional IP header is
   added to the datagram.

   In encapsulating the datagram, the original IP header [5] is modified
   as follows:

    -  The Protocol field in the IP header is replaced by protocol
       number 56 for the PAID encapsulation protocol.

    -  The Destination Address field in the IP header is replaced by the
       IP address of the exit point of the tunnel.

    -  If the encapsulator is not the original source of the datagram,
       the Source Address field in the IP header is replaced by the IP
       address of the encapsulator.

    -  The Total Length field in the IP header is incremented by the
       size of the PAID forwarding header added to the datagram.

    -  The Header Checksum field in the IP header is recomputed [5] or
       updated to account for the changes in the IP header described
       here for encapsulation.

   Note that like minimal encapsulation, the Time to Live (TTL) field
   in the IP header is not modified during encapsulation; since this
   encapsulation is performed at the datagram origination, the
   encapsulator will not decrement the TTL.

3.2 Format of PAID Forwarding Header

   The format of the PAID forwarding header is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Protocol    |D|S|  Reserved |        Header Checksum        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Public Destination Address                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Public source Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :            (if present) Private Destination Address           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :              (if present) Private Source Address              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Li, Teo                 Expires 17 July 1998                    [Page 6]


Internet Draft    IP Private Address Identification      18 January 1998


      Protocol

         Copied from the Protocol field in the original IP header.

      D bit

         If set, the private destination PAID is present.

      S bit

         If set, the private source PAID is present.

      Reserved

         Sent as zero; ignored on reception.

      Header Checksum

         The 16-bit one's complement of the one's complement sum of all
         16-bit words in the PAID forwarding header.  For purposes of
         computing the checksum, the value of the checksum field is 0.
         The IP header and IP payload (after the PAID forwarding header)
         are not included in this checksum computation.

      Public Destination Address

         The address of a public destination node, or the PAID agent
         address of a private destination node. In the case of public
         destination node, this is the original destination address.

      Public source Address

         The address of a public source node, or the PAID agent address
         of a private source node. In the case of public source node,
         this is the original source address.

      Private Destination Address

         If present, the address of a private destination node. In the
         case of private destination node, this is the original
         destination address.

      Private Source Address

         If present, the address of a private source node. In the case
         of private source node, this is the original source address.





Li, Teo                 Expires 17 July 1998                    [Page 7]


Internet Draft    IP Private Address Identification      18 January 1998


3.3 PAID Decapsulation

   A PAID agent should perform PAID decapsulation in the same way as in
   IP encapsulation within IP [2]. The agent should perform PAID
   encapsulation without changing the inner PAID forwarding header when
   it forwards the decapsulated packet to the destination.

   A private or public destination node should decapsulate a received
   packet and save the source <public, private> address pair for
   subsequent datagram origination.

3.4 ICMP Messages from within the Tunnel

   ICMP messages are to be handled as specified in [2], including the
   maintenance of tunnel "soft state".




































Li, Teo                 Expires 17 July 1998                    [Page 8]


Internet Draft    IP Private Address Identification      18 January 1998


4. Datagram Routing with PAID Encapsulation

   This section describes how the PAID encapsulation and decapsulation
   are performed when no other encapsulation protocols are involved. In
   this case, the following nodes should support the PAID encapsulation
   protocol:

   - private nodes who wish to enable global communication,
   - all PAID agents, and
   - public nodes who wish to communicate with a private node in
     another routing domain.

4.1 An Example of Packet Processing

   To better illustrate PAID, we take the same picture from NAT [1]:

                                  \ | /
                                +---------------+
                                |Regional Router|
                                +---------------+
                              WAN |           | WAN
                                  |           |
               {s2=198.76.28.4,^  |           |  |{s2=198.76.28.4,
                d2=198.76.28.7}|  |           |  v d2=198.76.28.7}
                {S=198.76.28.4,^  |           |  |{S=198.76.28.4,
                 D=198.76.29.7}|  |           |  v D=198.76.29.7}
                {s=10.33.96.5, ^  |           |  |{s=10.22.96.5,
                 d=10.81.13.22}|  |           |  v d=10.81.13.22}
                  +-----------------+       +-----------------+
                  |   PAID Agent    |       |   PAID Agent    |
                  +-----------------+       +-----------------+
                        |                         |
                        |  LAN               LAN  |
                  -------------             -------------
         {s2=10.33.96.5, ^ |                 |   |{s2=198.76.28.7,
          d2=198.76.28.4}| |                 |   v d2=10.81.13.22}
          {S=198.76.28.4,^ |                 |   |{S=198.76.28.4,
           D=198.76.29.7}| |                 |   v D=198.76.29.7}
          {s=10.33.96.5, ^ |                 |   |{s=10.22.96.5,
           d=10.81.13.22}| +--+             +--+ v  d=10.81.13.22}
                           |--|             |--|
                          /____\           /____\
                        10.33.96.5       10.81.13.22

     Figure 2  Datagram Encapsulation and Decapsulation under PAID






Li, Teo                 Expires 17 July 1998                    [Page 9]


Internet Draft    IP Private Address Identification      18 January 1998


4.2 Packets Originating from a Private Node To Another Domain

   When receiving a packet from a private node, any intermediate
   router should never change the PAID forwarding header.

4.2.1 Source Private Node

   When a private node generates a packet, it should perform PAID
   encapsulation for the packet. In the PAID forwarding header, private
   source address field should be present (S bit set). The exit point of
   the tunnel should be the PAID agent of the private source node.

4.2.2 Source PAID Agent

   When the PAID agent for the source private node receives the packet,
   it should replace the source and destination address in the outer IP
   header, respectively with its own address and the public destination
   address in the PAID forwarding header. This means the packet will be
   tunneled to a public destination node or the PAID agent of a private
   destination node.

4.2.3 Destination Node

   When receiving the packet, the final destination node should save the
   source <public, private> address pair for subsequent datagram
   origination.

4.3 Packets from a Domain to Private Node in Another Domain

   When receiving a packet destined to a private node, any
   intermediate router should never change the PAID forwarding header.

4.3.1 Source Node

   When a source node originates a packet to a private node in another
   routing domain, if it does not have the destination node's PAID, it
   may consult relevant DNS servers in the other domain to obtain the
   PAID of the private destination node. The method of obtaining PAIDs
   this way is beyond the scope of this document.

   The source node should perform PAID encapsulation for the packet. In
   the PAID forwarding header, private destination address field should
   be present (D bit set). The exit point of the tunnel should be the
   PAID agent of the source node if the source is a private node, or
   otherwise the public destination address in the PAID forwarding
   header.





Li, Teo                 Expires 17 July 1998                   [Page 10]


Internet Draft    IP Private Address Identification      18 January 1998


4.3.2 Destination PAID Agent

   When the PAID agent of the destination private node receives the
   packet, it should replace the source and destination address in the
   outer IP header, respectively with its own address and the private
   destination address in the PAID forwarding header. This means the
   packet will be tunneled to the destination private node.

4.4 Packets within the Same Domain

   When a packet is destined to a node in the same routing domain, PAID
   encapsulation and decapsulation are not required.

4.5 Packets between Public-Public Pair

   When a packet is originated from a public node and destined to
   another public node, PAID encapsulation and decapsulation are not
   required.

































Li, Teo                 Expires 17 July 1998                   [Page 11]


Internet Draft    IP Private Address Identification      18 January 1998


5. NAT and PAID Compatability

   NAT [6] provides a means for private hosts to access the global
   Internet. It is dominant in the virtual private networks (VPNs).

   PAID is a complement to the NAT. A PAID agent can employ either the
   PAID encapsulation protocol or NAT to forward packets from a private
   node to a public node, provided the private node tunnels the packets
   to the PAID agent by the PAID encapsulation.

   As the PAID approach may not be deployed quicky, the use of PAID as
   a complement to the NAT will probably help in the transition.

5.1 Source Private Node

   The source private node should specify the "forward" field in the
   PAID Registration Request message (see section 7.1). If it requests
   the PAID agent to employ the PAID encapsulation in forwarding
   packets to the destination, the "forward" field should be 0. If it
   requests to employ NAT in the forwarding, the field should be 1.

   The private should use the PAID encapsulation protocol to tunnel
   packets to the PAID agent as specified in section 4.2.1.

5.2 PAID agent

   The PAID agent should indicate its support for NAT using N bit in the
   PAID Agent Advertisement message (see section 6.2). Supporting PAID
   is the minimum requirement.

   When the PAID agent receives a PAID Registration Request, it should
   verify if it supports the requested forwarding method. If it does not
   support, it should deny the request and respond with a PAID
   Registration Reply with code set to 72.

   If it supports the requested forwarding method, whenever it receives
   a packet from the private node, the PAID agent should employ the
   relevant method, take the source and destination addresses from the
   PAID header, and forward packets to the destination.












Li, Teo                 Expires 17 July 1998                   [Page 12]


Internet Draft    IP Private Address Identification      18 January 1998


6. PAID Agent Discovery Protocol

   This section describes an optional means for a private node to
   discover PAID agents available in the same domain.

   A private node may multicast PAID Agent Solicitation messages to
   learn the presence of any PAID agents. Each PAID agent, whenever
   receiving a Solicitation message, must unicast a PAID Agent
   Advertisement message back to the private node.

6.1 PAID Agent Solicitation

   A private node may multicast a PAID Agent Solicitation message to
   obtain one or more PAID agent addresses. This message should be sent
   to the All-PAID-Agents multicast address.

   UDP fields:

      Source Port           variable

      Destination Port      434

   The UDP header is followed by the fields shown below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |C|P|                 Reserved                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Private Address (if present)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

      Type     16

      C        If set, the private node requests that all PAID agents
               receiving the message release the PAIDs associated with
               the private node.

      P        If set, the private address is present.

      Reserved 0

      Private Address
               This field, 4 bytes long, is present only if C bit is set.





Li, Teo                 Expires 17 July 1998                   [Page 13]


Internet Draft    IP Private Address Identification      18 January 1998


   A private node may multicast PAID Agent Solicitation messages to
   learn the presence of any PAID agents. It may retransmit the message
   in a reasonable interval if it does not receive any PAID Agent
   Advertisement message.

   If a private node reboots and loses its PAIDs, it must set the 'C'
   bit in the PAID Agent Solicitation message it sends when restarting.
   By setting the 'C' bit in the solicitation, a private node requests
   that all the PAID agents that receive the solicitation should clean
   up their private PAIDs that match the private address.

6.2 PAID Agent Advertisement

   A PAID agent may send a PAID Agent Advertisement message to inform a
   prospective private node about the IP address of the PAID agent.
   It may also multicast a PAID Advertisement message, at certain
   interval, to all private nodes.

   This message should be sent to a specific private address if it is
   in response to a PAID Agent Solicitation message, or otherwise the
   All-Private-Nodes multicast address.

   UDP fields:

      Source Port           variable

      Destination Port      434 if IP destination address is multicast,
                            or otherwise copied from the source port of
                            the corresponding PAID Solicitation.

   The UDP header is followed by the fields shown below:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |B|H|F|N| Reserved|         Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Agent Address                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-











Li, Teo                 Expires 17 July 1998                   [Page 14]


Internet Draft    IP Private Address Identification      18 January 1998


      Type     17

      B        Busy.  The PAID agent will not accept request from
               additional private nodes.

      H        Home PAID agent.  This agent offers service as a home
               PAID agent.

      F        Foreign PAID agent.  This agent offers service as a
               foreign PAID agent.

      N        NAT support. This agent support NAT. See 5.2.

      Reserved 0

      Lifetime The longest lifetime (measured in seconds) that this
               agent is willing to accept in any PAID Request.
               A value of 0xffff indicates infinity.

      Agent Address
               A public address of the PAID agent.






























Li, Teo                 Expires 17 July 1998                   [Page 15]


Internet Draft    IP Private Address Identification      18 January 1998


7. PAID Registration Protocol

   This section describes a means for a private node to register a PAID
   with a PAID agent. It is a subset of the registration procedure
   specified in the Mobile IP base protocol [1], where the private node
   is taken as the mobile node, the PAID agent is taken as the foreign
   agent, and no home agent is required.

   A private node may intend to register a PAID with a PAID agent in
   order to enable global communication. To register a PAID, the private
   node should send a PAID Registration Request message to a PAID agent.
   The PAID Agent should respond with a PAID Registration Reply message
   where it indicates whether it agrees to bind the private node to
   itself and to receive and forward traffic subsequently on behalf of
   the private node.

   The private node may keep retransmitting PAID Registration Request
   messages to the PAID agent until it receives a reply or a maximum of
   MAX_RETRANS Registration Request messages have been sent. In the
   latter case, the private node may choose to seek a PAID from another
   PAID agent.

   A private node may have multiple PAIDs, each associated with a
   different PAID agent. These PAIDs can be used for various sessions
   of datagram origination. However, each private node can only receive
   global datagrams at one PAID, which is the one it obtained in the
   latest registration.

   Below are the formats of the PAID Registration Request and Reply
   messages. The use of these messages are similar to the Mobile IP base
   protocol [1].

7.1 PAID Registration Request Message

   A private node may send a PAID Registration Request message to
   register a PAID with a PAID agent. This message should be sent to the
   specific PAID agent, which may be learned from previous PAID
   Advertisement messages.

   UDP fields:

      Source Port           variable

      Destination Port      434

   The UDP header is followed by the fields shown below:





Li, Teo                 Expires 17 July 1998                   [Page 16]


Internet Draft    IP Private Address Identification      18 January 1998


    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |D|Rsvd |Forward|           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Agent Address                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Private Address                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                     Identification                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

      Type     18

      D        Domain name. If the 'D' bit is set, the private node
               requests the PAID agent to update the DNS with the new
               PAID.

      Forward  Forwarding method. See 5.1.
               0: PAID Encapsulation
               1: NAT

      Reserved 0

      Lifetime
               The number of seconds remaining before the PAID is
               considered expired.  A value of zero indicates a
               request for disassociation. A value of 0xffff indicates
               infinity.

      Agent Address
               A public address of the PAID agent.

      Private address
               A private address of the originating node.

      Identification
               A 64-bit number, constructed by the private node, used
               for matching PAID Registration Requests with PAID
               Registration Replies, and for protecting against replay
               attacks of these messages.







Li, Teo                 Expires 17 July 1998                   [Page 17]


Internet Draft    IP Private Address Identification      18 January 1998


7.2 PAID Registration Reply Message

   A PAID agent returns a PAID Registration Reply message to a private
   node which has sent a PAID Registration Request message. The Reply
   message contains the necessary codes to inform the private node about
   the status of its Request, along with the lifetime granted by the
   PAID agent, which may be smaller than the original Request.

   UDP fields:

      Source Port           variable

      Destination Port      copied from the source port of the
                            corresponding Reply message.

   The UDP header is followed by the fields shown below:


    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |      Code       |         Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Agent Address                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Private Address                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                     Identification                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

      Type     19

      Code     A value indicating the result of the PAID Registration
               Request.  See below for a list of currently defined Code
               values.

      Lifetime
               If the Code field indicates that the PAID Registration
               request was accepted, the Lifetime field is set to the
               number of seconds remaining before the registration is
               considered expired.  A value of zero indicates that the
               private node has been disassociated.  A value of 0xffff
               indicates infinity.  If the Code field indicates that the
               request was denied, the contents of the Lifetime field
               are unspecified and must be ignored on reception.



Li, Teo                 Expires 17 July 1998                   [Page 18]


Internet Draft    IP Private Address Identification      18 January 1998


      Agent Address
               A public address of the PAID agent.

      Private address
               A private address of the originating node.

      Identification
               A 64-bit number used for matching PAID Registration
               Requests with PAID Registration Replies, and for
               protecting against replay attacks of these messages.  The
               value is based on the Identification field from the PAID
               Registration Request message from the private node, and
               on the style of replay protection used in the security
               context between the private node and its PAID agent
               (defined by the PAID security association between them,
               and SPI value in the PAID Authentication Extension).

The following values are defined for use within the Code field.
   PAID request successful:

        0 registration accepted

   PAID request denied by the foreign agent:

       64 reason unspecified
       65 administratively prohibited
       66 insufficient resources
       67 private node failed authentication
       68 requested Lifetime too long
       69 poorly formed Request
       70 invalid public address
       71 registration Identification mismatch
       72 forwarding method is not supported

   Up-to-date values of the Code field are specified in the most recent
   "Assigned Numbers" [4].















Li, Teo                 Expires 17 July 1998                   [Page 19]


Internet Draft    IP Private Address Identification      18 January 1998


7.3 PAID Authentication Extension

   Exactly one PAID Authentication Extension must be present in all PAID
   Requests and PAID Replies. The location of the extension marks the
   end of the authenticated data. This extension should be appended to
   both the PAID Request and Reply messages.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |         SPI  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ... SPI (cont.)          |       Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type            32

      Length          4 plus the number of bytes in the Authenticator.

      SPI             Security Parameter Index (4 bytes).  An opaque
                      identifier.

      Authenticator   (variable length)




























Li, Teo                 Expires 17 July 1998                   [Page 20]


Internet Draft    IP Private Address Identification      18 January 1998


8. Various Aspects of PAID

8.1 Network Applications Consideration

   To allow network applications (such as FTP) to control over the
   encapsulation, some BSD APIs ought to be changed. This issue may be
   discussed elsewhere.

8.2 Domain Name System Consideration

   This issue may be discussed elsewhere.

9. Security

   The security issue is beyond the scope of this document.

10. Acknowledgments

   Many thanks to Dr. Y. C. Tay at the National University of Singapore
   for supporting this joint work as well as for his valuable comments.

References

   [1] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
       1996.

   [2] C. Perkins. IP Encapsulation within IP.  RFC 2003, May 1996.

   [3] C. Perkins. Minimal Encapsulation within IP, RFC 2004, October
       1996.

   [4] J. K. Reynolds and J. Postel.  Assigned Numbers.  RFC 1700,
       October 1994.

   [5] J. Postel, Editor. "Internet Protocol", STD 5, RFC 791, September
       1981.

   [6] K. Egevang, and P. Francis. The IP Network Address Translator,
       RFC 1631, May 1994.

   [7] P. Calhoun and C. Perkins. Tunnel Establishment Protocol, Internet
       Draft, November 1997.

   [8] S. Hanks, T. Li, D. Farinacci, and P. Traina.  Generic Routing
       Encapsulation (GRE).  RFC 1701, October 1994.

   [9] Y. Rekhter, and et al. Address Allocation for Private Internets,
       RFC 1918, February 1996.



Li, Teo                 Expires 17 July 1998                   [Page 21]


Internet Draft    IP Private Address Identification      18 January 1998


Author's Address

   Questions about this memo can also be directed to the author:

        Y. Li
        Bay Networks, Inc.
        BL60-304
        600 Technology Park Drive
        Billerica, MA 01821

        Phone:  1-978-916-1130
        Fax:    1-978-670-8760
        E-mail: yli@BayNetworks.COM


        W. T. Teo
        Department of ISCS
        National University of Singapore
        Lower Kent Ridge Crescent
        SINGAPORE 119260

        E-mail: teoweetu@iscs.nus.edu.sg




























Li, Teo                      Expires 17 July 1998              [Page 22]