CURRENT_MEETING_REPORT_

Reported by Charlie Perkins/IBM Corporation

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

The Mobile IP Working Group met twice during the San Jose IETF, on
Thursday, 8 December.  The major focus of these meetings was to discuss
the remaining open issues in the current base protocol.



Discussion

The group agreed to move the home address out of the ``Home Address
Extension'' and into the registration request message.  In a subsequent
discussion on support for mobile routers, the group agreed that the
prefix size is no longer needed in the ``Home Address Extension,''
therefore the entire Home Address Extension was then viewed as
unnecessary, and is to be removed from the specification.

The group agreed to call the ``Tony'' bit the `R' bit.  After more
discussion, the group decided to allocate four bits in the Mobility
Extension flag field instead of three (as was decided in Toronto).  So,
now there will be the `R', `B', `F', and `H' bit -- the ``Registration
Required,'' ``Busy,'' ``Foreign Agent,'' and ``Home Agent'' bits.

It was decided to include a Foreign Agent lifetime in the Mobility
Extension of the agent advertisement.  The rationale was that this was
required since there is no longer any predefined relationship between
the service advertisement lifetime and the registration lifetime.  There
is already a status code (21) defined for exceeding the foreign agent
lifetime.

It was decided, based on the information that IBM has given permission
of use of certain related patented technology, that the specification
would assume the use of nonces (as the default) for replay protection
purposes.  The editor noted that he was not absolutely certain that the
patent issue had been resolved favorably.

Jim Solomon proposed to reincorporate MN$FA and FA$HA authentication
extensions into the draft specification.  This proposal was approved.

The group decided to make the Authentication computation include the
body of the UDP data as well as the extensions.  The editor was directed
to make a reasonable decision regarding whether the authenticator was to
be computed as 0, or just not included at all in the computation.  There
was a request to make it clear that the default mode of use of MD5 was
prefix jj data jj suffix.

It was decided to specify that the Foreign Agent must avoid routing
loops, and that it should drop the packets.  This is logically the same
as the language in the current draft, but by reversing the ordering of
the clauses it is hoped that the correct emphasis will be imparted to
the implementors.

There was a great deal of discussion about allowing the mobile nodes to
register without having any particular address available for their home
agent or agents.  Several schemes were put forth in the morning session.
It was originally decided to table the matter for the mailing list, but
since the group ended up having a lot of extra time in the afternoon,
the issue was taken up then; some interesting results were obtained
which will be described later.

After not too much discussion, the group generally agreed to adopt the
proposal (by Tony Li and Andrew Myles) put forth on the mailing list
regarding mobile routers.  The working group requested that language be
inserted into the draft clarifying the actual method by which the mobile
node can use tunneling when participating in a routing protocol with the
home agent.

Another patent issue received significant attention.  The editor, who
submitted the patent disclosure for IBM, stated that he has obtained a
statement of policy by IBM which complies with the official requirement
of the IETF, but which does not really meet the needs of the
participants in the MOBILEIP Working Group.  He also said that meeting
the needs is a time-consuming and tedious job which will proceed at a
pace which, while not rapid, will hopefully produce timely results.
John Tavs from IBM mentioned his view that there was no likely mechanism
by which IBM would pursue the collection of royalties, but this was not
viewed as sufficient to allay the fears of those implementing the
specification for use in products.  The general sense is that the editor
is expected to get a better resolution of the patent issue, but that the
current situation is good enough to proceed with implementation.  Tony
Li stated that if IBM does not make the technology available on suitably
favorable terms, he would direct his efforts towards making fundamental
changes to the specification so that there would be no use of patented
technology.

When the FA tries to contact the HA, it is possible for the FA to get
back an ICMP error message.  In this case, the group decided to create a
new failure status code, so that the mobile node could determine that it
should attempt to register with a different home agent (if possible).
The new status code will be called ``Home Agent Unreachable''; no
distinction will be made to reflect the various types of ICMP error
messages which might be returned to the foreign agent.

There was discussion about the bad things that might happen when a
foreign agent crashed.  Specifically, it was felt that a mobile node
might have difficulty if it dropped packet 0 or packet -1 just at the
time the foreign agent crashed.  It was decided to require that the
foreign agent must start its sequence of advertisement at 256 after a
reboot.  This will give the mobile nodes 256 opportunities to hear the
foreign agent's advertisements and discover that the sequence number had
wrapped around, instead of erroneously determining that the foreign
agent had crashed.

It was agreed to create a new status code for informing the mobile node,
upon successful registration, that simultaneous registrations are not
accepted by the home agent.  This was intended to eliminate the
following unfortunate scenario:


     The mobile node begins to enter a new service area for a
     foreign agent.  If the mobile node believes that simultaneous
     registration is possible, then it may issue a request for same.
     Under the previous existing scheme, if the home agent grants
     the request, the first registration is revoked, and the mobile
     node would be stuck with a single registration in a suboptimal
     service area.


With the new scheme, the mobile node will know as soon as it first
registers with its home agent, whether simultaneous registrations are
allowed.

These were all the major substantive issues that people in the working
group meeting could think of for discussion.  Since the group had come
to some conclusion on all of them except for the issue of registration
without knowledge of any home agent address, the group decided in the
afternoon to revisit the tabled question and quite good progress was
made.

The following approaches to the problem were identified:


  0. Use the mobile node's address.

    Pro: Trivial for the mobile node.
    Con: Cannot work the first time when the mobile node moves away from
         the home network, since the home agents cannot tell that they
         need to start intercepting packets addressed to the mobile
         node.

     This alternative was eliminated right away because no one could
     argue against the Con:  objection.

  1. Use the subnet broadcast address, <pfx>.<0> or <pfx>.<-1>.

    Pro: Trivial for mobile node.
    Con: Problems with multiple home agents.

     It was claimed that most, but not all, entry routers into a home
     network would be able to successfully relay such subnet broadcast
     packets onto the home network.

  2. Use DNS to get a ``Home Address'' record for the mobile node (as
     proposed by Greg Minshall on the mailing list).

    Pro: Uses established mechanisms.
    Con: Lots of packets exchanged.

     The foreign agent could actually do the work on behalf of the
     mobile node as part of the registration request sequence.  This
     method would need a new resource record (HA), but it is going to be
     needed anyway.

  3. Use a predetermined unicast address e.g, <pfx>.1.

    Pro: Guaranteed to work with existing routers.
    Con: Possible overload of whichever single HA is providing service
         at that address.  It was claimed that this was effectively
         pushing ARP into service as a routing protocol (a bad thing).
         This approach uses part of the subnet address space.  There
         might be trouble if there are multiple groups per subnet.  If
         there are multiple groups on the subnet, then there are
         presumably multiple groups of HAs, all of which would want to
         use .1, and only some of which would accept the registration.

  4. Could use a predetermined list of unicast addresses.

     This variant of (3) overcomes the objection of possibly overloading
     any particular home agent.

  5. Bag it.

    Pro: Not much, except that it reduces the amount of discussion time
         needed.
    Con: Unacceptable additional configuration requirement for mobile
         nodes.

  6. Preregistration via subnet broadcast address.

    Pro: Auto-discovery mechanism already available in existing
         specification, if another field is added to the registration
         reply failure return.
    Con: Extra round trip at bootup; foreign agents need to keep some
         extra state on mobile nodes.  Foreign agents need to permit
         registration packets to subnet broadcasts and forward replies
         to MN's even if they have not seen the HA's address before.
         Prior to this, the FA knew which HA was being registered with
         and could block packets for addresses other than that HA. This
         possibly exacerbates the existing covert channel provided by
         registration requests and replies.
    Alt: Home agents could wait a random time before responding.


Alternatives (1), (2), (4), and (5) were eliminated from consideration
after a great deal of productive discussion, and alternative (6) was a
latecomer which was proposed after those above mentioned alternatives
were eliminated.  No final decision was reached, and after a while the
suggestion was made to pursue the matter on the mailing list.  However,
it was the sense of the editor that alternative (6) was well received by
the group.

Since there was still time, Charles Perkins (not speaking as the editor)
made an impromptu presentation of the recent route-optimization draft
proposal.  This proposal is available as
draft-ietf-mobileip-optim-00.txt on the IETF draft directories, for
anonymous FTP. The basic operation was outlined, with explanation of the
need for ``Binding Notify,'' ``Binding Request'' and ``Binding
Acknowledgment'' packet types.

Mention was made of the idea of ``Simple Authentication,'' and how it
might be applied to the route optimization document.  Tony Li (co-chair)
pointed out that the route optimization proposal would be unlikely to
find acceptance by the area director if simple authentication were
included in the draft.  He suggested that a ``base'' draft of the route
optimization proposal be developed first.  He also suggested that an
Informational RFC could be produced as a companion document for the
route optimization proposal, and that implementors interested in
offering the less stringent authentication mechanism would probably be
interested in standardizing on the information approach, depending upon
market acceptance.

Charles Perkins accepted the responsibility of coordinating the
interoperability testing of implementations produced by the next IETF
meeting in Danvers.  A handful of organizations indicated that they plan
to begin implementation of the latest draft.  Tony Li mentioned that he
could possibly volunteer to get some equipment together to help the
implementors, but no firm commitment yet.

The editor hopes to release a new draft of the mobile-IP document in a
couple of weeks.