PPP Extensions Working Group J. Solomon, Motorola
Internet Draft S. Glass, FTP Software
expires September 24, 1997 March 24, 1997
Mobile IPv4 Configuration Option for PPP IPCP
<draft-ietf-pppext-ipcp-mip-00.txt>
Status of this Memo
This document is a submission to the PPPEXT working group of the
IETF, having already reached consensus within the MOBILEIP working
group. Questions can be directed to the respective mailing lists:
ietf-ppp@merit.edu and mobile-ip@smallworks.com.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
Mobile IP [RFC 2002] defines media-independent procedures by which a
Mobile Node can maintain existing transport and application-layer
connections despite changing its point-of-attachment to the Internet
and without changing its IP address. PPP [RFC 1661] provides a
standard method for transporting multi-protocol packets over point-
to-point links. As currently specified, Mobile IP Foreign Agents
which support Mobile Node connections via PPP can do so only by first
assigning unique addresses to those Mobile Nodes, defeating one of
the primary advantages of Foreign Agents. This documents corrects
this problem by defining the Mobile IPv4 Configuration Option to the
Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this
option, two peers can communicate their support for Mobile IP during
the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP
[RFC 1332], and PPP [RFC 1661] is assumed.
Solomon & Glass expires September 24, 1997 [Page 1]
Internet Draft Mobile IP Option for PPP March 24, 1997
Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . 3
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
2. Mobile IPv4 Configuration Option . . . . . . . . . . . . . . . 6
3. Additional Requirements . . . . . . . . . . . . . . . . . . . 9
3.1. Other IPCP Options . . . . . . . . . . . . . . . . . . . 9
3.2. Move Detection . . . . . . . . . . . . . . . . . . . . . 9
4. Supported Scenarios . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Mobile IP [RFC 2002] defines protocols and procedures by which
packets can be routed to a mobile node, regardless of its current
point-of-attachment to the Internet, and without changing its IP
address. Mobile IP is designed to run over any type of media and any
type of data link-layer. However, the interaction between Mobile IP
and PPP is currently underspecified and generally results in an
inappropriate application of Mobile IP when mobile nodes connect to
the Internet via PPP.
This document defines proper interaction between a mobile node [RFC
2002] and a dialup server through which the mobile node connects to
the Internet using PPP. This requires the definition of a new option
for IPCP [RFC 1332], named the "Mobile IPv4 Configuration Option",
which is defined in this document. The mobile node and the dialup
server use this option to negotiate the appropriate use of Mobile IP
over the PPP link.
1.1. Terminology
This document uses the following terms as defined in [RFC 2002]:
Mobile Node
A host or router that changes its point of attachment from one
network or subnetwork to another. A mobile node may change its
location without changing its IP address; it may continue to
communicate with other Internet nodes at any location using its
(constant) IP address, assuming link-layer connectivity to a
point of attachment is available.
Solomon & Glass expires September 24, 1997 [Page 2]
Internet Draft Mobile IP Option for PPP March 24, 1997
Home Agent
A router on a mobile node's home network which tunnels
datagrams for delivery to the mobile node when it is away from
home, and maintains current location information for the mobile
node.
Foreign Agent
A router on a mobile node's visited network which provides
routing services to the mobile node while registered. The
foreign agent detunnels and delivers datagrams to the mobile
node that were tunneled by the mobile node's home agent. For
datagrams sent by a mobile node, the foreign agent may serve as
a default router for registered mobile nodes.
Dialup Server
The PPP peer of a mobile node. A dialup server might support
home agent functionality, foreign agent functionality, both, or
neither.
1.2. Problem Statement
In Mobile IP, packets sent to a mobile node's home address are routed
first to the mobile node's home agent, a router on the mobile node's
home link which intercepts packets sent to the home address. The
home agent then tunnels such packets to the mobile node's care-of
address, where the packets are extracted from the tunnel and
delivered to the mobile node. There are two types of care-of
addresses:
Co-located Care-of Address
An address temporarily assigned to a mobile node itself. In
this case, the mobile node is the exit-point of the tunnel and
decapsulates packets encapsulated for delivery by its home
agent.
Foreign Agent Care-of Address
An address of a foreign agent that has at least one interface
on a mobile node's visited link. In this case, the foreign
agent decapsulates packets that have been tunneled by the home
agent and delivers them to the mobile node over the visited
link.
Solomon & Glass expires September 24, 1997 [Page 3]
Internet Draft Mobile IP Option for PPP March 24, 1997
In Appendix B, Mobile IP [RFC 2002] currently specifies only the
following with respect to PPP:
"The Point-to-Point-Protocol (PPP) [RFC 1661] and its Internet
Protocol Control Protocol (IPCP) [RFC 1332], negotiates the use of
IP addresses.
"The mobile node SHOULD first attempt to specify its home address,
so that if the mobile node is attaching to its home network, the
unrouted link will function correctly. When the home address is
not accepted by the peer, but a transient IP address is
dynamically assigned to the mobile node, and the mobile node is
capable of supporting a co-located care-of address, the mobile
node MAY register that address as a co-located care-of address.
When the peer specifies its own IP address, that address MUST NOT
be assumed to be a foreign agent care-of address or the IP address
of a home agent."
Inspection of this text reveals that there is currently no way for
the mobile node to use a foreign agent care-of address, without first
being assigned a unique IP address, even if the dialup server also
supports foreign agent functionality. The reason for this can be
seen by walking through the IPCP negotiation:
1. A mobile node calls a dialup server and proposes its home address
in IPCP's "IP Address" option.
2. The dialup server has no way of knowing whether this is: (a) a
mobile node proposing its home address; or (b) a conventional node
proposing a non-routable address. In this case, the dialup server
must (conservatively) Nak the IP address option.
3. The mobile node, in turn, has no way of knowing whether its home
address was Nak'ed because the peer is a foreign agent being
conservative, or because the peer does not implement Mobile IP at
all. Therefore, the mobile node must (conservatively) assume that
the peer does not implement Mobile IP and continue the negotiation
of an IP address in IPCP, after which point the mobile node can
use the assigned address as a co-located care-of address.
Here we observe that, even if the dialup server is a foreign agent
and sends an Agent Advertisement to the mobile node after IPCP
completes, the mobile node will still have negotiated a routable
address in step 3 which it is likely already using as a co-located
care-of address. This defeats the purpose of foreign agent care-of
addresses, which are designed to be shared by multiple mobile nodes
and to eliminate the need to assign a unique address to each mobile
node.
Solomon & Glass expires September 24, 1997 [Page 4]
Internet Draft Mobile IP Option for PPP March 24, 1997
1.3. Requirements
The purpose of this document is to specify the behavior of both ends
of the PPP link when one or more of the PPP peers supports Mobile IP.
Specifically, the design of the option and protocol defined in this
document is based upon the following requirements:
1. The option and protocol described in this document must be
backwards compatible with conventional nodes and dialup servers
which do not implement this option nor any Mobile IP
functionality.
2. The option and protocol described in this document must
accommodate a variety of scenarios, minimally those identified in
Section 4.
3. A unique address must not be assigned to a mobile node unless
absolutely necessary. Specifically, no such address is assigned
to a mobile node that connects via PPP to its home link or a
mobile node that connects via PPP to a foreign agent (and uses
that foreign agent's care-of address).
Solomon & Glass expires September 24, 1997 [Page 5]
Internet Draft Mobile IP Option for PPP March 24, 1997
2. Mobile IPv4 Configuration Option
The Mobile IPv4 Configuration Option for IPCP is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |D| reserved1 |C|H| reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node's Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned Co-Located Care-Of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 137 (Mobile IPv4 Configuration Option)
Length 12 (The length of this entire extension in bytes)
D 1, if the Mobile Node wants a Dynamically assigned,
co-located care-of address, 0 otherwise.
reserved1 sent as 0, ignored on reception
C 1, if the dialup server Cannot fulfill the mobile
node's request to be dynamically assigned a
co-located care-of address, 0 otherwise.
H 1, if the PPP interface of the dialup server is a
neighbor of the mobile node's home address on the
home link, 0 otherwise.
reserved2 sent as 0, ignored on reception
Mobile Node's Home Address
The IP home address of the mobile node sending the
Mobile IPv4 Configuration Option.
Assigned Co-Located Care-of Address
A place-holder for the dynamically assigned
co-located care-of address. Ignored if the 'D' bit
is 0.
The option works as follows. A mobile node includes the Mobile IPv4
Configuration Option in a Configure-Request of IPCP. A mobile node
MUST NOT include an IP Address Option (nor the deprecated IP-
Addresses Option) along with the Mobile IPv4 Configuration Option but
MAY include other options that do not involve negotiation of an IP
address (see section 3.1).
Solomon & Glass expires September 24, 1997 [Page 6]
Internet Draft Mobile IP Option for PPP March 24, 1997
The mobile node MUST set the 'D' bit to 1 if it wants to be assigned
a co-located care-of address, otherwise it MUST set the 'D' bit to 0.
The mobile node SHOULD set all other fields and bits to 0, except for
the "Mobile Node's Home Address" field in which it MUST place its IP
home address.
The response generated at the other end of the PPP link depends upon
the identity and the capabilities of the PPP peer (for simplicity, we
call this peer a "dialup server"). Several cases are described as
follows, which assume that the dialup server has received a
Configure-Request from the mobile node containing a Mobile IPv4
Configuration Option:
1. If the Mobile IPv4 Configuration Option is not recognizable or is
not acceptable for negotiation (as configured by a network
administrator), then the dialup server MUST respond by sending a
Configure-Reject, as described in [RFC 1661]. A mobile node that
receives such a Configure-Reject MAY proceed with IPCP negotiation
using the IP Address Option [RFC 1332] instead of the Mobile IPv4
Configuration Option. The address so negotiated MAY be used by
the mobile node as a co-located care-of address.
If, instead, the Mobile IPv4 Configuration Option is recognizable
and is acceptable for negotiation, then the dialup server MUST
respond with either a Configure-Ack or a Configure-Nak, depending
upon the acceptability of the specific values contained within the
Mobile IPv4 Configuration Option. Each such case is described
below where, due to the recognizability of the Mobile IPv4
Configuration Option, we assume that the dialup server is either a
home agent, a foreign agent, or both.
2. If the dialup server is a bridge with one interface on the mobile
node's home network or if the dialup server is a router whose
address on its PPP interface is a neighbor to the mobile node's
home address (i.e., the mobile node is connecting to its home
link), then the dialup server sends a Configure-Nak in which it
sets the 'H' bit to 1 and leaves all other fields unmodified. A
mobile node receiving this Configure-Nak MUST respond by sending a
new Configure-Request (containing the Mobile IPv4 Configuration
Option) with D=0, C=0, H=1, Mobile Node's Home Address field set
to the mobile node's IP home address, and the Assigned Co-Located
Care-of Address field set to 0. The dialup server will
subsequently send a Configure-Ack in response to this new
Configure-Request and IPCP will complete. The mobile node is not
required to wait for an Agent Advertisement before de-registering
with its home agent.
Solomon & Glass expires September 24, 1997 [Page 7]
Internet Draft Mobile IP Option for PPP March 24, 1997
All the remaining cases assume that the dialup server is a foreign
agent to the mobile node and specifically not connected to the
mobile node's home link (as determined by the Mobile Node's Home
Address field).
3. If the mobile node set the 'D' bit to 1, if the Assigned Co-
Located Care-of Address is set to a value never previously
assigned to this mobile node (e.g., 0.0.0.0), and if the foreign
agent is capable of assigning an address, then the foreign agent
MUST respond with a Configure-Nak in which a newly assigned co-
located care-of address is placed in the Assigned Co-Located
Care-of Address field and all other fields are left unmodified. A
mobile node receiving such a Configure-Nak MUST respond by sending
a new Configure-Request containing a Mobile IPv4 Configuration
Option copied without modification from this received Configure-
Nak. The foreign agent MUST respond to this new Configure-Request
with a Configure-Ack.
As specified in [RFC 1661] and [RFC 1332], a mobile node MUST
receive such a Configure-Ack before it can consider IPCP to be
completed and therefore that it may use the assigned address as a
co-located care-of address. In addition, the mobile node MUST (!)
wait for an Agent Advertisement before registering this co-located
care-of address. This is because the foreign agent might set the
'R' Bit in its Agent Advertisements (see [RFC 2002]) which forces
the mobile node to register via the foreign agent, even when using
a co-located care-of address. Accordingly, the foreign agent MUST
send an Agent Advertisement over a PPP link immediately after IPCP
for that link enters the Opened state.
4. If the mobile node set the 'D' bit to 1, and if the Assigned Co-
Located Care-of Address is set to a value previously assigned to
this mobile node by this foreign agent (i.e., as assigned in case
#3 above), then the foreign agent MUST respond with a Configure-
Ack and IPCP completes. The mobile node MUST (!) wait for an
Agent Advertisement from the foreign agent before registering.
This is because the foreign agent might set the 'R' Bit in its
Agent Advertisements (see RFC 2002) which forces the mobile node
to register via the foreign agent, even when using a co-located
care-of address. Accordingly, the foreign agent MUST send an
Agent Advertisement over a PPP link immediately after IPCP for
that link enters the Opened state.
Solomon & Glass expires September 24, 1997 [Page 8]
Internet Draft Mobile IP Option for PPP March 24, 1997
5. If the mobile node set the 'D' bit to 1, and if the foreign agent
is *not* capable of assigning an address, then the foreign agent
MUST respond with a Configure-Nak in which the 'C' bit is set to 1
and all other fields are left unmodified. The mobile node must
now either give up and try to find a dialup server that can assign
an address, or proceed to use a foreign agent care-of address. In
the latter case, the mobile node sends a new Configure-Request
containing the Mobile IPv4 Configuration Option with the 'D' bit
set to 0, as described in item #6 below.
6. If the mobile node set the 'D' bit to 0, then the foreign agent
MUST return the option unmodified in a Configure-Ack and IPCP
completes. The mobile node MUST wait for an Agent Advertisement
from the foreign agent before registering. Accordingly, the
foreign agent MUST send an Agent Advertisement over a PPP link
immediately after IPCP for that link enters the Opened state.
The design and semantics of the Mobile IPv4 Configuration Option are
therefore optimized for the case of a mobile node making use of a
foreign agent's care-of address. The negotiation takes only one
round-trip in this case.
3. Additional Requirements
3.1. Other IPCP Options
Although a mobile node MUST NOT include an IP Address Option (nor the
deprecated IP-Addresses Option) in any Configure-Request that
contains a Mobile IPv4 Configuration Option, the mobile node MAY
include an IP-Compression-Protocol Option or any other option that
does not involve the negotiation of an IP address. If a mobile node
and a foreign agent or home agent agree in IPCP to use Van Jacobson
Header Compression [RFC 1144], then the mobile node MUST NOT set the
'V' bit in its ensuing, Mobile IP Registration Request [RFC 2002].
3.2. Move Detection
Mobile nodes that connect via PPP MUST correctly implement PPP's
IPCP, since movement by the mobile node will likely change its PPP
peer. Specifically, mobile nodes MUST be prepared to re-negotiate
IPCP at any time, including, the re-negotiation of the Mobile IPv4
Configuration Option described in this document.
Also note that certain wireless links can employ handoff and proxying
mechanisms that would not necessarily require bringing down a PPP
link but would indeed require a mobile node to register with a new
foreign agent. Therefore, mobile nodes which connect to an agent via
PPP MUST employ their move detection algorithms (see section 2.4.2 in
Solomon & Glass expires September 24, 1997 [Page 9]
Internet Draft Mobile IP Option for PPP March 24, 1997
[RFC 2002]) and register whenever they detect a change in
connectivity.
Specifically, a mobile node that fails to receive an Agent
Advertisement within the Lifetime advertised by its current foreign
agent, MUST assume that it has lost contact with that foreign agent
(see Section 2.4.2.1, [RFC 2002]). If, in the mean time, the mobile
node has received Agent Advertisements from another foreign agent,
the mobile node SHOULD immediately register with that foreign agent
upon timing out with its current foreign agent.
Likewise, a mobile node that implements move detection based upon the
Prefix-Length Extension MUST compare the prefix of any advertising
agents with that of its current foreign agent (see Section 2.4.2.2,
[RFC 2002]). If such a mobile node receives an Agent Advertisement
from a foreign agent specifying a different prefix than that of its
current foreign agent, then the mobile node that employs this method
of move detection MUST register with that new foreign agent.
A mobile node MAY treat PPP link-establishment as a sufficient reason
to proceed with a new Mobile IP registration. Section 2 defines the
circumstances under which mobile nodes MUST wait for an Agent
Advertisement before registering. Accordingly, foreign agents and
home agents MUST send an Agent Advertisement over a PPP link
immediately after IPCP for that link enters the Opened state.
4. Supported Scenarios
The Mobile IPv4 Configuration Option is designed to accommodate the
following scenarios. This section also helps to illustrate the use
of the option and the protocol specified above.
In the scenarios which follow, the direction of message flow is
indicated along with the type of IPCP message and the contents of the
appropriate option. "MN" refers to the mobile node and "dialup"
refers to the PPP peer to which the mobile node connects.
For sake of brevity, the Type, Length, Reserved, and Mobile Node's
Home Address fields have been omitted from the Mobile IPv4
Configuration Option below because these fields are always set to
their obvious values. Finally, the Assigned Co-Located Care-Of
Address field is designated by "IPcol-coa".
Solomon & Glass expires September 24, 1997 [Page 10]
Internet Draft Mobile IP Option for PPP March 24, 1997
A. A mobile node wants to use a co-located care-of address and the
dialup server is a foreign agent that is capable of assigning such
an address:
[ From -> To ] PPP Message Type Mobile IPv4 Configuration Option
============== ================= ================================
[MN -> dialup] Configure-Request {D=1,C=0,H=0,IPcol-coa=0.0.0.0}
[dialup -> MN] Configure-Nak {D=1,C=0,H=0,IPcol-coa=new-coa}
[MN -> dialup] Configure-Request {D=1,C=0,H=0,IPcol-coa=new-coa}
[dialup -> MN] Configure-Ack {D=1,C=0,H=0,IPcol-coa=new-coa}
- Mobile node waits to receive an Agent Advertisement.
- If (Advertisement has R-bit set) then
Mobile node registers with co-located care-of address via the
foreign agent;
else
Mobile node registers with co-located care-of address directly
with its home agent.
B. A mobile node wants to use a co-located care-of address and the
dialup server is a foreign agent. The foreign agent cannot assign
a co-located care-of address (e.g., it has no pool of addresses
from which to allocate for the purposes of assignment):
[ From -> To ] PPP Message Type Mobile IPv4 Configuration Option
============== ================= ================================
[MN -> dialup] Configure-Request {D=1,C=0,H=0,IPcol-coa=0.0.0.0}
[dialup -> MN] Configure-Nak {D=1,C=1,H=0,IPcol-coa=0.0.0.0}
The mobile node has two options: either proceed to use this
foreign agent's care-of address or disconnect and try to find a
different dialup server which can fulfill the request for a co-
located care-of address. In the former case, IPCP continues as
follows:
[ From -> To ] PPP Message Type Mobile IPv4 Configuration Option
============== ================= ================================
[MN -> dialup] Configure-Request {D=0,C=0,H=0,IPcol-coa=0.0.0.0}
[dialup -> MN] Configure-Ack {D=0,C=0,H=0,IPcol-coa=0.0.0.0}
- IPCP completes.
- Mobile node waits to receive an Agent Advertisement.
- Mobile node registers with its home agent via the foreign agent.
Solomon & Glass expires September 24, 1997 [Page 11]
Internet Draft Mobile IP Option for PPP March 24, 1997
C. A mobile node wants to use a foreign agent care-of address and the
dialup server is a foreign agent which finds this state of affairs
satisfactory:
[ From -> To ] PPP Message Type Mobile IPv4 Configuration Option
============== ================= ================================
[MN -> dialup] Configure-Request {D=0,C=0,H=0,IPcol-coa=0.0.0.0}
[dialup -> MN] Configure-Ack {D=0,C=0,H=0,IPcol-coa=0.0.0.0}
- IPCP completes.
- Mobile node waits to receive an Agent Advertisement.
- Mobile node registers with its home agent via the foreign agent.
D. A mobile node connects to a dialup server which is connected to
the mobile node's home link (for this scenario, it does not matter
whether the mobile node wishes to use a co-located care-of address
or a foreign agent care-of address). The dialup server informs
the mobile node that it is connected to its home link as follows
(the notation "D=x" implies a "don't care" condition):
[ From -> To ] PPP Message Type Mobile IPv4 Configuration Option
============== ================= ================================
[MN -> dialup] Configure-Request {D=x,C=0,H=0,IPcol-coa=0.0.0.0}
[dialup -> MN] Configure-Nak {D=x,C=0,H=1,IPcol-coa=0.0.0.0}
[MN -> dialup] Configure-Request {D=0,C=0,H=1,IPcol-coa=0.0.0.0}
[dialup -> MN] Configure-Ack {D=0,C=0,H=1,IPcol-coa=0.0.0.0}
- IPCP completes.
- Mobile node de-registers with its home agent.
Solomon & Glass expires September 24, 1997 [Page 12]
Internet Draft Mobile IP Option for PPP March 24, 1997
E. A mobile node wants to use either type of care-of address and the
dialup server does not implement the Mobile IPv4 Configuration
Option. The server rejects the option as follows (the notation
"D=x" implies a "don't care" condition):
[ From -> To ] PPP Message Type Mobile IPv4 Configuration Option
============== ================= ================================
[MN -> dialup] Configure-Request {D=x,C=0,H=0,IPcol-coa=0.0.0.0}
[dialup -> MN] Configure-Reject {D=x,C=0,H=0,IPcol-coa=0.0.0.0}
At this point, the mobile node can use the IP Address Option [RFC
1332] to negotiate an address which it can subsequently use as a
co-located care-of address:
[ From -> To ] PPP Message Type ***IP Address Option***
============== ================= ===============================
[MN -> dialup] Configure-Request {IPaddress = 0.0.0.0}
[dialup -> MN] Configure-Nak {IPaddress = assigned-address}
[MN -> dialup] Configure-Request {IPaddress = assigned-address}
[dialup -> MN] Configure-Ack {IPaddress = assigned-address}
- IPCP completes.
- Mobile node registers "IPaddress" as a co-located care-of address
with its home agent.
5. Security Considerations
This document introduces no known security threats over and above
those facing any node on the Internet that either connects via PPP or
implements Mobile IP or both. Specifically, service providers should
use cryptographically strong authentication (e.g., CHAP [RFC 1994])
to prevent theft-of-service. Additionally, users requiring
confidentiality should use PPP link encryption [RFC 1968], IP-layer
encryption [RFC 1827], or application-layer encryption, depending
upon their individual requirements. Finally, Mobile IP
authentication [RFC 2002] protects against trivial denial-of-service
attacks that could otherwise be waged against a mobile node and its
home agent.
Solomon & Glass expires September 24, 1997 [Page 13]
Internet Draft Mobile IP Option for PPP March 24, 1997
6. References
[RFC 1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
Serial Links", RFC 1144, January 1990.
[RFC 1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)," RFC 1332, May 1992.
[RFC 1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)
for the Transmission of Multi-protocol Datagrams over Point-to-
Point Links," RFC 1661, July 1994.
[RFC 1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC 1827, August 1995.
[RFC 1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC 1968] Meyer, G., "The PPP Encryption Control Protocol (ECP)",
RFC 1968, June 1996.
[RFC 2002] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
October 1996.
7. Acknowledgments
The design of this protocol and option were inspired by an earlier
submission by B. Patel and C. Perkins, then of IBM, in draft-patel-
mobileip-pppext-00.txt, which has since expired. Tim Wilson and
Chris Stanaway of Motorola contributed significantly to the design of
this configuration option and protocol specification.
Also, some of William Simpson's text was copied verbatim from [RFC
1661] in order to ensure consistency of terminology and
specification. The same goes for Charlie Perkins' text, including
definitions, from [RFC 2002].
Solomon & Glass expires September 24, 1997 [Page 14]
Internet Draft Mobile IP Option for PPP March 24, 1997
8. Authors' Addresses
Questions about this memo can be directed to:
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd. - Rm 2240
Schaumburg, IL 60196
Voice: +1-847-576-2753
Fax: +1-847-576-3240
E-Mail: solomon@comm.mot.com
Steven Glass
FTP Software, Inc.
2 High Street
North Andover, MA 01845
Voice: +1-508-685-4000
Fax: +1-508-684-6105
E-mail: glass@ftp.com
Solomon & Glass expires September 24, 1997 [Page 15]
