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

Text File | 1995-05-26 | 12.0 KB | 251 lines

CURRENT_MEETING_REPORT_

Reported by David Johnson/Carnegie Mellon University

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

The minutes were prepared by Dave Johnson and edited for clarity by the
co-chairs.


Introduction

The Mobile IP Working Group met twice during the week, once on Tuesday
afternoon and again on Wednesday afternoon.  Tuesday's meeting was
devoted to the discussion of a number of issues in detail, and
Wednesday's meeting was devoted to a line-by-line review of Version 9 of
the base protocol draft and a short presentation on the Route
Optimization extensions.


Patent Issues

IBM holds a patent covering work done by Charlie Perkins on mobile IP.
In San Jose, the group decided to send a letter to IBM requesting a
no-cost license for use of this technology in the Mobile IP protocol,
but Tony Li announced that he had not been able to get this letter out
until last week.  A reply has not yet been received from IBM, but
Charlie Perkins and John Tavs (IBM Raleigh) told the group unofficially
that IBM's lawyers are working on it.  IBM also holds a patent related
to the use of nonces for replay protection, and we are likewise pursuing
a no-cost license from IBM to use this technology in Mobile IP. If you
are interested in becoming a ``test case'' for the IBM patent licensing,
contact John Tavs.


Implementations and Interoperability Testing

Surprise was expressed that there does not seem to be much in the way of
implementation progress on the protocol to date, although IBM has
completed an implementation, and several additional implementations are
in progress.  It seems we have been busy with other things, such as
getting the protocol definition worked out.  Charlie Perkins is
coordinating implementation interoperability testing, and the mailing
list will be used to discuss implementation issues and progress.  A
small group of implementors met briefly after the Tuesday working group
meeting, and it was suggested that the group would probably hold an
interim meeting for interoperability testing sometime late this summer.


Broadcast and Multicast Support


Some applications that people may want to run require the ability to
send broadcast or multicast datagrams to mobile nodes away from home,
and the ability for mobile nodes away from home to send broadcast or
multicast datagrams.  The example of running NetBIOS was briefly
discussed.

For broadcast support, it was decided to add two new flag bits to the
Registration Request message:  one bit to request the home agent to
forward all broadcast IP datagrams from the home network to the mobile
node, and a second bit to indicate that the mobile node is registering
with its own dynamically-assigned care-of address rather than with a
care-of address associated with a foreign agent.  To encode these bits
in the Registration Request, it was decided to change the existing Code
field to be a byte of flags.  One bit was essentially already used in
this byte to indicate to the home agent to remove all previous
simultaneous bindings for the mobile node.  Two more of these bits were
used for the two new bits to support broadcast datagram forwarding, and
since there are now some spare bits, one more was used to replace the
existing extension to indicate availability of support for the minimal
encapsulation protocol.  When needed, there are still four more spare
bits in this byte.

When requested by the mobile node (with the first of the two new bits in
the Registration Request), the home agent forwards all received
broadcast IP datagrams to the mobile node.  The method used to forward
each depends on whether the mobile node is using its own
dynamically-assigned care-of address or is registered using a care-of
address associated with a foreign agent (indicated by the second of the
two new bits when the mobile node registered).  When using a
dynamically-assigned care-of address, the home agent simply tunnels each
received broadcast IP datagram to this care-of address.  When registered
through a foreign agent, an extra level of encapsulation is required to
indicate to the foreign agent which mobile node to deliver the tunneled
datagram to when it is received by the foreign agent.  The home agent
first encapsulated the broadcast datagram in a unicast datagram
addressed to the mobile node's home address, and then tunnels this
encapsulated datagram to the foreign agent.  When received by the
foreign agent, the unicast encapsulated datagram is detunneled and
delivered to the mobile node in the same way as any other datagram.  The
mobile node must decapsulate this datagram to receive the original
broadcast datagram.  The extra level of encapsulation is necessary,
since otherwise, the mobile node's home address would not appear
anywhere in the tunneled datagram received by the foreign agent.
Similar extra encapsulation is not required when using a
dynamically-assigned care-of address, since the tunnel then terminates
with the mobile node rather than with a foreign agent.

For multicast support, it was decided that no changes to the Mobile IP
protocol are required.  There will be an informational appendix in the
draft, though, describing how multicast would work.  Tony Li and Charlie
Perkins will craft the text for this appendix.

In a small digression on this subject, it was realized that the care-of
address for a mobile node must be a unicast address, and decided the
home agent should reject any registration attempt that gives a broadcast
or multicast address as the care-of address.



Change In Use Of MD5

Following the recommendation of the IP Security Working Group, we agreed
to change the way in which we use MD5 to authenticate Mobile IP
messages.  Instead of


     MD5(key || message || key)


we will now use


     MD5(key || MD5(message)) (1)



     (1) Charlie Perkins and Jim Solomon attended the IPSEC session
     on Thursday morning at which it was determined that there are
     problems with this suggested change.  Therefore, Charlie and
     Jim agreed that the Mobile IP draft should remain unchanged
     until IPSEC itself comes to consensus on the proper way to use
     MD5 to compute an authenticator.  -- Jim Solomon



Preferences In Agent Advertisements

The question was raised about whether we really needed or should be
using the router preferences in Agent Advertisements as mobility agent
preferences.  This is overloading their meaning, since they are already
used to giving the preferences for nodes choosing a first-hop router,
and the preferences for choosing a mobility agent may be different.  The
current version of the Mobile IP draft also left several unanswered
questions about particular values to use for the preference, such as
requiring that a home agent that does not also provide foreign agent
services use a preference less than the highest foreign agent
preference, but it had not specified what the cutoff preference should
be.  It was decided, instead, that the existing ``F'' (foreign agent),
``H'' (home agent), and ``B'' (foreign agent busy) bits in the Agent
Advertisement were sufficient, and that all wording about preferences
should be removed from the Mobile IP draft.



Knowing The Home Agent Address

The current Mobile IP draft requires a mobile node to be configured
specifically with its own home agent's IP address.  The group has had
much discussion in past meetings about how this was inconvenient if, for
example, the node serving as home agent had to be changed while the
mobile node was away from home.  It was decided to relax the wording in
the draft to allow other alternatives.  For example, one alternative is
for the mobile node to use a directed broadcast to send the Registration
Request to the home network, and for a home agent that receives a
Registration Request sent to a broadcast address to reject the Request,
including its real IP address in the rejection Registration Reply
message.  To support this, it was decided to add a Home Agent Address
field to the data in the Registration Reply, so that this address is
available to the mobile node after the foreign agent forwards the
Registration Reply to the mobile node.  Another alternative method for
sending the Registration Request to the home agent without specifically
knowing the home agent's IP address would be to use some configured
address to address a ``virtual home agent''; at all times, some node in
the home network would respond to this IP address in addition to its own
real IP address, but which node this is could be changed by the home
network administrator without reconfiguring the mobile nodes belonging
to this home network.  Each home network using this alternative could
choose its own address to serve as the virtual home agent address, so no
reserved address is required.


Addresses In Registration Request and Reply Messages

There was some question and confusion about what addresses are used as
the source and destination address for Registration Request and
Registration Reply messages.  After some discussion, the group decided
on the following.

For registering without a foreign agent, the source address on the
registration request should be the temporary address that has been
acquired by the mobile node for its care-of address, and the destination
address should be the address that the mobile node uses for its home
agent.  For the Registration Reply, the source address should be copied
from the destination of the Registration Request, and the destination
should be copied from the source address of the Registration Request.

For registering with a foreign agent, the Registration Request from the
mobile node to the foreign agent should have a source address of the
mobile node's home address and a destination address of the foreign
agent, copied from the source address of the Agent Advertisement in
which the mobile node learned of that foreign agent.  The foreign agent
then sends the Registration Request on to the home agent, with a source
address of the ``non-mobile side'' of the foreign agent, and a
destination address of the home agent, copied from the Home Agent field
of the Registration Request.  The Registration Reply sent by the home
agent back to the foreign agent should be sent with a source address
copied from the destination address of the Registration Request to which
it is replying, and a source address copied from the destination address
of this Registration Request.  Finally, when the foreign agent sends the
Registration Reply on to the mobile node, the source address should be
copied from the destination address of the original Registration Request
from the mobile node, and the destination address should be the mobile
node's home address.


Route Optimization

Dave Johnson made a short presentation on the operation of the proposed
Mobile IP extensions for Route Optimization.  In the base Mobile IP
protocol, all datagrams for a mobile node always must go through that
mobile node's home agent, adding overhead to the Internet and adding
latency in eventually delivering each datagram to the mobile node.
Route Optimization allows a correspondent to learn and cache the care-of
address of a mobile node, and to then use this binding in tunneling its
own datagrams directly there.  The current draft for Route Optimization
is draft-ietf-mobileip-optim-01.txt, by Dave Johnson, Charlie Perkins,
and Andrew Myles.  Comments on the draft should be sent to the Mobile IP
mailing list.


The Next Step

Finally, the group discussed what the next step at this point should be.
After the line-by-line review of the base draft, it appears we are very
close to closure on the base draft, except that the patent issues
described above have not yet been resolved.  Charlie hopes to have an
updated (and final, at least for implementation purposes) draft out by
the end of the month.

The group considered whether to wait for the resolution of the patent
issues before going to Proposed Standard status, or to remove from the
protocol all features and technology related to the patents and to go to
Proposed Standard right away.  The group decided for now to wait, while
completing the base draft, continuing work on the Route Optimization
extensions, and gaining implementation and interoperability experience.