CURRENT MEETING REPORT


Reported by Jim Solomon, Motorola

Minutes of the IP Routing for Wireless/Mobile Hosts Working Group 
(MOBILEIP)


The Mobile IP Working Group met twice at the Dallas IETF.  The first 
meeting was focused on IPv4 mobility and the second was primarily 
concerned with IPv6 mobility.  The organization of these minutes is by 
topic area:  IPv4 then IPv6.


IPv4 Mobility

Administrative Note:  The Mobile IP mailing list has moved.  The new 
location is as follows:

General Discussion:  mobile-ip@smallworks.com
To Subscribe:  majordomo@smallworks.com
In Body:  subscribe mobile-ip

Many thanks to Jim Thompson for continuing to maintain the mailing 
list.


1)  Patent Issues

The outstanding patent issues facing Mobile IP have been solved:

a)  Perkins Patent.  Tony read the summary of the opinion from Hale & 
Dorr, the law firm hired with ISOC funds to determine the scope-of-
infringement of Mobile IP with respect to IBM Patent #5,159,592.  The 
working group being generally pleased with the opinion has decided to 
publish the specification "as is" (i.e. no major substantive changes) and 
pursue PS RFC.  The opinion from Hale & Dorr will be published as the 
appendix in the specification.

b)  Nonce Patent.  It has been difficult to obtain a specific statement 
from IBM as to whether this patent is being asserted as relevant to 
Mobile IP.  A proposal to mandate the use of timestamps, while 
allowing the optional use of nonces, was accepted by the working group.


2) Spec. Issues

a)  Requirements of FA location with respect to MN (i.e. "one hop 
away") and of HA location with respect to MN's home network (i.e. 
"must have an interface on") are never specified.  Dave Johnson will 
supply text to the author.

b)  Temporary COA--similar comment as in (a), namely, what is the 
relation between the COA and the MN's current location?  Dave 
Johnson will supply text here as well.

c)  Extensions are being defined by this WG that apply to either ICMP 
Router Advertisement or Registration messages--but not to both.  It 
should be clear that the Extension values for each of these come from 
respectively separate numbering spaces, that is, an Extension intended 
only for ICMP Router Advertisements (e.g. Mobile Service Extension) 
and an Extension intended only for Registration Requests (e.g., Mobile-
Home Authentication Extension), could both have the same Extension 
number.  This should be clarified in the document.  The working group 
decided not to renumber the extenstion Type values.

d)  The document should say that the advertising period should be 
NOMINALLY 1/3 of the Lifetime in the RFC1256-portion of the Agent 
Advertisement.

e)  Can an Agent Advertisement contain zero Router Addresses?  The 
consensus is "yes, it can".  In such a case, the MN MAY use the IP source 
address of the Agent Advertisement as a default router.  If the "Num 
Addrs" is non-zero, then a default router MAY be chosen according to 
the rules of RFC1256 wherein the IP source address of the Agent 
Advertisement is interpreted to be the "worst" choice for address of a 
default router.

f)  FAs MUST be routers, that is, an MN must be capable of 
communicating by sending its packets through the FA to which it has 
registered.

g)  Solicitations SHOULD be rate-limited more so than the once per 
second currently specified in the draft.  For example, exponential 
backoff was suggested.  Dave Johnson will supply text to the editor.

h)  There was much discussion about the usefulness of prefixes for MN 
move detection in wireless environments where subnets can overlap.  
Tony Li and Charlie Perkins will put suitable text in the draft to 
discourage the use of prefixes in environments (e.g. certain wireless 
configurations) where they could lead to problems.

i)  Timestamp replay protection is broken.  Two registrations with 
different COAs but both timestamps within the synchronization 
window would cause the wrong mobility binding to be current at the 
HA.  As an additional rule, the HA must not accept any timestamp from 
an MN that is less than the currently accepted one.

j)  Usage of ARP is underspecified or downright broken:

1)  Consider an MN that is not within the wireless range of its HA (and 
thus registers with an FA) but is within the wireless range of a CH on 
its home network.  If the MN hears the CH's ARP and answers it, 
problems can arise if the MN then moves out of the range of the CH.  
Thus, while registered with an FA, the MN MUST NOT answer ARPs 
from any nodes other than that FA.

2)  The ordering of operations when a MN leaves home and/or returns 
home is underspecified/wrong.  When a mobile node leaves its home 
network and detects movement to a foreign network, the following 
sequence should occur:

o  MN stops answering ARPs
o  MN sends Registration Request
o  if HA accepts registration, it:
a) sends gratuitous ARPs for the MN
b) starts Proxy ARPing for the MN endif
o  HA sends Registration Reply.

When an MN returns home, the following ordering occurs:

o  MN begins answering ARPs
o  MN sends gratuitous ARP(s)
o  MN sends Registration Request(s)
o  if HA accepts registration, it:
a) stops Proxy ARPing for the MN
b) sends gratuitous ARPs for the MN endif
o  HA sends Registration Reply.

k)  Some confusion was detected with regard to mobile routers.  The 
language in the draft should perhaps be clarified in this regard.

l)  Validity checks in 3.6.2.1 are wrong with respect to receiving 
Registration Replies with a Code indicating a rejection by the FA.  In 
this case, no MN/HA authenticator is likely to be found and, instead, 
an MN/FA authenticator must appear if the MN and FA share a 
security association.  Jim Solomon to supply text.

m)  A suggestion was made that an FA provide tunneling in the reverse 
direction to provide location privacy for MNs.  It was determined that 
this needed much more protocol mechanism and is a good topic for 
discussion on the mailing list.  That is, it will be deferred until after 
the current draft goes PS.

n)  A suggestion was made to provide a mechanism to supply a node 
with an indication of WHICH extension was unrecognized or 
malformed.  It was decided that at the time extensions are defined, the 
mechanism by which error reporting occurs (e.g. new code field, a 
general-purpose "bad extension" extension) should be defined as well.

o)  The current language in the draft states that if an MN sets the 'B' bit 
in a Registration Request then it will receive a copy of "all" broadcasts 
on the home net.  The spec. should say that it is a matter of 
configuration at the HA as to which broadcasts get tunneled to the MN.


3)  Mobile IP Applicability Statement.

An applicability statement, as required for advancement of Mobile IP 
to Proposed Standard RFC (cf RFC1264), has been written by Jim 
Solomon and will be submitted as an Internet-Draft early next week.


4)  Mobile IP MIB(s).

David Cong and Mark Hamlen of Motorola have written a draft MIB 
for Mobile IP which will also be submitted early next week as an 
Internet-Draft.  The group agreed to appoint the forementioned as 
working group editors of the MIB document.  Charlie Perkins has 
agreed to assist in this effort.


5)  Advancement to Proposed Standard RFC.

All the requirements of RFC1264 have been (nearly) completed.  Thus, 
when Charlie updates the draft, a working group last call will be 
issued, followed by submission of the draft to the IESG.  Minimum 
Encapsulation could be advanced as an Informational RFC but "IP in IP" 
encapsulation MUST be advanced on the standards track.  The co-chairs 
will consult with the Routing Area Director as for the rules for 
advancing IP in IP Encapsulation along the standards track.

6)  Other Topics

The following topics were discussed which are not part of the base 
technical specification but are nonetheless important to the Mobile IP 
Working Group:

a)  Route Optimization

Dave Johnson presented the route optimization proposal as defined in 
draft-ietf-mobileip-optim-03.txt.  The proposal involves a mechanism 
for distributing authentic binding information to correspondents of 
mobile nodes.  The key distribution problem is mitigated by having 
authenticated bindings sent by the home agent rather than the mobile 
nodes themselves.  The authors stressed the need for feedback on their 
proposal from the members of the Mobile IP Working Group.

b)  DHCP Extension

Charlie Perkins presented a new option to DHCP for Mobile Home 
addresses for IPv4.  DHCP currently provides an IP address for the local 
subnet.  The new option requests an address that the mobile can use as a 
home address as well as an address of a home agent.  The value of the 
option is 68.  More investigation is required to determine how the 
mobile node and home agent can be set up with a security association.

c)  IP Squared

Kazuhiro Okanoue <okanoue@nwk.CL.nec.co.jp> presented his work on 
route optimization using Double-IP Headers (IP Squared) based on the 
Sony VIP work.  This proposal uses IP concatenation, which uses an 
encapsulating IP header with the same protocol number.  Statistically, 
it would be possible to differentiate this from the real data.  IP 
concatenation is used by the mobile node to send data.  All intermediate 
routers learn that the sender of the data is indeed a mobile node and 
then cache its care-of address.  Such routers can then shortcut the routes 
to mobile nodes.

d)  Virtual Home Agents

Dave Johnson presented a method on how to solve the problem of 
crashing home agents.  This approach uses an extra address for home 
agents, which elect a "real" home agent from among the group.  Tony Li 
noted that Cisco has a patent pending which might be relevant to this 
technology.

e)  Hierarchical Foreign Agent

Charlie Perkins presented a method for short-cutting the registration 
process by registering a list of foreign agents that form a hierarchical 
tree.  When moving among leaves in the tree, registration messages 
need only be sent back as far as the common branching node within the 
tree.

f)  IPv6 Mobility

Charlie Perkins presented an overview of his and Dave Johnson's IPv6 
Mobility draft (see draft-perkins-ipv6-mobility-sup-02.txt).  The 
working group reached consensus that this is the architectural 
framework to be adopted for IPv6 moving forward.  Future revisions of 
the IPv6 mobility draft will thus be "official working group" 
documents.

The remainder of these minutes summarize Charlie's presentation 
(notes taken by Tony Li):

o  Port IPv4 Mobile IP proposal over to IPv6, but add allowances for 
IPv6 flexibility.  There is no installed base.  Authentication is built 
into all nodes.  We can include route optimization for effectively no cost 
because of authentication.

o  Foreign Agents are still useful in IPv6.  They can do authentication, 
charge for connection services, produce or share a session key for new 
clients, negotiate compression, manage the local router.

o  Tunneling can use an IPv6 routing header.  It provides a loose/strict 
source route, but done right and can be done in any packet.  We may still 
want to do tunneling because the header is authenticated and thus only 
the source can insert a header into the packet.

o  Binding updates are new and come from the IPv4 route optimization 
proposal.  The HA is responsible for updating the previous foreign 
agent and the correspondent node.  Only the mobile node sends binding 
updates.

o  A binding update fits in a destination option.  You can still register 
with your home agent to establish location.  The MN still needs to 
register with the FA, so the registration is encapsulated and forwarded 
to the FA, and then relayed to the HA.

o  The FA can decapsulate incoming packets if they are encapsulated.  
The MN sends updates to CH, without acknowledgment.  No routing 
header indicates that a binding is necessary.

o  Binding updates should be rate limited.  Estimate the RTT and use 
this as an approximation for a rate at which to limit.  One MAY send 
updates to all open TCP connections.

o  To do:
o  Define binding update destination option
o  Define binding ACK packet or option
o  All nodes must be able to process them
o  All nodes must be able to use and maintain a binding cache
o  All nodes must be able to tunnel their own packets
o  Insure that authentications works during registration


o  Issues:
o  Interaction with IPv4 correspondents and mobile mobiles
o  Hop count limitations may halve the diameter of reachability
o  Should beacons be on a separate multicast address for performance of 
non-mobile hosts?