Internet Engineering Task Force Bernhard Petri INTERNET-DRAFT Siemens AG Date: Jan. 20, 2000 Expires: July 2000 Private IP Encapsulation within IP (PIPE) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract RFC 2003 specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. This is 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. This draft allows to extend this encapsulation mechanism also for private IP addresses. Petri [Page 1] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 1. Introduction [RFC 2003] specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. 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 based on the (network part of the) IP Destination Address field in the original IP header. Once the encapsulated datagram arrives at this intermediate destination node, it is decapsulated, yielding the original IP datagram, which is then delivered to the destination indicated by the original Destination Address field. [RFC 2003] only allows to encapsulate public IP addresses within IP. However, current IP solutions often use non-unique private IP addresses, e.g. taken from the address space reserved for this purpose in [RFC 1918]. These private IP addresses typically are unique within a private Intranet, e.g. behind a firewall / Network Address Translator (NAT), but are not globally unique and not globally routable in the Internet. This draft therefore outlines an extension of [RFC 2003] which allows to encapsulate and decapsulate such private IP addresses in the same way as described in [RFC 2003], and to transfer them across the public Internet (also referred to as "tunneling" in RFC 2003). Behaviour not explicitly mentioned in this draft applies as specified in [RFC 2003]. 2. Motivation and Solution Overview 2.1 Motivation: Mobility Applications Using Private IP Addresses It is expected that there may be various applications which will be able to benefit from the PIPE encapsulation mechanism outlined in this draft. An important initial application will be the support of mobile nodes having obtained private IP addresses within a foreign network and/or using private IP addresses in their home network (see also section 2 of [RFC 2003]). Figure 1 shows an example of a basic tunneling/encapsulation case where a private IP address is translated and encapsulated through a public IP tunnel; within the framework of mobility applications, the source might e.g. be a foreign agent registering at the home agent as the destination, or the source might e.g. be the home agent forwarding data packets to the foreign agent as the destination. Petri [Page 2] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 The terms "encapsulator" and "decapsulator" are used as defined in [RFC 2003]. It should be noted that the encapsulator - as the entry point of the tunnel - also performs an address resolution function, in this case between private und public IP addressing. The particular resolution functions used by the encapsulator are outside the scope of this draft. private IP private IP in IP private IP | | | source ---> encapsulator --------> decapsulator ---> destination Figure 1: Example for encapsulation of private IP in IP In Figure 1, the "private IP" address realm between source and encapsulator may or may not be the same "private IP" address realm as the one between decapsulator and destination. 2.2 Identification of Private Addressing Realms A major problem of the use of private IP addresses is that they are not globally unique, and that a decapsulator receiving an encapsulated private IP address would usually not know, to which address space a private IP address belongs to. In Figure 1 above, the decapsulator will usually not be able to derive the particular private addressing realm from its knowledge about the begin of the tunnel. Similar problems had already emerged within the Internetwork over NBMA (ION) area of the IETF, and a solution had been developed using a global identification scheme for IP-VPNs which is outlined in [RFC 2685]. This scheme uses an identifier ("VPN-ID") to identify a private network, typically with the objective to provide a related VPN service. The scheme is based on a well-known OUI/index mechanism as e.g. also used for MAC addresses, or for the Interface ID of IPv6 addresses. The VPN-ID consists of a 7-octet format which is split into a 3-octet OUI of a "VPN authority", followed by a 4-octet index allocated by that authority. This draft proposes to also use this identification scheme for the indication of the particular address realm a private IP address belongs to, when being encapsulated and being transferred across the internet. Since private IP addresses are assumed to be unique within that particular private network, it is easy to attach a VPN-ID to them, e.g. by using the VPN-related OUI of the owner of that network. Petri [Page 3] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 2.3. Example: Private IP Interconnection This example is intended to illustrate and motivate the generic solution specified in sections 3 ff below. In this particular example, the configuration shown in Figure 1 is taken, and it is assumed that both the source and destination belong to the same private address realm "PR1". Two different cases for the IP-IP tunnels can be distinguished: a) The decapsulator may be configured in a way that all inner IP header addresses received via IP-IP tunnels, are assumed to belong to one particular IP address space (either a private IP address space or the public IP addressing). In this case, the encapsulator will only insert IP datagrams from that particular address space into the IP-IP tunnel. b) No particular IP address space is pre-associated with the IP-IP tunnel. This configuration option applies in cases where the encapsulator might send IP datagrams for different address spaces (e.g. public and private) via the IP-IP tunnel to a decapsulator. In case a), IP-IP encapsulation is applied in a similar way as specified in section 3 of [RFC 2003], with the difference that in this example, the IP addresses within the inner IP header are configured to belong to the private IP address space "PR1" rather than to public IP addressing. In order to encapsulate a private IP datagram into an IP-IP tunnel in case b), an outer IP header is inserted by the encapsulator before the datagram's existing private IP header, as follows: Petri [Page 4] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 Public IP Network Private IP Network "PR1" +---------------------------+ | | | Outer IP Header | | | +--------+------------------+ | Sel. | VPN-OUI | +--------+------------------+ | VPN index | +---------------------------+ +---------------------------+ | | | | | private IP Header (PR1) | | private IP Header (PR1) | | | | | +---------------------------+ ====> +---------------------------+ | | | | | | | | | IP Payload | | IP Payload | | | | | | | | | +---------------------------+ +---------------------------+ Figure 2: Example for Private IP-IP Encapsulation The detailed formats for the fields shown in Figure 2 are specified in section 3 below. The Selector field ("Sel.") serves as discriminator / selector indicating which types of addresses are used in the inner IP header. The VPN-Identifier (VPN-ID), consisting of VPN-OUI and VPN index, in this example shows a value identifying PR1. 3. Private IP-IP Encapsulation (PIPE) 3.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. In this document, the following definitions and acronyms are used: Default Addressing Realm -- this is the configured addressing realm a particular (sent or received) source / destination IP address is assumed to belong to, unless another addressing realm is explicitly indicated by a VPN-ID with the mechanisms specified below. In case of [RFC 2003], the default addressing realm is the public IP addressing. Petri [Page 5] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 Explicitly Indicated Addressing Realm -- this is the addressing realm specified by a VPN-ID related to a particular sent or received source / destination IP address. VPN-Identifier (VPN-ID) -- this term is specified in [RFC 2685], and is used in this document for the identification of a particular Explicitly Indicated Addressing Realm. Other terms, like e.g. "encapsulator", "decapsulator", "inner IP header" and "outer IP header" are used as specified in section 3 of [RFC 2003]. 3.2 Configuration Options and Backward Compatibility This draft outlines a backward compatible extension of [RFC 2003] for the use of private IP addresses. Behaviour not explicitly mentioned in this draft applies as specified in [RFC 2003]. As indicated in [RFC 2003], IP-IP tunnels require knowledge about the decapsulation capabilities at the endpoint of the tunnel. For this document, 3 different configuration options are distinguished which determine how source and destination IP addresses, indicated in the inner IP header, are interpreted. (1)All source and destination addresses, both in the inner and outer IP headers, are interpreted as being public IP addresses. Support of this configuration option IS REQUIRED for the case of communication with legacy [RFC 2003] devices. (2)All indicated source and destination IP addresses, indicated in the inner or outer header of IP-IP tunnels, are assumed to belong to one particular Default Addressing Realm. This configuration option MUST e.g. be selected if either the encapsulator or the decapsulator is not able to process VPN-IDs. The Default Addressing Realm may be the public Internet addressing (as in RFC 2003) or any other private IP addressing realm. The Default Addressing Realm for the outer IP header is that of the network between Encapsulator and Decapsulator. (3) Indicated source IP addresses may belong to an Explicitly Indicated Addressing Realm or to the Default Addressing Realm; indicated destination IP addresses may also belong to an Explicitly Indicated Addressing Realm or to the Default Addressing Realm. This is the most general case. For equipment complying to this specification, it IS REQUIRED to support configuration options (1) and (2), and it is RECOMMENDED to also support option (3). Support of option (3) IS REQUIRED if more Petri [Page 6] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 than one addressing realm is to be supported by IP-IP tunnels. The main purpose of configuration option (1) is to ensure interoperability with legacy [RFC 2003] devices. For configuration option (1), the IP in IP encapsulation formats specified in [RFC 2003] MUST be used. The formats for configuration options (2) and (3) are outlined in section 3.3 below. For configuration options (2) and (3), Default Addressing Realms for the inner source and destination IP addresses MUST be preallocated. Note that the Default Addressing Realms for source and destination MAY be different. For all 3 options, the format of the inner "IP header" and "IP payload" fields MUST be coded as specified in section 3 of [RFC 2003]. 3.3 PIPE Encapsulation Formats For the formats used in configuration options (2) and (3), 5 different cases can be distinguished (see subsections 3.3.1 - 3.3.5 below). For all 5 cases, the "Protocol" field of the outer IP header (identifying the next level protocol) MUST be set to the value: .. . The Selector Byte ("Sel."), specified below, is used to distinguish between these cases: 3.3.1 Default Source and Destination Address If for both source and destination address the Default Addressing Realm is used, the encapsulation format of [RFC 2003] applies. Note that unlike in [RFC 2003], the inner header IP addresses in this case are not automatically assumed to be public IP addresses, but are interpreted according to the Default Address Realm(s). It is not precluded that the Default Address Realms for the source and destination addresses are different. For configuration option (2), this is the only possible format. 3.3.2 Explicitly Indicated Source and Destination Adress (Same Realm) If both the source and destination IP address are to be indicated explicitly, and belong to the same addressing realm, the following encapsulation format SHOULD be used: Petri [Page 7] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 +---------------------------+ | | | Outer IP Header | | | +------+--------------------+ | Sel. | VPN-OUI | +------+--------------------+ | VPN index | +---------------------------+ | | | Inner IP Header | | | +---------------------------+ | | | | | IP Payload | | | | | +---------------------------+ Figure 3: Private IP-IP Encapsulation Format (Case 2) Outer IP Header: as in [RFC 2003] Sel.: Selector, value to be allocated by IANA: tentatively: 0xE0 (= explicitly indicated source / destination address, same addressing realm) VPN-OUI, VPN index: as in [RFC 2685] (refers to both source and destination IP address) In addition to the format specified above, the format specified in section 3.3.5 below MAY instead by used in certain cases. 3.3.3 Default Source Adress, Explicit Destination Address If only the destination address is to be indicated explicitly, the following encapsulation format MUST be used: Petri [Page 8] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 +---------------------------+ | | | Outer IP Header | | | +------+--------------------+ | Sel. | VPN-OUI | +------+--------------------+ | VPN index | +---------------------------+ | | | Inner IP Header | | | +---------------------------+ | | | | | IP Payload | | | | | +---------------------------+ Figure 4: Private IP-IP Encapsulation Format (Case 3) Outer IP Header: as in [RFC 2003] Sel.: Selector, value to be allocated by IANA: tentatively: 0xE1 (=default source, explicitly indicated destination) VPN-OUI, VPN index: as in [RFC 2685], refers to destination only 3.3.4 Explicit Source Adress, Default Destination Address If only the source address is to be indicated explicitly, the following encapsulation format MUST be used: Petri [Page 9] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 +---------------------------+ | | | Outer IP Header | | | +------+--------------------+ | Sel. | VPN-OUI | +------+--------------------+ | VPN index | +---------------------------+ | | | Inner IP Header | | | +---------------------------+ | | | | | IP Payload | | | | | +---------------------------+ Figure 5: Private IP-IP Encapsulation Format (Case 4) Outer IP Header: as in [RFC 2003] Sel.: Selector, value to be allocated by IANA: tentatively: 0xE2 (=explicitly indicated source, default destination) VPN-OUI, VPN index: as in [RFC 2685], refers to source only 3.3.5 Explicitly Indicated Source and Destination Address (Different Realms) If both the source and the destination address are to be indicated explicitly, and belong to different addressing realms, the following encapsulation format MUST be used: Petri [Page 10] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 +---------------------------+ | | | Outer IP Header | | | +------+--------------------+ | Sel. | VPN-OUI (S) | +------+--------------------+ | VPN index (S) | +---------------------------+ | Pad | VPN-OUI (D) | +------+--------------------+ | VPN index (D) | +---------------------------+ | | | Inner IP Header | | | +---------------------------+ | | | | | IP Payload | | | | | +---------------------------+ Figure 6: Private IP-IP Encapsulation Format (Case 5) Outer IP Header: as in [RFC 2003] Sel.: Selector, value to be allocated by IANA: tentatively: 0xE3 (=explicitly indicated source and destination, different addressing realm) VPN-OUI (S), VPN index (S): as in [RFC 2685], refers to source Pad: Pad field (inserted for 32-bit alignment), this field MUST be coded as 0x00, and is ignored on receipt) VPN-OUI (D), VPN index (D): as in [RFC 2685], refers to destination 4. Example: A Mobile Node Registers at its Home Agent This section provides an example illustrating how the formats specified in section 3 above can be applied. In this example, a mobile node MN has obtained a temporary private IP address within a private IP address realm PR2, where it is currently located. It now wants to register this address with its home agent HA which owns a private IP address within realm PR3. Petri [Page 11] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 priv. realm PR2 public IP (or PR4) private realm PR3 | | | MN ---> border gateway A ------> border gateway B ---> HA (BG A) (BG B) Figure 7: Example for encapsulation of private IP in IP Since PR3 is different from PR2, the following Private IP in IP Encapsulation (PIPE) formats are used on the way from MN to HA: Step 1: From MN to BG A: Outer Header: Source Address: MN(PR2) Destination Address: BG A(PR2) Inner Header: Source Address: MN(PR2) = default Destination Address: HA (PR3) Selector: 0xE1 (explicitly indicated destination) Step 2: From BG A to BG B: Outer Header: Source Address: BG A(public IP or PR4) Destination Address: BG B(public IP or PR4) Inner Header: Source Address: MN (PR2) Destination Address: HA (PR3) Selector: 0xE3 (explicit source and destination, different address realms) Step 3: From BG B to HA: Outer Header: Source Address: BG B(PR3) Destination Address: HA(PR3) Inner Header: Source Address: MN(PR2) Destination Address: HA(PR3) = default Selector: 0xE2 (explicitly indicated source) It should be noted that in addition to the formats illustrated above, a real transfer of a packet from MN to HA also involves a number of routing decisions, and address resolution functions which are outside the scope of this specification, and may perhaps be specified in separate drafts. In the example above, the use of the public Internet as a backbone to interconnect the address realms PR2 and PR3 seems to be a natural Petri [Page 12] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 choice, but another private realm (PR4) might also be suitable for that purpose. The selection of a transit backbone or a particular address resolution may be subject to different criteria, and/or may be dependent on particular applications. 5. Security Considerations IP encapsulation potentially reduces the security of the Internet, and care needs to be taken in the implementation and deployment of IP encapsulation. More detailed considerations of security implications of IP-IP tunnels can be found in section 6 of [RFC 2003]. Since private addresses are typically administered to prevent access to networks inside an enterprise, the transfer of private addresses across networks outside this enterprise must be handled with great care. It may be required to use authentication and possibly encryption to maintain the existing security policy which originally dictated the choice of using a private address space within the enterprise. 6. IANA Considerations It is proposed that IANA establishes and maintains a list of protocol values for the selector byte following the outer IP header. The following values are an example for this possible list: 0x00 through 0xDF as for corresponding IP version number and header field 0xE0 - 0xE3 as defined in this specification 0xE4 - 0xFF reserved In addition, the formats for private IP-IP encapsulation specified in this document require the allocation of a new value in the "Protocol" field (identifying the next header) within the IPv4 header, (e.g.: 129 PIPE Private IP-IP Encapsulation .... ). 7. IPR Considerations Siemens may own intellectual property on some of the technologies described in this document. References [RFC 1918] Rekhter, Y. et al., "Address Allocation for Private Internets", RFC 1918, Febr. 1996 [RFC 2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996 Petri [Page 13] INTERNET-DRAFT Private IP-IP (PIPE) Expires July 2000 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks Identifier", RFC 2685, September 1999. Author Information Bernhard Petri Siemens AG Hofmannstr. 51 Munich, Germany, D-81359 phone: +49 89 722-34578 email: bernhard.petri@icn.siemens.de Petri [Page 14]