< draft-ietf-pppext-ipcp-mip-01.txt   draft-ietf-pppext-ipcp-mip-02.txt >
PPP Extensions Working Group J. Solomon, Motorola PPP Extensions Working Group J. Solomon, Motorola
Internet Draft S. Glass, FTP Software Internet Draft S. Glass, FTP Software
expires November 23, 1997 May 23, 1997 expires January 2, 1998 July 2, 1997
Mobile-IPv4 Configuration Option for PPP IPCP Mobile-IPv4 Configuration Option for PPP IPCP
<draft-ietf-pppext-ipcp-mip-01.txt> <draft-ietf-pppext-ipcp-mip-02.txt>
Status of this Memo Status of this Memo
This document is a submission to the PPPEXT working group of the This document is a submission to the PPPEXT working group of the
IETF. Questions and comments should be sent to the mailing list: IETF. Questions and comments should be sent to the mailing list:
ietf-ppp@merit.edu. ietf-ppp@merit.edu.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
skipping to change at page 7, line 24 skipping to change at page 7, line 24
0 1 2 3 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 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 | Mobile Node's ... | Type | Length | Mobile Node's ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Home Address | ... Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
137 (Mobile-IPv4) 4 (Mobile-IPv4)
Length Length
6 (The length of this entire extension in bytes) 6 (The length of this entire extension in bytes)
Mobile Node's Home Address Mobile Node's Home Address
In a Configure-Request, the IP home address of the mobile node In a Configure-Request, the IP home address of the mobile node
sending this Configuration Option; otherwise, the (unmodified) IP sending this Configuration Option; otherwise, the (unmodified) IP
home address of the peer when sent in a Configure-Ack or home address of the peer when sent in a Configure-Ack or
skipping to change at page 8, line 42 skipping to change at page 8, line 42
sent by a PPP peer during IPCP. Along with each possibility is a sent by a PPP peer during IPCP. Along with each possibility is a
description of how the receiver should interpret the contents as well description of how the receiver should interpret the contents as well
as a suggested course of action. as a suggested course of action.
2.3. High-Level Requirements for Non-Mobile-Nodes 2.3. High-Level Requirements for Non-Mobile-Nodes
A node that is not performing mobile node functionality (such as A node that is not performing mobile node functionality (such as
non-Mobile-IP-aware nodes as well as nodes performing only home agent non-Mobile-IP-aware nodes as well as nodes performing only home agent
functionality, foreign agent functionality, or both) MUST NOT include functionality, foreign agent functionality, or both) MUST NOT include
a Mobile-IPv4 Configuration Option within any Configure-Request a Mobile-IPv4 Configuration Option within any Configure-Request
message. Such a node SHOULD send a Configure-Request containing an message. As per [RFC 1332], such a node SHOULD send a Configure-
IP-Address Configuration Option in which the IP-Address field is set Request containing an IP-Address Configuration Option in which the
to a non-zero IP address that the node has assigned to one of its IP-Address field is set to a non-zero IP address that the node has
interfaces. If an explicit IP address has been assigned to the assigned to one of its interfaces. If an explicit IP address has
node's PPP interface then this address SHOULD be sent in preference been assigned to the node's PPP interface then this address SHOULD be
to any of the node's other addresses. sent in preference to any of the node's other addresses.
A node MUST NOT send a Configure-Nak containing a Mobile-IPv4 A node MUST NOT send a Configure-Nak containing a Mobile-IPv4
Configuration Option. Doing so is currently "undefined" and might Configuration Option. Doing so is currently "undefined" and might
cause interoperability problems when a useful meaning for Configure- cause interoperability problems when a useful meaning for Configure-
Nak is ultimately defined for the Mobile-IPv4 Configuration Option. Nak is ultimately defined for the Mobile-IPv4 Configuration Option.
A node that sends a Configure-Ack containing a Mobile-IPv4 A node that sends a Configure-Ack containing a Mobile-IPv4
Configuration Option SHOULD send an Agent Advertisement [RFC 2002] Configuration Option SHOULD send an Agent Advertisement [RFC 2002]
immediately upon IPCP for that link entering the Opened state. immediately upon IPCP for that link entering the Opened state.
2.4. High-Level Requirements for Mobile Nodes 2.4. High-Level Requirements for Mobile Nodes
skipping to change at page 9, line 28 skipping to change at page 9, line 28
numbered items in Section 2.5 under extenuating circumstances. numbered items in Section 2.5 under extenuating circumstances.
A mobile node that receives a Configure-Ack containing a Mobile-IPv4 A mobile node that receives a Configure-Ack containing a Mobile-IPv4
Configuration Option MUST receive an Agent Advertisement, possibly in Configuration Option MUST receive an Agent Advertisement, possibly in
response to an Agent Solicitation, before sending a Registration response to an Agent Solicitation, before sending a Registration
Request [RFC 2002] if that mobile node is connecting to a foreign Request [RFC 2002] if that mobile node is connecting to a foreign
link. This is because the peer might be a foreign agent that link. This is because the peer might be a foreign agent that
enforces a policy which requires a mobile node to register with that enforces a policy which requires a mobile node to register with that
foreign agent even if the mobile node is using a co-located care-of foreign agent even if the mobile node is using a co-located care-of
address. A mobile node need not wait for such an advertisement if it address. A mobile node need not wait for such an advertisement if it
connects to its home link. connects to its home link. See item 7a in section 2.5 for one way in
which a mobile node can determine if it has connected to its home
link. Another way is by receiving an explicit notification of this
fact from its peer, such as receipt of the messages in items 1b, 2c,
and 3a in section 2.5.
This specification recommends that a mobile node fall back to IP- A mobile node that receives a Configure-Reject containing a Mobile-
Address option-negotiation using Request(IP=0) if the Mobile-IPv4 IPv4 Configuration Option SHOULD fall back to IPCP negotiation using
Configuration Option is Rejected. This provides an opportunity for the IP-Address option [RFC 1332]. A mobile node SHOULD begin this
the mobile node to obtain a co-located care-of address from its peer negotiation with Request(IP=home) or Request(IP=0), depending on
if that peer supports dynamic address assignment through PPP. This whether or not the mobile node is connecting to its home link,
is in contrast to [RFC 2002] which recommends that mobile nodes send respectively. A mobile node MAY make this determination by
Request(IP=Home). The problem with the latter is that some inspection of an IP-Address option contained within a Configure-
implementations will send Ack(IP=Home) even though the mobile node is Request sent by its peer. If the prefix of the peer's stated IP-
not connecting to its home link. In such an instance, the mobile address is equal to the prefix of the mobile node's home address,
node is better off requesting a co-located care-of address with then the mobile node MAY conclude that it is connecting to its home
Request(IP=0) and falling back to Request() if its peer sends link. Otherwise, if the mobile node is connecting to a foreign link,
Reject(IP=0). See Section 2.5 item (5)(b) and (7)(a) for the then the mobile node SHOULD send Request(IP=0) since its peer might
relevant exchange. have no means for assigning addresses other than IPCP. This
specification therefore differs slightly from [RFC 2002], the latter
of which recommends that a mobile node begin IP-Address negotiation
with Request(IP=Home) under all circumstances.
A peer that is performing neither home agent nor foreign agent A peer that is performing neither home agent nor foreign agent
functionality SHOULD send a Reject in response to any Request functionality SHOULD send a Reject in response to any Request
received from its peer that contains a Mobile-IPv4 Configuration received from its peer that contains a Mobile-IPv4 Configuration
Option. Option.
2.5. Detailed Description 2.5. Detailed Description
The numbered items below show all possible combinations of Mobile- The numbered items below show all possible combinations of Mobile-
IPv4 and IP-Address Configuration Options that a mobile node (or a IPv4 and IP-Address Configuration Options that a mobile node (or a
skipping to change at page 10, line 33 skipping to change at page 10, line 38
with one of the following: with one of the following:
a. Nak(IP=coa) means "use coa as your co-located care-of a. Nak(IP=coa) means "use coa as your co-located care-of
address". Goto 2. address". Goto 2.
b. Nak(IP=home) means "you're at home and don't need a care-of b. Nak(IP=home) means "you're at home and don't need a care-of
address". Goto 3. address". Goto 3.
c. Reject(IP=0) means "I cannot assign a co-located care-of c. Reject(IP=0) means "I cannot assign a co-located care-of
address but you're welcome to use me as a foreign agent". address but you're welcome to use me as a foreign agent".
Goto 4. Goto 4.
d. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4 d. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4
option". Goto 5. option". If the peer also sent Request(IP=address) and the
prefix of the peer's address is equal to that of the mobile
node's home address, then goto 6 with a.b.c.d=home;
otherwise, goto 5.
e. Reject(IP=0,MIPv4=home) means "use the default". Goto 7. e. Reject(IP=0,MIPv4=home) means "use the default". Goto 7.
=> Ack(IP=0, ...), Nak(MIPv4=any, ...) MUST NOT be sent. => Ack(IP=0, ...), Nak(MIPv4=any, ...) MUST NOT be sent.
2. Request(IP=coa,MIPv4=home) means "I want to use coa as my co- 2. Request(IP=coa,MIPv4=home) means "I want to use coa as my co-
located care-of address." Peer MUST respond with one of the located care-of address." Peer MUST respond with one of the
following: following:
a. Ack(IP=coa,MIPv4=home) means "ok, use coa as your co-located a. Ack(IP=coa,MIPv4=home) means "ok, use coa as your co-located
care-of address; be sure to wait for an advertisement." care-of address; be sure to wait for an advertisement."
Opened. Opened.
b. Nak(IP=coa') means "no, use coa' as your co-located care-of b. Nak(IP=alternate-coa) means "no, use alternate-coa as your
address". Goto 2. co-located care-of address". Goto 2.
c. Nak(IP=home) means "you're at home and don't need a co- c. Nak(IP=home) means "you're at home and don't need a co-
located care-of address". Goto 3. located care-of address". Goto 3.
d. Reject(IP=coa) means "coa is not a useful value for a co- d. Reject(IP=coa) means "coa is not a useful value for a co-
located care-of address on this link and I cannot assign a located care-of address on this link and I cannot assign a
useful one -- you may use me as a foreign agent". Goto 4. useful one (or I will not negotiate the IP-Address option) --
you may use me as a foreign agent". Goto 4.
e. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4 e. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4
option". Goto 5. option". If the peer also sent Request(IP=address) and the
prefix of the peer's address is equal to that of the mobile
node's home address, then goto 6 with a.b.c.d=home;
otherwise, goto 5.
f. Reject(IP=coa,MIPv4=home) means "use the default". Goto 7. f. Reject(IP=coa,MIPv4=home) means "use the default". Goto 7.
=> Nak(MIPv4=any, ...) MUST NOT be sent. => Nak(MIPv4=any, ...) MUST NOT be sent.
3. Request(IP=home,MIPv4=home) means "I think I'm at home but if I'm 3. Request(IP=home,MIPv4=home) means "I think I'm at home but if I'm
wrong then I prefer a co-located care-of address to a foreign wrong then I prefer a co-located care-of address to a foreign
agent care-of address." Peer MUST respond with one of the agent care-of address." Peer MUST respond with one of the
following: following:
a. Ack(IP=home,MIPv4=home) means "yes, you're at home". Opened. a. Ack(IP=home,MIPv4=home) means "yes, you're at home". Opened.
b. Nak(IP=coa) means "you're not at home, use coa as your co- b. Nak(IP=coa) means "you're not at home, use coa as your co-
located care-of address". Goto 2. located care-of address". Goto 2.
c. Reject(IP=home) means "you're not at home and I cannot assign c. Reject(IP=home) means "you're not at home and I cannot assign
a co-located care-of address (or I will not negotiate the a co-located care-of address (or I will not negotiate the
IP-Address option) -- you may use me as a foreign agent". IP-Address option) -- you may use me as a foreign agent".
Goto 4. Goto 4.
d. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4 d. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4
option". Goto 5. option". If the peer also sent Request(IP=address) and the
prefix of the peer's address is equal to that of the mobile
node's home address, then goto 6 with a.b.c.d=home;
otherwise, goto 5.
e. Reject(IP=home,MIPv4=home) means "use the default". Goto 7. e. Reject(IP=home,MIPv4=home) means "use the default". Goto 7.
=> Nak(MIPv4=any, ...) MUST NOT be sent. => Nak(MIPv4=any, ...) MUST NOT be sent.
4. Request(MIPv4=home) means "I want to run Mobile IP over this link 4. Request(MIPv4=home) means "I want to run Mobile IP over this link
and I don't want a co-located care-of address." Peer MUST respond and I don't want a co-located care-of address." Peer MUST respond
with one of the following: with one of the following:
a. Ack(MIPv4=home) means "ok, wait for an advertisement to a. Ack(MIPv4=home) means "ok, wait for an advertisement to
figure out where you are." Opened. figure out where you are." Opened.
b. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4 b. Reject(MIPv4=home) means "I do not implement the Mobile-IPv4
option". Goto 5. option". If the peer also sent Request(IP=address) and the
prefix of the peer's address is equal to that of the mobile
node's home address, then goto 6 with a.b.c.d=home;
otherwise, goto 5.
=> Nak(MIPv4=any, ...) MUST NOT be sent. => Nak(MIPv4=any, ...) MUST NOT be sent.
5. Request(IP=0) means "Please assign an address/co-located-care- 5. Request(IP=0) means "Please assign an address/co-located-care-
of-address". Peer MUST respond with one of the following: of-address". Peer MUST respond with one of the following:
a. Nak(IP=a.b.c.d) means "use a.b.c.d as your address/co- a. Nak(IP=a.b.c.d) means "use a.b.c.d as your address/co-
located-care-of-address". Goto 6. located-care-of-address". Goto 6.
b. Reject(IP=0) means "I cannot assign the requested b. Reject(IP=0) means "I cannot assign the requested
address/co-located-care-of-address; or, I do not implement address/co-located-care-of-address; or, I do not implement
skipping to change at page 13, line 36 skipping to change at page 13, line 36
mobile node's home address under the prefix-length associated mobile node's home address under the prefix-length associated
with the home link. If the mobile node is connected to its with the home link. If the mobile node is connected to its
home link then it SHOULD de-register with its home agent. home link then it SHOULD de-register with its home agent.
Otherwise, the mobile node MAY attempt to obtain a Otherwise, the mobile node MAY attempt to obtain a
topologically routable address through any of its supported topologically routable address through any of its supported
means (e.g., DHCP, manual configuration, etc.) for use as a means (e.g., DHCP, manual configuration, etc.) for use as a
co-located care-of address. If the mobile node is successful co-located care-of address. If the mobile node is successful
in obtaining such an address then it SHOULD register this in obtaining such an address then it SHOULD register this
address with its home agent. address with its home agent.
=> Nak(IP=0) SHOULD NOT be sent and historically means "send me => Nak(IP=0) MUST NOT be sent. Goto 6.
Request(a.b.c.d) because I insist on knowing your address".
Goto 6.
=> Nak() MUST NOT be sent. => Nak() MUST NOT be sent.
=> Reject() MUST NOT be sent. => Reject() MUST NOT be sent.
2.6. Example Scenarios 2.6. Example Scenarios
The section illustrates the use of the option and protocol as defined This section illustrates the use of the option and protocol as
in the previous sections. In the examples which follow, a defined in the previous sections. In the examples which follow, a
Configure-Request sent by a mobile node and the response generated by Configure-Request sent by a mobile node and the response generated by
the peer are shown on the same line. The number and letter to the the peer are shown on the same line. The number and letter to the
left of each request/response refer to the numbered and lettered left of each request/response refer to the numbered and lettered
items in Section 2.5. items in Section 2.5.
A. A mobile node prefers a co-located care-of address and the peer A. A mobile node prefers a co-located care-of address and the peer
is a foreign agent that is capable of assigning such an address: is a foreign agent that is capable of assigning such an address:
(1)(a) Request(IP=0,MIPv4=Home) / Nak(IP=coa) (1)(a) Request(IP=0,MIPv4=Home) / Nak(IP=coa)
(2)(a) Request(IP=coa,MIPv4=Home) / Ack(IP=coa,MIPv4=Home) (2)(a) Request(IP=coa,MIPv4=Home) / Ack(IP=coa,MIPv4=Home)
skipping to change at page 16, line 9 skipping to change at page 16, line 9
IP-Compression-Protocol option and any other options that do not IP-Compression-Protocol option and any other options that do not
involve the negotiation of IP addresses. If a mobile node and a involve the negotiation of IP addresses. If a mobile node and a
foreign agent or home agent agree in IPCP to use Van Jacobson Header 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 Compression [RFC 1144], then the mobile node MUST NOT set the 'V' bit
in its ensuing, Mobile IP Registration Request [RFC 2002]. in its ensuing, Mobile IP Registration Request [RFC 2002].
3.2. Move Detection 3.2. Move Detection
Mobile nodes that connect via PPP MUST correctly implement PPP's Mobile nodes that connect via PPP MUST correctly implement PPP's
IPCP, since movement by the mobile node will likely change its PPP IPCP, since movement by the mobile node will likely change its PPP
peer. Specifically, mobile nodes MUST be prepared to re-negotiate peer. Specifically, mobile nodes MUST be prepared to renegotiate
IPCP at any time, including, the re-negotiation of the Mobile-IPv4 IPCP at any time, including, the renegotiation of the IP-Address
Configuration Option described in this document. Configuration Option and the Mobile-IPv4 Configuration Option
described in this document. As per [RFC 1661], a mobile node in the
Opened state MUST renegotiate IPCP upon receiving an IPCP Configure-
Request from its peer.
Also note that certain wireless links can employ handoff and proxying Also note that certain wireless links can employ handoff and proxying
mechanisms that would not necessarily require bringing down a PPP mechanisms that would not necessarily require bringing down a PPP
link but would indeed require a mobile node to register with a new link but would indeed require a mobile node to register with a new
foreign agent. Therefore, mobile nodes which connect to an agent via foreign agent. Therefore, mobile nodes which connect to an agent via
PPP MUST employ their move detection algorithms (see section 2.4.2 in PPP MUST employ their move detection algorithms (see section 2.4.2 in
[RFC 2002]) and register whenever they detect a change in [RFC 2002]) and register whenever they detect a change in
connectivity. connectivity.
Specifically, a mobile node that fails to receive an Agent Specifically, a mobile node that fails to receive an Agent
 End of changes. 15 change blocks. 
38 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/