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 = <any>
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 = <any> 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]
