Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/mobileip/mobileip-minutes-95dec.txt

Text File | 1996-06-03 | 13KB | 296 lines

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:  [e-mail]
To Subscribe:  [e-mail]
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 <[e-mail]> 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?