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 address pair. To enable private hosts to communicate using these address pairs efficiently, we propose a PAID Encapsulation protocol. To acquire a 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 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 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 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 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 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]