Internet Engineering Task Force                                    Y. Li
INTERNET DRAFT                                           Nortel Networks
                                                               W. T. Teo
                                                     National University
                                                            of Singapore
                                                        17 November 1998


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



Status of This Memo

   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 (North
   Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
   ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).


Abstract

   This memo describes a hierarchical IP addressing scheme that provides
   end-to-end host connectivity across routing realms with overlapping
   address space. PAID agents are routers that connect an internal
   private network to the global public Internet. The PAID agents'
   public IP addresses augment the locally significant private addresses
   to form globally unique binary IP addresses for private hosts. This
   extends the IPv4 address space and allows Internet hosts to use
   private instead of public IP addresses for global Internet
   communication. The proposal does not need any changes to the current
   routing infrastruture but requires an extension to the end hosts'
   network socket descriptors and the domain name system.








Li, Teo                 Expires 16 May 1999                     [Page i]


Internet Draft    IP Private Address Identification     17 November 1998

1. Introduction

   This document describes a proposal to extend the IPv4 address space
   using a hierarchical IP addressing scheme.

1.1 Private Networks

   In an internal private network, host machines are usually assigned IP
   address from the private IP address space [1]. These addresses
   typically have no topological significance outside the network i.e.
   external hosts cannot communicate with the hosts within the private
   network.

   Each of the private networks (and the public Internet) constitute an
   independent routing realm. IP addresses are unique and valid only
   within each routing realm, thus routing realms may have overlapping
   address space. The standard IP routing mechanism cannot deliver
   datagrams across the different routing realms.

1.2 Datagram Delivery

   Using Generic Routing Encapsulation (GRE) tunneling between the end
   hosts, the current IPv4 routing mechanism already supports the
   delivery of datagrams across different routing realms. Therefore,
   using GRE [2], there is no need to modify the routing infrastructure
   to support PAID operation. Since datagram delivery is not a problem,
   a solution needs only be found to address the end hosts in different
   routing realms.

1.3 Address Collisions

   Address collision is an implication of using private IP addresses.
   The problem of address space collisions are further aggravated by
   merging privately addressed networks. Therefore to maintain the
   end-to-end semantics of IP addresses, the current IP addressing
   scheme needs to be augmented.

   This document will describe one addressing scheme that can provide a
   globally unique identification to any private host without modifying
   the existing network deployment or require the network address
   renumbering of any hosts and still retain compatibility with the
   current IPv4 addressing scheme.

1.4 Hierachical IP Addressing

   Within a routing realm, the current single-tier IP addressing scheme
   fulfills the end-to-end host connectivity requirements, thus for the
   rest of this document, we are only concerned with network
   communication across connected routing realms.



Li, Teo                 Expires 16 May 1999                     [Page 1]


Internet Draft    IP Private Address Identification     17 November 1998

   A two-tier address hierarchy is used to identify end hosts in private
   networks connected to the public Internet.

   At the top level, all private hosts can be identified by the private
   network which they belong to. Since the private network must be
   connected to the public Internet for global communication, there must
   be a router that is connected to both the public Internet and the
   private network. This router will have a public IP address that is
   valid in the public Internet. The private network can therefore be
   globally addressed using this public IP address. Some private
   networks may have more than one connection to the public Internet. In
   this case, any of the public IP addresses can be used to identify the
   private network, provided the chosen address remains constant for a
   given network stream connection.

   At the bottom level, all the end hosts can then be addressed by their
   private IP addresses. Therefore, private hosts can be globally
   addressed using a <public, private> address pair.

1.5 Design Goals

   The PAID proposal attempts to prevent possible side effects to higher
   layer network protocols due to the introduction of binary IP
   addressing. Although the end hosts' network socket descriptors are
   associated with binary IP addresses, the GRE tunnelled payload
   retains the original IPv4 header. As in the traditional IPv4
   addressing scheme, this encapsulated IP header's destination and
   source IP addresses are the end hosts' assigned IP addresses.

   The design limits PAID impact on existing IP protocols and unless it
   is mentioned otherwise, the IP protocols should not need any
   modification for PAID compatibility.

   The end-to-end semantics of network addresses are retained with the
   adoption of binary addresses, ensuring support for any end-to-end
   network layer security scheme.

1.6 Applicability

   Since it is unrealistic to expect all Internet hosts to immediately
   support PAID, hosts using private IP address will enjoy less services
   than if they have full traditional IPv4 connectivity.

   If the private hosts only require access to foreign servers but do
   not provide services to foreign clients, they can employ IP Network
   Address Translators [4] to access end hosts that do not support PAID.
   Thereafter, the Internet connectivity of the private hosts can expand
   with PAID deployment without sacrificing the latters' access to the
   Internet resources.



Li, Teo                 Expires 16 May 1999                     [Page 2]


Internet Draft    IP Private Address Identification     17 November 1998

   Currently, PAID is more suitable for complete IP network connectivity
   between multiple cooperating private networks. Enterprizes with their
   own Intranets can adopt PAID to merge with related organizations'
   private networks and form extranets. Consequently, all these
   extranets will also have full network connectivity with one anther.

1.7 PAID Requirements

================ 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  Hosts in different Routing Realms communicate using PAID

   The diagram above illustrates a typical network deployment over the
   Internet. Private Address Identification (PAID) enables hosts to
   communicate across routing realms.

   For example, a private host 10.10.10.10 in the ISP network can
   communicate with a private host 10.20.20.20 in the enterprise VPN by
   using the binary IP addresses <192.32.174.44, 10.10.10.10> and
   <200.9.2.1, 10.20.20.20> respectively. To enable this functionality,
   these two private hosts must support the binary addressing scheme and
   GRE encapsulation and decapsulation. Additionally, the ISP router and
   the Enterprise router B must support GRE tunneling. All other routers
   can continue to run conventional routing protocols.






Li, Teo                 Expires 16 May 1999                     [Page 3]


Internet Draft    IP Private Address Identification     17 November 1998

2. Terminology and Definitions

2.1 Private Node

   A node where all its interface addresses are not reachable from the
   global public Internet. These addresses are typically from the
   private address space as specified in RFC 1918 [1].

2.2 Public Node

   A node which has at least one public interface address. The public
   address is routable by the global public Internet as contrast to a
   private node's address.

2.3 PAID Agent

   A PAID agent is a public node. The PAID agent's public address
   provide private nodes with a globally unique identification of their
   routing realm.

   A PAID agent is connected to both the public Internet and a private
   network. 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.4 PAID Address

   This document uses a binary IP addressing scheme to identify nodes in
   private routing realms. The PAID address is used to identify a
   private node globally. The PAID address is a <Agent, Node> IP address
   pair.

   PAID agents connect private routing realms to the public Internet.
   The Agent component of a PAID address is a PAID agent's public IP
   address. The Node component of a PAID address is the end host's IP
   address.

   All private routing realms are connected to a common routing realm,
   the public Internet. The Agent address is optional for public node in
   this common routing realm. However, private nodes must have an Agent
   address for communication across routing realms. The Agent address
   must be reachable from the Node address using the existing routing
   mechanism available in a private routing realm.






Li, Teo                 Expires 16 May 1999                     [Page 4]


Internet Draft    IP Private Address Identification     17 November 1998

   The PAID addresses represent the communication end points for traffic
   across different routing realms and are only relevant to the end
   hosts. The PAID agents may also process the PAID addresses in order
   to handle ICMP messages from within the GRE tunnel. All other non
   PAID aware nodes will identify both the PAID Agents and end hosts by
   their Agent and Node IP addresses respectively.

   The diagram below illustrates all the PAID entities during
   communication between two private nodes across the public Internet.

     Node "A" <----> Agent "B" <----> Agent "C" <------> Node "D"
   10.10.10.10     192.32.174.44      200.9.2.1        10.20.20.20

   Node "A" PAID address is <B,A> / <192.32.174.44,10.10.10.10>
   Node "C" PAID address is <C,D> / <200.9.2.1,10.20.20.20>

3. Datagram Delivery

   PAID uses GRE tunneling [3] for datagram delivery across different
   routing realm.

   GRE encapsulation is a means to alter the normal IP routing for
   datagrams, by delivering them to intermediate destinations 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 GRE encapsulation provides a Source Route Entry (SRE) in the
   tunnel header. Using a SRE with an Address Family indicating an IP
   source route (and the Strict Source Route flag cleared), the
   intermediate destinations can be specified.

   In the case of PAID, the SRE's IP address list will include the Agent
   and Node addresses. The SRE list also represents the PAID addresses
   of the end hosts. The end points of the GRE tunnel must therefore be
   the communicating end hosts.

3.1 Overall PAID packet

   The diagram below provides an overview of the entire PAID packet.






Li, Teo                 Expires 16 May 1999                     [Page 5]


Internet Draft    IP Private Address Identification     17 November 1998

   ---------------------    -------------------------
   |                   |    |
   | IP Delivery Header| -> | ... Protocol Type 47
   |                   |    |
   ---------------------    -------------------------
   |                   |    | ... Protocol Type 0x800
   |     GRE Header    | -> -------------------------    --------------
   |                   |    | ... Source Route Entry  -> | ... Address
   |                   |    |     (PAID Address)         | Family 0x800
   |                   |    |                            |
   ---------------------    -------------------------    --------------
   |                   |    | ... Original IP Header
   |    IP Payload     | -> -------------------------
   |                   |    |
   ---------------------    -------------------------

3.2 GRE SRE Processing

   PAID agents should process the GRE's SRE as specified in RFC 1702
   [2]. The diagram illustrates the processing of a PAID packet in the
   example in [Section 1.7].

   S1 and D1 represent the original IP header's source and destination
   addresses respectively. S2 and D2 represent the IP delivery header's
   source and destination addresses respectively.

                                  \ | /
                                +---------------+
                                |Regional Router|
                                +---------------+
                              WAN |           | WAN
                                  |           |
             {S2=192.32.174.44,^  |           |  |{S2=192.32.174.44,
              D2=200.9.2.1}    |  |           |  | D2=200.9.2.1}
               {S1=10.10.10.10 |  |           |  |{S1=10.10.10.10
                D1=10.20.20.20}|  |           |  v D1=10.20.20.20}
                  +-----------------+       +-----------------+
                  |   PAID Agent    |       |   PAID Agent    |
                  +-----------------+       +-----------------+
                        |                         |
                        |  LAN               LAN  |
                  -------------             -------------
       {S2=10.10.10.10,  ^ |                 |   |{S2=200.9.2.1,
        D2=192.32.174.44}| |                 |   | D2=10.20.20.20}
         {S1=10.10.10.10,| |                 |   |{S1=10.10.10.10,
          D1=10.20.20.20}| +--+             +--+ v D1=10.20.20.20}
                           |--|             |--|
                          /____\           /____\
                        10.10.10.10      10.20.20.20



Li, Teo                 Expires 16 May 1999                     [Page 6]


Internet Draft    IP Private Address Identification     17 November 1998

3.3 Source Node

   When a private node generates a packet destined to another routing
   realm, it must perform GRE encapsulation for the packet.

   IP Delivery Header

      The TTL, TOS and IP options of the original IP header must be
      copied into the same fields in the IP delivery header.

   GRE Header

      The GRE Checksum and Key values are optional for PAID packets.
      The GRE Sequence Number is not required for PAID packets.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|R|K|S|s|Recur|P| Flags | Ver |         Protocol Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Checksum (optional)      |            Offset             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key (optional)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Routing
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Checksum Present (bit 0)

      If the Checksum Present bit is set to 1, then the Checksum field
      contains valid information.

      BOTH the Checksum and Offset fields are present in the GRE packet.

   Routing Present (bit 1)

      The Routing Present bit is set to 1.

   Key Present (bit 2)

      If the Key Present bit is set to 1, then it indicates that the Key
      field is present in the GRE header.

   PAID Present (bit 8)

      The PAID Present bit is set to 1, to indicate PAID addresses is
      used.

      The Sequence Number Present (bit 3), Strict Source Route (bit 4),
      Recursion Control (bits 5-7) and Version Number (bits 13-15) bits
      are set to 0.

Li, Teo                 Expires 16 May 1999                     [Page 7]


Internet Draft    IP Private Address Identification     17 November 1998

   Protocol Type (2 octets)

      The Protocol Type field is 0x800.

   Offset (2 octets)

      The offset field indicates the octet offset from the start of the
      Routing field to the first octet of the active Source Route Entry
      to be examined. The default value is 0.

   Checksum (2 octets)

      The Checksum field contains the IP (one's complement) checksum of
      the GRE header and the original IP payload.

   Key (4 octets)

      The Key field contains a four octet number which is inserted by
      the source node. It may be used by the destination node to
      authenticate the source of the packet. The techniques for
      determining authenticity are outside of the scope of this
      document.

   The Routing field is a list of Source Route Entries (SREs). Each
   SRE has the form:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Address Family          |  SRE Offset   |  SRE Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         IP Address List ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The routing field is terminated with a "NULL" SRE containing an
   address family of type 0x0000 and a length of 0.

   Address Family (2 octets)

      The Address Family field is set to 0x800.

   SRE Offset (1 octet)

      The SRE Offset field indicates the octet offset from the start of
      the Routing Information field to the first octet of the active
      entry in Source Route Entry to be examined. The initial default
      value is 8.





Li, Teo                 Expires 16 May 1999                     [Page 8]


Internet Draft    IP Private Address Identification     17 November 1998

   SRE Length (1 octet)

      The SRE Length field contains the number of octets in the SRE. If
      the SRE Length is 0, this indicates this is the last SRE in the
      Routing field.

   The IP Address List indicates the intermediate destinations from the
   source node to the destination node that the PAID packet has to
   traverse. The list also represent the PAID addresses of the end
   hosts.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Source Node                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Source Agent    (Optional)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Destination Agent (Optional)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Destination Node                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The source node's PAID address is <Source Node, Source Agent>.  The
   destination node's PAID address is <Destination Node, Destination
   Agent>.

   The first and last IP address list entries MUST be the end nodes' IP
   addresses.

   Either the Source or Destination Agent entry MUST be present. If
   there is only one Agent IP address entry, the latter may be treated
   as the Source or Destination Agent in the end nodes' PAID address.

3.4 Destination Node

   On receiving the PAID packet, the destination node should record the
   PAID addresses in the GRE's SRE, before performing GRE decapsulation.
   The TTL, TOS and IP options of the IP delivery header must be copied
   into the same fields in the original IP header.

3.5 ICMP messages

   The PAID agents should handle ICMP messages from within the GRE
   tunnel as specified in [5], including the maintenance of tunnel
   "soft state".






Li, Teo                 Expires 16 May 1999                     [Page 9]


Internet Draft    IP Private Address Identification     17 November 1998

4. PAID DNS

   This section describes the enhancements to DNS required to support
   PAID addressing and the procedure for PAID hosts to perform PAID DNS
   lookup.

   PAID DNS resolution can typically be performed through a two step DNS
   resolution by the source host. The traditional public DNS server need
   to be enhanced to provide the public addresses of PAID agents and
   private DNS servers of a private network.

   This document operates on the paradigm that interconnecting routing
   realms may have overlapping address space but the Fully Qualified
   Domain Names (FQDN) of hosts that fall within IN-ADDR.ARPA domain
   must be unique for the PAID DNS service to work.

4.1 Public DNS Server

   A name server contains "in-addr.arpa" records and enable reverse
   "address to name" lookup. To support PAID, two new DNS records type
   are introduced in the public DNS server - the PX and DX records. The
   solution is a generalization of the MX record scheme [6] currently
   used to identify a mail exchange in a domain.

   The PX records list the PAID agents' public addresses in a domain and
   the DX record points to the public address of the domain's private
   DNS server.

4.2 Private DNS Name Server

   A private DNS server contains the resource records (RRs) of the
   private nodes in its domain. This DNS server should be separated from
   the general Internet DNS referrals to prevent the non routable
   private IP addresses from propagating on public networks.

   The private DNS server should support secure DNS name service and may
   sign replies that originate from the external world.

4.3 DNS Resolver

   The source hosts' resolvers must support an extension to the
   iterative mode DNS resolution process [4]. The resolver must retrieve
   the PX and DX records of the destination domain before querying the
   destination domain's private DNS server.

   For simplicity, the proposal assumes the source node resolver has
   access to the public Internet. This access may be via network address
   (port) translators [4] or any other application gateways.
   Alternatively, the DNS server in a private network may support
   recursive service to access the private DNS server in the destination
   domain, provided it can guarantee the source host is PAID aware. The

Li, Teo                 Expires 16 May 1999                    [Page 10]


Internet Draft    IP Private Address Identification     17 November 1998

   DNS server acts as an intermediatery to cross the routing realm
   boundaries. The rest of this document assumes the DNS server does not
   support recursive service.

   The resolver should typically return the PAID address to the user
   program.

4.4 PX and DX records

   In a definative scheme, it would be neccessary to define the DNS
   record type and the corresponding format. Currently for easier
   deployment, the two entries may use the generic "text" record to
   register the PAID agents and private name server of a domain. This
   record is desiged for general purpose extensions in the DNS, and
   its content is a text string.

   The PX record will contain three fields :

   - A record identifier composed of the two characters "PX".

   - A cost indicator, encoded up to 3 numerical digits.

   - An IP address, encoded as a text string following the "dot"
     notation.

   The three strings will be separated by a single comma. An example of
   a PX record would thus be:
    ________________________________________________________________
   |         domain        |  type  |  record  |       value        |
   |                       |        |          |                    |
   |*.2.9.200.in-addr.arpa |   IP   |    TXT   |   RX, 10, 200.9.2.1|
   |_______________________|________|__________|____________________|

   The DX record is similar to the PX record except there are only two
   fields :

   - A record identifier composed of the two characters "DX".

   - An IP address, encoded as a text string following the "dot"
     notation.

4.5 PAID DNS requirements

   The scheme is valid only if the PX, DX records and the private DNS
   server of the destination domain can be accessed from the public
   Internet.

   A private domain that wants to obtain dynamic connectivity using this
   scheme will have to replicate its domain name service info so as to
   provide them through servers accessible from the core of the
   Internet.

Li, Teo                 Expires 16 May 1999                    [Page 11]


Internet Draft    IP Private Address Identification     17 November 1998

5. Name Lookup

   For Host name to Host Address address query requests :

   Assuming the destination node is dst.private.com.

   The source host resolver will query the DNS with the name for the
   destination host and obtain the PX and DX records. The PX record
   lists the Agent address for the destination node.

   The name resolver on the source host node will send the name lookup
   query (A record) for dst.private.com to the private.com domain's
   private DNS server listed in the DX record. The Node address for the
   destination node is returned.

   For Host address to Host name queries :

   Assuming the destination node is <192.32.174.44,10.10.10.10>

   The source host resolver will query the DNS with the host address
   192.32.174.44 and obtain the DX record.

   The name resolver on the source host will send a inverse name lookup
   query (PTR record) for "10.10.10.10.IN-ADDR,ARPA." to the private
   domain's private DNS server listed in the DX record. The host name
   for the destination node is returned.

5.1 Choosing a PAID agent

   Having only one PAID agent will be a single point of failure and
   a possible bottleneck device.

   The PX records should carry associated with each PAID agent a
   preference identifier. To select a PAID agent, one has to rely on
   heuristical approaches. The easiest may be to always choose the
   "preferred PAID agent" - the PX entry with the minimal preference
   index or alternatively chose one PAID agent randomly within the list
   for each stream network connection. This will spread the traffic on
   several routes and introduce better load sharing and more redundancy
   to the network.

5.2 Performance

   The initial DNS exchanges required for loading the record information
   may induce a response time penalty for the users. Some caching
   strategy of each private routing realm's PAID agents and private DNS
   server should be sufficient to alleviate the performance effect.





Li, Teo                 Expires 16 May 1999                    [Page 12]


Internet Draft    IP Private Address Identification     17 November 1998

6. Applications Consideration

   Any application protocol that embeds the end nodes' IP addresses in
   the application payload may need to be PAID aware if these addresses
   are consequently used to create another separate network connection.

7. Security Considerations

   This document proposes a scheme to allow network communication across
   routing. GRE is a clear text encapsulation mechanism and does not
   protect sensitive data over the unsecure global Internet. Since PAID
   retains the end-to-end semantics across routing realms, additional
   security mechanism such as IPSEC should be used to protect the
   original IP payload.

   Organizations may not want to enable full network connectivity for
   all private hosts nor allow access from all external hosts. The PAID
   agents should support host access controls. The firewall rules may
   be enhanced to deny or allow access based on PAID addresses in the
   GRE' SRE.

Acknowledgements

   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.

   This work was supported in part by National University of Singapore
   ARF grant RP960683.

References

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

   [2] S. Hanks, T. Li, D. Farinacci and P. Traina, "Generic Routing
       Encapsulation over IPv4 networks", RFC 1702, October 1994

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

   [4] P. Srisuresh, K. Egevang, "Traditional IP Network Address
       Translator (Traditional NAT)",
       <draft-ietf-nat-traditional-01.txt> - work in progress, November
       1998

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

   [6] P. Mockapetris, "Domain Name - Concepts and Facilities",
       RFC 1034, November 1987


Li, Teo                 Expires 16 May 1999                    [Page 13]


Internet Draft    IP Private Address Identification     17 November 1998

Author's Address

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

   Phone:  1-978-916-1130
   Fax:    1-978-670-8760
   E-mail: yunli@NortelNetworks.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 16 May 1999                    [Page 14]