Mobile IP Working Group Pat Calhoun INTERNET DRAFT Gabriel Montenegro Category: Standards Track Charles Perkins Title: draft-ietf-mobileip-calhoun-tep-01.txt Sun Microsystems, Inc. Date: March 1998 Tunnel Establishment Protocol draft-ietf-mobileip-calhoun-tep-01.txt Status of this Memo This document is a submission by 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 (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract A general tunnel establishment protocol (TEP) is defined to handle multi-protocol tunneling as well as multilevel domains guarded by tunnel agents which may be thought of as security gateways, or alternatively as modified foreign agents defined by with Mobile IP. Mobile IP provides the model for TEP; the registration messages in RFC 2002 establish a tunnel between the home agent and the foreign agent. Calhoun, Montenegro, Perkins expires September 1998 [Page 1] INTERNET DRAFT March 1998 1. Introduction Tunnels are needed for a variety of reasons in the Internet. Two nodes may wish to communicate by using protocol data units (PDUs) for protocols other than IP that are not easily routed over the Internet infrastructure. Such PDUs can, however, be transmitted over the Internet encapsulated within IP. For remote access, one might wish to set up a secure tunnel between a current point of attachment and a enterprise network. Mobile IP (RFC 2002) [9] requires the creation of a tunnel so that the home agent can transmit IP datagrams to the care- of address of the mobile node. All of these separate needs share a common need for tunnel establishment and management, which can be fulfilled by enhancements of the tunnel establishment procedures specified in RFC 2002 [9], and the tunnel management procedures specified in RFC 2003 [7]. This document specifies those enhancements. Currently, Mobile IP lacks flexibility in how registrations are accomplished in that it assumes that the endpoints of the tunnel are mutually trusting entities that are able to and willing to exchange registration protocol packets. Furthermore, it assumes that the mobile node creates the Registration Request. TEP addresses these issues by allowing the creation of compound tunnels. TEP recognizes that in addition to tunnel endpoints, there may be tunnel intermediate points. Registrations are exchanged only between intermediate points. The result is a composite tunnel with some very desireable security and scalability characteristics: - Different security domains interface at an intermediate point, which provides a clean separation between segments. - Movement beyond a certain intermediate point only implies re-registrations from that point onward. This document draws on several previous documents -- notably "Integrated Mobility Extension" [4], "Virtual Tunneling Protocol (VTP)" [1], and "Tunnel Set-up Protocol" [5]. 1.1. Terminology This document uses the following terms: Binding An association between a mobile node's address and the IP address of a Tunnel Agent nearer to the mobile node. Chained Registration Calhoun, Montenegro, Perkins expires September 1998 [Page 2] INTERNET DRAFT March 1998 A registration in which the home agent and the mobile node do not directly exchange a Registration Request and Reply. Rather, the request/reply is carried out between endpoints of tunnel segments. The composition of tunnel segments represents the compound tunnel from home agent to mobile node. Downstream Agent The endpoint of a tunnel segment that is closer to the mobile node. The last downstream agent may be the mobile node itself or its foreign agent. Home Agent The tunnel agent which terminates the tunnel, and which encapsulates datagrams to be sent to the mobile node. Mobile Node The node on whose behalf the tunnel is established. SPI Acronym for "Security Parameters Index". The combination of a destination address, and an SPI uniquely identifies a security association. The SPI is carried Registration Requests and Replies to enable the receiving system to select the SA under which a received packet will be processed. An SPI has only local significance, as defined by the creator of the SA (usually the receiver of the packet carrying the SPI); thus an SPI is generally viewed as an opaque bit string. However, the creator of an SA may choose to interpret the bits in an SPI to facilitate local processing. Surrogate Agent A tunnel agent establishing a tunnel on behalf of a mobile node which does not take any active role in the establishment process. Surrogate Registrations These are registrations that are not created by the mobile node. Rather, they are created on its behalf by another entity (a foreign agent). This is not a new concept and is in use in commercial implementations. Nevertheless, with its introduction of chained registrations and compound tunnels, this document allows for registrations that neither originate at the mobile node (i.e. they start off as surrogate registrations), nor do they terminate at the home agent (i.e. they terminate at an Calhoun, Montenegro, Perkins expires September 1998 [Page 3] INTERNET DRAFT March 1998 intermediate point at least one tunnel away from the home agent). Targeted Tunnel Agent The ultimate intended recipient for a Tunnel Establishment Request. Tunnel Agent An agent which can perform encapsulation and decapsulation Tunnel Requestor Either a mobile node, or a surrogate agent acting on its behalf. Upstream Agent The endpoint of a tunnel segment that is closer to the home agent. The last upstream agent is the home agent itself. Notice that in this document, the term "mobile node" is used to help understanding. There is no protocol dependence upon the fact that the node is mobile, but we so far have not been very successful in finding suitable terminology. The previous term we had used in this document was "PDU receiver". Similarly, what was previously called the "encapsulator" is now called a home agent. Finally, what was previously called the "decapsulator" is now called the "foreign agent", and is a tunnel agent capable of forwarding decapsulated PDUs from the home agent to the mobile node. 1.2. Design Goals One of the main objectives in defining TEP is to support Mobile Network Computers [11]. Given that these devices are meant to be very lightweight and to keep as little state as possible, TEP's design goals are: - Simplicity. TEP only defines the minimum required to support the additional applications and target devices. Surprisingly little needs to be specified in order to adapt Mobile IP to serve as a remote access mechanism based on layer 3 forwarding. - Reusability. Calhoun, Montenegro, Perkins expires September 1998 [Page 4] INTERNET DRAFT March 1998 Unless otherwise specified, TEP adopts packet formats and protocol behavior as specified by Mobile IP. This results in one protocol that solves mobility and remote access. - Security. Given the nature of remote access, security associations are required of entities exchanging Registration Protocol packets over public sectors of the internet. Privacy and authentication of data transfer is also a requirement in these conditions, and is accomplished by using ESP [12] and optionally using AH [13]. 2. Overview of tunnel establishment Mobile IP [9] is a tunnel between the home agent and the foreign agent, on behalf of a mobile node. In the Tunnel Establishment Protocol (TEP), the protocol methods used by Mobile IP are modified to work between arbitrary nodes. When a tunnel is established, the upstream agent (called the home agent) then transmits PDUs to the tunnel endpoint (called the foreign agent) according to the tunnel establishment parameters. Generally, the tunnel establishment parameters include a network address of the node for which the tunnel is being established, called the mobile node. The foreign agent may then use any of a variety of methods, to further transmit the decapsulated PDU so that it can be received by the mobile node (one mechanism which is defined in this document). If the mobile node is the same node as the foreign agent, then no further network operations are needed to deliver the PDU. When the home agent obtains a PDU that needs to be transmitted to the mobile node, the home agent consults a table to determine the appropriate tunnel endpoint for that mobile node. In the case of mobile IP, the table is indexed by the mobile node's IP address. This document specifies ways to allow the table to be indexed by other network-layer addresses. Additionally, each table entry will contain other necessary parameters associated with the tunnel as part of the establishment process. The act of creating or updating the table entry which contains all of the parameters associated to the tunnel is called tunnel establishment, or just establishment. Note that a binding is the equivalent of a row (entry) in the table. The procedures in this document deal with the actions of four separate TEP entities, as outlined above, called the home agent, the foreign agent, the gateway foreign agent, and the mobile node. For simplicity, it is assumed that all home agents can also perform decapsulation and vice versa. A tunnel agent is thus a node that can perform the functions of either the home agent or the (gateway) foreign agent, and tunnels are said to be established between two tunnel agents. The Calhoun, Montenegro, Perkins expires September 1998 [Page 5] INTERNET DRAFT March 1998 foreign agent and mobile node may be the same node. This document does not specify means by which a mobile node discovers a suitable tunnel endpoint (foreign agent) which can be used for the tunnel establishment. An example of one such method, by which a mobile node (receiving IP data units) discovers a tunnel endpoint called a care-of address, is specified as part of the Mobile IP protocol, and consists of a straightforward modification of the Mobile Service Extension to the ICMP Router Discovery protocol [2], as specified in Mobile IP [9]. This extension will soon be specified in a companion document. This document assumes that each tunnel endpoint will be equipped with an IP address. If the establishment completes successfully, the foreign agent becomes one endpoint of a GRE tunnel [3]. The other endpoint is the home agent. Once the tunnel is established, it provides IP (network layer) connectivity between the two tunnel agents. The tunnel appears to be a virtual point-to-point link, and encapsulated PDUs traverse the tunnel as if it were a single link. This document defines new extensions which are used with the existing Mobile IP message types as defined in [9]. Tunnel establishment requires authentication. The tunnel establishment messages use some of the authentication extensions defined by [17]. This security association between receiver and home agent may require additional security mechanisms such as encryption which are not part of the tunnel establishment, but which affect the format of the encapsulated datagrams which flow through the tunnel. Intermediate nodes which are involved with the tunnel establishment may additionally impose their own authentication and privacy requirements. Such nodes follow the dictates of their security associations with the other nodes with which they communicate in the course of managing the established tunnel, but the security associations or the use of them are established by policy which is external to TEP. A requesting foreign agent MAY use procedures that are not specified in this document to obtain all tunnel establishment parameters, including authentication information for the mobile node, for use in the Registration Request message. Alternatively, the mobile node MAY (as is the case with mobile IP) transmit a Registration Request message to a prospective tunnel endpoint to enable that node to transact a tunnel establishment with some home agent. TEP specifies that the downstream agent issue the Registration Request message as surrogate for the mobile node. This MAY happen as a result of protocol operations transacted between the foreign agent and the mobile node. The downstream agent could, on the other hand, be configured by any convenient means to have all the necessary tunnel Calhoun, Montenegro, Perkins expires September 1998 [Page 6] INTERNET DRAFT March 1998 establishment parameters needed to issue a request message on behalf of the mobile node. TEP makes no restriction on the methods by which the foreign agent discovers the establishment parameters. 2.1. Chained Registrations Base Mobile IP assumes that the foreign agent is directly reachable from the home agent. In many situations this is not possible or desirable. For example, if the foreign agent belongs to an ISP, or a wireless carrier, it is not desirable to allow it direct reachability to a system (the HA) that "lives" within the private network. A much more secure configuration is to allow the ISP's system to directly reach only as far as the private network's gateway or firewall. These two systems need to share some mutual trust, particularly if using surrogate registrations. Another separate trust relationship is then built between the gateway or firewall system, and the home agent inside the private network. Notice that by introducing this intermediate system there is a very clean separation between external and internal systems security domains. This configuration is possible because of the use of chained registrations, whereas usual registration requests flow directly from the mobile node to the home agent [15]. 2.2. Surrogate Registrations Surrogate registrations are composed on behalf of a given node by another node. Consider the following network: MN@COA ---------------------- GFA ----- HA where the mobile node has acquired a co-located address (COA). Assume that the mobile node is not allowed to exchange packets directly with its home agent within the private network. Instead, it sends a Registration Request to the gateway foreign agent (GFA) as follows: MN@COA, home agent = GFA. The gateway foreign agent is not, of course, the mobile node's home agent. Nevertheless, it has knowledge or can obtain knowledge (perhaps after consulting a RADIUS database) of the mobile node's home agent. It then composes a Registration Request aimed at establishing a tunnel with the home agent: MN@GFA, home agent = HA. Calhoun, Montenegro, Perkins expires September 1998 [Page 7] INTERNET DRAFT March 1998 From the home agent's point of view, this registration request is almost indistinguishable from what it would have received from the MN directly. Notice that when the mobile node roams within the private network, mobility is probably accomplished without surrogate registrations. Hence, Registration Requests like the above are sometimes sent directly by the mobile node to the home agent. 2.3. Regionalized Tunnel Management The use of Hierarchical Foreign Agent Extension as defined in [6] provides TEP with a method to support mobile nodes accessing their private home networks from a private foreign network. +------------------------------------+ | Private Foreign Network | | +------+ +------+ +-------+ | | | MN |---| FA |------| PFA | | | +------+ +------+ +---+---+ | | | | +------------------------------|-----+ +-------|--------+ | | | | Public Network | | | | +-------|--------+ | +------------------------------|-----+ | Private Home Network | | | +------+ +---+---+ | | | HA |------| PHA | | | +------+ +-------+ | | | +------------------------------------+ The above diagram provides an example of a mobile node that belongs to a private network (NET 10) and temporarily visiting a foreign private network (NET 10). In this example the mobile node receives an advertisement from the FA with the PFA's public IP address. The mobile node issues a Registration Request to the FA with the home agent set to the PHA's public address, which in turn adds a Hierarchical Foreign Agent Extension indicating its address and forwards the request to the PFA. The PFA keeps track of the mobile node's current point of attachement as indicated in the hierarchical foreign agent extension and removes the extension. The request is then forwarded to the PHA. The PHA performs a lookup either locally or through the use of an Calhoun, Montenegro, Perkins expires September 1998 [Page 8] INTERNET DRAFT March 1998 external AAA Policy Server in order to determine the mobile node's true home agent. Once found, the PHA adds a hierarchical foreign agent extension to the request and forwards the request to the HA. The HA is now aware that the mobile node is reachable through the PHA and will reply back directly to the PHA. The PHA will forward the reply back to the PFA, which will in turn forward the request to the FA. The FA then uses the MN's link layer address in order to forward the reply to it. 3. Dynamic Home Address Discovery It is possible for a mobile node to not have a permanently assigned IP address. This is the default operating condition for a Mobile Network Computer. 3.1. Registering over the Internet When a Mobile Network Computer tries to register over the internet, it may not have a valid IP address (because it is booting instead of resuming, or because its lease ran out). TEP defines a home address discovery mechanism akin to the home agent discovery mechanism defined by Mobile IP. In both cases, a registration denial carries the necessary information (see Section 6). 3.2. Registering within the Corporation In this case, the Mobile Network Computer boots using the Network Computer model of obtaining its operating parameters from a DHCP server. One of the parameters received is the IP address to be used. The Mobile Network Computer must make sure that it receives an IP address valid for roaming as a Mobile IP node, i.e. it must be an address that a home agent is willing to provide forwarding service to [14]. The home agent could also be communicated using DHCP, or it could be discovered using the home agent discovery mechanism in [9]. 4. Payload Encapsulation There are two methods which may be used to encapsulate TEP payloads. IP in IP encapsulation [7] can be used to encapsulate an IP packet. However, TEP also adds multi-protocol support which can only be handled by encapsulating with GRE [3]. The encapsulation mechanism is negotiated during Mobility Registration and cannot be changed while a binding is active. Calhoun, Montenegro, Perkins expires September 1998 [Page 9] INTERNET DRAFT March 1998 4.1 Multi-Protocol Support and IP-only Foreign Agents There are two methods for foreign agents to support multi-protocol mobile nodes. One is to support all of the protocols requested and "route" multi-protocol packets based on the innermost destination address. However, it is envisioned that not all foreign agents will support protocols other than IP. Therefore in order for an IP only foreign agent to support multi-protocol, it is necessary to support the Tunnel Identifier extension. When a foreign agent receives a Registration Request from a mobile node, the foreign agent adds the Tunnel Identifier extension to the request. The foreign agent MUST insert a locally unique value within the most significant 16 bits of the Tunnel ID. When a home agent responds successfully to a Registration Request that included the Tunnel Identifier extension, it MUST insert a locally unique within the least significant 16 bits of the field. When the home agent receives a packet destined for the mobile node, it MUST include the negotiated Tunnel ID within the KEY field of the GRE header. Similarly, when the foreign Agent receives a packet from the mobile node it MUST include the Tunnel ID within the KEY field of the GRE header. If a Registration Request is sent to re-register an existing tunnel (which is presumably about to expire) it is recommended that the foreign agent includes the negotiated Tunnel ID in the Tunnel Identifier extension. 5. Security Model TEP uses the Key Registration mechanisms as defined in [17]. Specifically when a mobile node wishes to establish a tunnel, it includes the Foreign Agent Key Request extension within the Registration Request. Upon receipt the home agent includes a Foreign Agent Key Reply Extension and a Home-Mobile Key Reply Extension in the Registration Reply. 5.1. SPI Usage According to [9] and [19, 20] a given security association is indexed by the SPI (a 32-bit number), the destination address and the security protocol (for example AH, ESP or Mobility Security Associations). The first 256 SPI values are assigned by IANA, and the rest MUST be Calhoun, Montenegro, Perkins expires September 1998 [Page 10] INTERNET DRAFT March 1998 unique at the destination. There are several ways to assign the non- reserved SPIs: - the SPI is the result of some previous and fixed agreement between both parties, - the SPI is the result of a security association establishment procedure (for example [21] or assignment by a key-distribution center). Even if an SPI value has not been determined by either of the above procedures, secure communication may still be possible. In this case, the SPI value MUST be set to 0 [22]. This typically implies that the security association is being negotiated in-line using information found elsewhere within the datagram. This is similar to SKIP's in-line keying, although in this case the SPI value of 1 has been assigned by IANA [22]. Once this secure exchange is over, a non-reserved SPI MUST be assigned and used in subsequent messages. 6. Registration Request A Registration Request message is sent by the mobile node towards the foreign agent which forwards the request to the home agent. Unless otherwise specified by the 'G' bit, the requestor expects to receive PDUs encapsulated within an IP header. When the 'G' bit is set, the PDU is to be encapsulated within GRE, which can further be encapsulated within IP. Since TEP requires reverse tunnels, the Registration Request MUST have the reverse tunnel 'T' bit set [16]. The Registration Request MUST include an authentication extension appropriate to the targeted tunnel agent. The format of the authentication extension is identical to one of the extensions defined in the base Mobile IP specification, either a Mobile-Home Authentication Extension, or a Mobile-Foreign Authentication Extension. In the case of the Mobile-Foreign Authentication Extension the mobile node MAY use the SPI and Mobility Security Association set up when it obtained a session key (say, using Route Optimization extension numbers 104 and 105 [8]), from a previous Tunnel Parameters Extension it transacted with its home agent and all intervening foreign agents at that time. The relative order in which different extensions, when present, MUST be placed is defined in [9]. Calhoun, Montenegro, Perkins expires September 1998 [Page 11] INTERNET DRAFT March 1998 7. Registration Reply A tunnel agent returns a Registration Reply message to a tunnel requestor which has sent a Registration Request (Section 6) message The Registration Reply message contains the necessary codes to inform the tunnel requestor about the status of its Request, along with the lifetime granted by the targeted agent. When the foreign agent receives a successful Registration Reply, it updates its binding for the mobile node and forwards the reply to the mobile node. The multi-protocol network address(es) of the mobile node MUST be included in multi-protocol extension(s) within the Registration Reply as they appeared in the Registration Request. Unless specifically superseded in this document, all processing of Registration Replies by tunnel agents is specified to be the same as the processing by tunnel agents in the base mobile-IP draft specification [9]. This includes determining the validity of the Registration Request, and selecting the appropriate status code (from among those listed below) for the reply. The IP fields and UDP fields are chosen just as with the Registration Reply message in the base mobile-IP specification. The following value is available for use within the Code field in addition to the values defined in [9] and in the most recent "Assigned Numbers" [10]: 140 invalid home address Notice that the "invalid" home address (140) error may occur in two cases: 1. mobile node requires an address assignment, 2. mobile node's lease on its previous address has expired. An "invalid home address" denial carries the assigned home address in the home address field of the registration reply. 8. Multi-Protocol Extension This specification defines the Multi-Protocol Extension, which is found in Registration Request and Reply messages. This extension is denoted by the value of 128 in the extension field. 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 | EtherType | Calhoun, Montenegro, Perkins expires September 1998 [Page 12] INTERNET DRAFT March 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length |M| reserved | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ is encoded in the following Type-Length-Value format: Type TDB Length Indicates the length (in octets) of the data field within this Extension. The length does NOT include the Type and Length octets. EtherType The EtherType indicates which network layer protocol address is included in the Data field, and thus the particular type of tunnel to be registered with the home agent. Sub-Length The length of the data following the reserved field M(andatory) When the Mandatory bit is set, the Home Agent MUST support the requested extension in order to return a successful reply. Data Data in the particular format, specified in subsequent sections, needed for the establishment of tunnel appropriate for the Addr Family. Each Addr Family defines a protocol and address format. The values for the Addr Family are compatible with those defined by GRE [3]. The contents of the Data field depend on the particular network layer. For each value of the Addr Family, the format of the Data field is to be outlined in a subsequent Section. 8.1. IPX Calhoun, Montenegro, Perkins expires September 1998 [Page 13] INTERNET DRAFT March 1998 An IPX address is either 6 or 10 octets. If the target is an IPX host, the extension MUST supply its 6 octet IEEE 802 address. If the target is an IPX router, the extension MUST supply both its network number and node number (its IEEE 802 address). This extension is OPTIONAL and must be present only if the client being registered supports IPX. This extension may be sent to register a new client on an existing tunnel even if the initial tunnel establishment request did not register IPX support. Many instances of this extension may be present in a registration request in the case that several IPX addresses are to be registered. In this case, a conventional router or dial-up router is serving multiple IPX addresses in the remote LAN. The format of the extension is: 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 | EtherType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length |M| reserved | IPX Network Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPX Network Number (cont.) | IPX Node Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPX Node Number (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Routing Support| +-+-+-+-+-+-+-+-+ EtherType 8137h (IPX) Sub-Length 12 (the length of the Data field) M(andatory) The Mandatory bit MUST be set reserved MUST be zero Calhoun, Montenegro, Perkins expires September 1998 [Page 14] INTERNET DRAFT March 1998 IPX Network This field contains the IPX Network number of the remote client (as negotiated by IPXCP for a dial-up user). IPX Node Number This field contains the IPX Node number of the remote client. IPX Routing Flag It is possible to enable a routing protocol over an existing tunnel only if one was not already negotiated. The following routing protocols may be used over the tunnel by setting the following values: IPX_RIP 0x0001 NLSP 0x0002 IPXWAN_2 0x0004 8.2. AppleTalk Address Extension An AppleTalk address is three octets. If the target does not yet have an AppleTalk address, the tunnel endpoint should use the address 0.0 (three octets of all zeros). 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 | EtherType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length |M|Z| reserved | Appletalk Network | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node number | Zone | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EtherType 809Bh (Ethertalk - Appletalk) Sub-Length 5 or 7 (the length of the Data field) Calhoun, Montenegro, Perkins expires September 1998 [Page 15] INTERNET DRAFT March 1998 M(andatory) The Mandatory bit MUST be set Z(one) If set, the Zone field is present Appletalk Network Two octets for the Appletalk network number Node number One octet for the Appletalk node number Zone If present, an unsigned integer indicating the Zone in which the Appletalk Address is located. 8.3. Vines Address Extension A Vines address is either 6 or 10 octets. If the target is a Vines host, it MUST supply its 6 octet Vines address (normally an IEEE 802 address). If the target is a Vines router, it MUST supply both its Vines address and the subnet number. 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 | EtherType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length |M| reserved | Vines Node Number ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Vines Node Number, continued. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vines subnet Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EtherType 0BADh (Vines) Calhoun, Montenegro, Perkins expires September 1998 [Page 16] INTERNET DRAFT March 1998 Sub-Length 12 (the length of the Data field) M(andatory) The Mandatory bit MUST be set reserved MUST be zero Vines Node Number This field contains the Vines Node number of the remote client. Vines Network This field contains the Vines Network number of the remote client. 8.4. CLNP Address Extension CLNP uses NSAPs as its addresses, which are of variable length. If the target knows its NET (NSAP with an NSEL of 0), it MUST Include its NET in the extension. Targets which do not know their NET May specify a zero length address. 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 | EtherType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length |M| reserved | NSAP ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ EtherType 00FEh (OSI) Sub-Length 12 (the length of the Data field) Calhoun, Montenegro, Perkins expires September 1998 [Page 17] INTERNET DRAFT March 1998 M(andatory) The Mandatory bit MUST be set reserved MUST be zero NSAP Network address for use by NSAP 9. Tunnel Establishment Protocol Extensions This section contains several optional TEP extensions which MAY be used during the registration process. 9.1. Client-Identifier Extension The Client-Identifier Extension contains the user or hosts name in the format defined in [18] and serves two purposes. First and foremost, this extension MAY be used by intermediate foreign agents in order to identify a user's domain for authentication, authorization and accounting purposes. When a foreign agent receives a TEP request, it can form an Authentication/ Authorization request and forward the request to its AAA Server to see if the local policy authorizes the mobile node to use the services requested. Simply using an IP address is problematic since it does not necessarily identify the user's domain. The Client-Identifier Extension is also used if the mobile node is requesting dynamic home address discovery. In this case since the home address is set to zero (0) the foreign agent can only rely on the ID field, which is not guaranteed to be unique across multiple mobile nodes. The Client-Identifier does provide sufficient information for the foreign agent (or downstream agent) to uniquely identify the mobile node. The home agent (or upstream agent) MUST return this identifier in the Registration Reply for the foreign agent to be able to resolve which mobile node it is intended for. The Client-Identifier Extension defined below serves this purpose. The Client-Identifier Extension MUST appear before the TEP-required Foreign-Home Authentication Extension. It SHOULD appear immediately before it. Calhoun, Montenegro, Perkins expires September 1998 [Page 18] INTERNET DRAFT March 1998 As per section 1.9 of [9], the type value of TDB implies that if a node encounters a Client-Identifier Extension in a Registration Request or Reply, it MAY silently ignore it. This implies that home agents that comply with Mobile IP, but are unaware of the TEP extension MAY still be used, as long as the mobile node does not attempt home address discovery. TEP home agents that support Mobile Network Computers MUST understand the Client-Identifier Extension and return it in its replies. The reason is that Mobile Network Computers may attempt to register using a certain home address whose DHCP lease may have expired. Furthermore, two or more Mobile Network Computers may attempt to use the same home address. Without the Client-Identifier Extension the foreign agent (or downstream agent) may be unable to resolve the conflict. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client-Identifier... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Length 8 Reserved 0 Client-Identifier Contains the Client's username or host name in the format defined in [18]. 9.2. VPN Identifier Extension The VPN Identifier Extension has no significance when the Home Agent belongs to the MN's home network. However there are current services already deployed which allow service providers to own the HA and share Calhoun, Montenegro, Perkins expires September 1998 [Page 19] INTERNET DRAFT March 1998 it among many customers. There are some obvious security considerations since the service providers want to ensure that these customers cannot access each other's networks through the shared HA. The VPN Identifier allows the shared HA to know which domain a mobile node belongs to, and furthermore only permits routing of the mobile node's packet to routes which are tagged with the same VPN Identifier. Implementation details of how a shared HA can handle routes for multiple domains is outside the scope of this specification. The optional VPN Identifier extension MAY be present in a Registration Request. If present the VPN Identifier MUST be returned in the Registration Reply (even if not used by the HA). 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Name... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Length >8 Reserved 0 VPN Identifier The VPN Identifier is a numerical representation of a domain. This identifier is assigned by the service provider and must be unique within the mobile network. It is common for a foreign agent to retrieve this value from an authentication service such as RADIUS. Calhoun, Montenegro, Perkins expires September 1998 [Page 20] INTERNET DRAFT March 1998 VPN Name This optional field contains the ASCII representation of the VPN identifier (i.e. ABC.COM). The length of the field is computed using the length (less the size of the VPN Identifier field). 9.3. Dynamic-Connection Extension The Dynamic Connection Extension is used when a service provider provides a Gateway Foreign Agent or a Home Agent within its network and the link to the customer network is over a WAN. The information contained in this extension should be sufficient in order for the GFA or HA to communicate or establish a link with the CPE device. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Type | Address... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TDB Length >8 Reserved 0 Link Type The Link Type field contains a numerical representation of the underlying link to use in order to connect to the CPE device. The following have already been defined: VTP_FR_PVC 0x0001 When set, the address refers to a Frame Relay Permanent Virtual Circuit. Calhoun, Montenegro, Perkins expires September 1998 [Page 21] INTERNET DRAFT March 1998 VTP_FR_SVC 0x0002 When set, the address refers to a Frame Relay Switched Virtual Circuit. VTP_ATM_PVC 0x0003 When set, the address refers to an ATM Permanent Virtual Circuit. VTP_ATM_SVC 0x0004 When set, the address refers to an ATM Switched Virtual Circuit. VTP_X25_PVC 0x0005 When set, the address refers to a X.25 Permanent Virtual Circuit. VTP_X25_SVC 0x0006 When set, the address refers to a X.25 Switched Virtual Circuit. Address A link layer address that the GFA or HA uses in order to communicate or establish a link with the CPE device. The length of the address field is determined by the length field (less the size of the reserved and link type field). 9.4. Tunnel-Identifier Extension The optional Tunnel Identifier MAY be added in a Registration Request by the foreign agent. This extension MUST NOT be used if IP-in-IP encapsulation is requested. The Tunnel Identifier added by the foreign agent MUST include a locally unique value in the most significant 16 bits. The home agent MUST include a locally unique value within the least significant 16 bits. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Montenegro, Perkins expires September 1998 [Page 22] INTERNET DRAFT March 1998 Type TDB Length >8 Reserved 0 Tunnel ID The Tunnel Identifier contains the GRE session ID. This identifier is used within each GRE header to indicate the session associated with with the payload. 10. Hierarchical Foreign Agent Extension One or more Hierarchical Foreign Agent Extension MAY be present in a Registration Request or Reply. If more than one Hierarchical Foreign Agent Extension is present, the order of these extensions MUST be maintained through the hierarchy. When replying with a Registration Reply, the Home Agent MUST ensure that the order of the Hierarchical Foreign Agent extensions are reversed. (PRC?!?) If the hierarchical Foreign Agent Extension is present in the Request, Each foreign agent MUST check to make sure that its address is Included in the list of tunnel agents. If not, it rejects the Request with a status code of 70. Otherwise, the foreign agent makes note of the address of the next lower-level tunnel agent, for future association with the mobile node's network address. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Level Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun, Montenegro, Perkins expires September 1998 [Page 23] INTERNET DRAFT March 1998 Type TDB Length 6 Reserved 0 Foreign Agent Address The IP Address of the next Foreign Agent in the hierarchy. 11. Mobile Node Considerations The tunnel requestor MAY also include at least one multi-protocol extension as well as Tunnel establishment extensions. Only one such extension MAY be included per additional network layer protocol. Note that a tunnel requestor may change which ethertypes are to be used by establishing a tunnel with different ethertype extensions in its establishment packets. If the mobile node receives a successful Reply message containing an Tunnel Establishment extension, the mobile node should immediately establish a GRE tunnel with the home agent as the other endpoint of the tunnel. Then, all data packets at the mobile node with a next hop of the home agent will be tunneled to the home agent using GRE over IP as the transport mechanism. This includes IP packets. Once the packet reaches the home agent, the outer header (IP) and GRE header are stripped and the packet is submitted for local processing, as appropriate for the particular network layer protocol. 12. Foreign Agent Considerations The foreign agent MUST copy the Tunnel Establishment extension from the Mobile Request to the Establishment Request without modifying it in any way. The foreign agent MUST NOT reject a Mobile Request due to the presence or contents of any well formed Tunnel Establishment or multi-protocol extensions. Foreign Agents that support IP only wishing to provide multi-protocol support MUST support the Tunnel Identifier extension. Calhoun, Montenegro, Perkins expires September 1998 [Page 24] INTERNET DRAFT March 1998 13. Home Agent Considerations The home agent MAY reject an Registration Request based on the contents of an multi-protocol or any other Tunnel Establishment extensions. If the home agent accepts a Registration Request with an multi-protocol extension, it MUST provide connectivity to the mobile node for the network layer protocol described in the multi-protocol extension. Further, the multi-protocol extensions MUST be copied into the Reply message. If the home agent accepts a Registration Request with an Integrated Mobility extension, the request MUST also have a Local Care-Of Address extension. The home agent MUST use the Local Care-Of Address as the tunnel endpoint and MUST establish a GRE tunnel to the Local Care-Of Address. Once the GRE tunnel is established, a PDU arriving at the home agent for the mobile node will be tunneled to the receiver using GRE over IP as the transport mechanism. Note that this includes IP packets. Once the packet reaches the mobile node, the outer header (IP) and GRE header are stripped and the packet is submitted for local processing, as appropriate for the particular network layer protocol. 14. Security Tunnel establishment follows the design philosophy of the Mobile IP specification to provide accceptable authentication of the establishment process. This document does not discuss confidentiality of user data. Note that tunnel establishment often has the effect of controlling and possibly redirecting data streams to new points of attachment for the mobile node. Thus, failure to provide sufficient authentication of Registration Request messages can have the effect of allowing malicious disruption of traffic which is supposed to be received by the mobile node. Even failure to properly authenticate Registration Reply messages could have the effect of masking control or data errors in the establishment process. 15. Acknowledgements Acks anyone??? (PRC) 16. References [1] Pat R. Calhoun and Ellis Won. Virtual Tunneling Protocol (VTP). draft-calhoun-vtp-protocol-00.txt, July 1996. (work in progress). Calhoun, Montenegro, Perkins expires September 1998 [Page 25] INTERNET DRAFT March 1998 [2] Stephen E. Deering, Editor. ICMP Router Discovery Messages. RFC 1256, September 1991. [3] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic Routing Encapsulation (GRE). RFC 1701, October 1994. [4] T. Li and Y. Rekhter. Integrated Mobility Extension. draft-ietf-mobileip-integrated-00.txt, March 1994. (work in progress). [5] G. Montenegro. Tunnel Set-up Protocol (TSP). draft-montenegro-tsp-00.txt, August 1997. (work in progress). [6] C. Perkins. Mobile-IP Local Registration with Hierarchical Foreign Agents. draft-perkins-mobileip-hierfa-00.txt, February 1996. (work in progress). [7] Charles Perkins. IP Encapsulation within IP. RFC 2003, May 1996. [8] Charles E. Perkins and David B. Johnson. Route Optimization in Mobile-IP. draft-ietf-mobileip-optim-07.txt, November 1997. (work in progress). [9] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. [10] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, October 1994. [11] Mobile Network Computer Reference Specification, June 1997. http://www.internet.ibm.com/computers/networkstation/os/mncrs.html [12] S. Kent, R. Atkinson. IP Encapsulating Payload -- work in progress, draft-ietf-ipsec-esp-v2-00.txt, July 1997 (obsoletes RFC 1827, August 1995). [13] S. Kent, R. Atkinson. IP Authentication Header -- work in progress, draft-ietf-ipsec-auth-header-01.txt, July 1997 (obsoletes RFC 1826, August 1995). [14] S. Alexander, R. Droms. DHCP Options and BOOTP Vendor Extensions. RFC 2132. [15] V Gupta, S. Glass. Firewall Traversal for Mobile IP: Guidelines for Firewalls and Mobile IP entities. draft-ietf-mobileip-firewall-trav-00.txt, March 1997. (work in progress). [16] G. Montenegro. Reverse Tunneling for Mobile IP. Calhoun, Montenegro, Perkins expires September 1998 [Page 26] INTERNET DRAFT March 1998 draft-ietf-mobileip-tunnel-reverse-05.txt, January 1998. (work in progress). [17] C. Perkins, D. Johnson. Registration Keys for Route Optimization. draft-ietf-mobileip-regkey-00.txt. November 1997. (work in progress). [18] B. Aboba, M. Beadles. Network Address Identifier. draft-ietf-roamops-nai-10.txt, February 1998. (work in progress). [19] Atkinson, R., "IP Authentication Header", RFC 1826, Naval Research Laboratory, August 1995. [20] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, Naval Research Laboratory, August 1995. [21] Harkins, D., Carrel, D., The Internet Key Exchange (IKE), February 1998, Internet-draft draft-ietf-ipsec-isakmp-oakley-06.txt (work in progress). [22] Assigned numbers for Security Parameters Index. Available at: http://www.isi.edu/in-notes/iana/assignments/spi-numbers 17. Chairs' Addresses The working group can be contacted via the current chairs: Jim Solomon Motorola, Inc. 1301 E. Algonquin Road Schaumburg, IL 60196 USA Voice: +1-847-576-2753 Fax: +1-847-576-3240 E-Mail: solomon@comm.mot.com Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK17-202 Mountain View, California 94303 Phone: +1 650 786-5166 Fax: +1 650 786-5896 E-Mail: erik.nordmark@eng.sun.com Calhoun, Montenegro, Perkins expires September 1998 [Page 27] INTERNET DRAFT March 1998 17. Author's Address Questions about this memo can be directed to: Pat R. Calhoun Technology Development Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-847-548-9587 Fax: 1-650-786-6445 E-mail: pcalhoun@toast.net Gabriel E. Montenegro Technology Development Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-650-786-6288 Fax: 1-650-786-6445 E-mail: Gabriel.Montenegro@Eng.Sun.Com Charles E. Perkins Technology Development Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-650-786-6464 Fax: 1-650-786-6445 E-mail: Charles.Perkins@Eng.Sun.Com Appendix A. Example of an IPX Mobile Node A Mobile Node which desired IPX connectivity in addition to IP connectivity would include an extension of the form: 0x?? 0x06 0x81 0x37 0x00 0x00 0x0c 0x01 0x0e 0x36 0x00 0x00 This indicates an extension of TDB [0x??] (Tunnel Establishment), a data length of 6 octets, an ethertype value of 0x8137 (IPX), and an IEEE 802 address of 00:00:0c:01:03:36. The final two octets of 0x00 Calhoun, Montenegro, Perkins expires September 1998 [Page 28] INTERNET DRAFT March 1998 are sent so that the extension terminates on a four- octet boundary, in accordance with the IP Mobility RFC. Appendix B. TEP as a Mobile Remote Access Solution Chained registrations flow in separate steps which together build one compound tunnel. For example, assuming there is only one intermediate point (or "traversal point"), labelled GFA ("gateway foreign agent"), this is how the chained registration would work: EXAMPLE: TEP for Mobility and Remote Access MN -- FA ---------------------- GFA ----- HA A. The MN sends a registration request to the FA with the following information: name: MN care-of address: FA home agent: GFA B. The FA then forwards this registration to the "home agent", i.e. to GFA. Notice that GFA is not a home agent in the traditional sense, because it's address and MN's do not belong to the same subnet. Also notice that the FA could have composed the above registration on behalf of the MN (the so-called "surrogate registration"). At any rate, whoever composes the registration request must share a secret with GFA, as this is needed to fill correctly the authenticator field of the registration request (not shown above). C. GFA verifies the authentication for this registration and fetches the information contained therein. It notices that it is listed as the home agent for the MN, which is not really true. However, it checks its database, and obtains information that MN's real home agent is HA, with which it can engage in yet another authenticated registration protocol exchange ("chained registration"). GFA sends the following registration to HA: name: MN care-of address: GFA home agent: HA Notice two things: 1. This registration is composed by the GFA on behalf of the MN, so it is a surrogate registration. Calhoun, Montenegro, Perkins expires September 1998 [Page 29] INTERNET DRAFT March 1998 2. If GFA is indeed the home agent for the mobile node at this point Remote Access has been accomplished. D. HA verifies the authentication for this registration and notices that it is indeed valid (it is possible for HA and GFW to use a shared secret different from the one used by HA and MN). It then establishes a "tunnel" (i.e an IP forwarder) of MN's packets to GFA. Once this chained registration is in place, this is how data transfer may occur: A. A correspondent node, CN, sends a packet to the MN with the following IP header: IP source: CN IP destination: MN B. The packet arrives in the vicinity of HA, which intercepts and forwards it to GFA by prepending a new IP header like this: New IP source: HA New IP destination: GFA C. GFA receives the packet, recovers the original packet: IP source: CN IP destination: MN and notices that it has a binding or registration for MN. This prompts GFA to forward the packet, this time with the following new IP header prepended to it: New IP source: GFA New IP destination: FA D. FA obtains the packet, recovers the inner, original packet: IP source: CN IP destination: MN and notices that is has a binding or registration for MN. This time, it just forwards without any additional headers because MN is directly reachable. E. MN receives the packet: IP source: CN IP destination: MN Calhoun, Montenegro, Perkins expires September 1998 [Page 30] INTERNET DRAFT March 1998 which from the point of view of its applications is exactly the same packet they would have received if MN had been in its office. Thus mobility is transparent. Appendix C. Registering Without a Permanent Home Address Assume that the mobile node is a Mobile Network Computer, and as such, does not have a permanent home address. If at home, it typically acquires an address via DHCP for use during that session. The notion of session, however, does not necessarily imply a certain time limit. As long as the Mobile Network Computer renews its DHCP lease, it can continue to use the assigned address. If it reboots again, it will need a new address, but this is probably a very rare ocurrence. Instead of rebooting, what is customary is for a Mobile Network Computer to suspend its state and resume it at a later time. At that time, it will attempt to use the same address as it was using when it suspended its state. It's DHCP lease may have expired, or it may even ignore what to use as a home address. At this point, it establishes a presence on the public internet, perhaps by starting a PPP session with an ISP. It needs to obtain a new home address. This is what it knows: *1. the home prefix is known 2. HA is known 3. secret is known 4. care-of address is known *5. care-of address is co-located This is what it wishes to find out: 1. MN home address The mobile node issues this Registration Request: IP fields: Source Address = co-located care-of address Destination Address = IP address of home agent Time to Live = 64 UDP fields: Source Port = Destination Port = 434 Registration Request fields: Type = 1 S=0,B=x,D=1,M=x,G=x Lifetime = 1800 (seconds) Home Address = the mobile node's home prefix Home Agent = IP address of mobile node's home agent Care-of Address = co-located care-of address Calhoun, Montenegro, Perkins expires September 1998 [Page 31] INTERNET DRAFT March 1998 Identification = timestamp Extensions: The Mobile-Home Authentication Extension The home agent sees that the home address field is not completely filled out, obtains a new address within the indicated prefix and returns it to the mobile node using this reply: Upon return: IP fields: Source Address = IP address of home agent Destination Address = co-located care-of address Time to Live = 64 UDP fields: Source Port = Destination Port = copied from src port or reg req Registration Reply fields: Type = 3 Code = 140 (invalid home address) Lifetime = 1800 (seconds) Home Address = the mobile node's newly assigned home address Home Agent = IP address of mobile node's home agent Identification = timestamp Extensions: The Mobile-Home Authentication Extension Notice that it is possible to discover both the home agent and the mobile node addresses: Now, this is what the Mobile Network Computer knows: *1. the home prefix is known *2. HA prefix is known 3. secret is known 4. care-of address is known *5. care-of address is co-located And this is what it wishes to find out: 1. HA address 2. MN home address It issues this Registration Request: Registration Request fields:.in 9 Type = 1 S=0,B=x,D=1,M=x,G=x Lifetime = 1800 (seconds) Home Address = the mobile node's home prefix Calhoun, Montenegro, Perkins expires September 1998 [Page 32] INTERNET DRAFT March 1998 Home Agent = directed broadcast to HA's prefix Care-of Address = co-located care-of address Identification = timestamp Extensions: The Mobile-Home Authentication Extension An initial reply with code 136 (unknown home agent address) tells the mobile node which home agent to use. Subsequently, the mobile node may discover its own home address. It must first discover the home agent address because the latter must be willing to provide some address allocation services on the mobile node's behalf. We could also use a separate foreign agent: In this case, these are the known quantities: *1. the home prefix is known *2. HA prefix is known 3. secret is known 4. care-of address is known In this case, the foreign agent uses a Mobile Node Cookie Extension (Section 9.5.) to determine which mobile node to send replies to. Notice that it is presumed that an foreign agent learn the mobile node MAC address from snooping the Registration Request. Calhoun, Montenegro, Perkins expires September 1998 [Page 33]