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 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 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 / <192.32.174.44,10.10.10.10> Node "C" PAID address is / <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 . The destination node's PAID address is . 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)", - 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]