Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/mobileip/mobileip-minutes-94jul.txt

Text File | 1994-11-02 | 18KB | 333 lines

CURRENT_MEETING_REPORT_

Reported by Kannan Alagappan/Digital Equipment Corporation

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

The Mobile IP Working Group met twice during the Toronto IETF. The major
focus of these meetings was to discuss the remaining open issues in the
current base protocol and draft for mobile IP.


Agent Discovery

It was questioned again whether support for agent discovery and roaming
detection at the IP layer needs to be provided, and if so, how this
should be done in cooperation with any assistance from various
media-specific lower-layer protocols and in light of any administrative
or policy issues.  Questions included how to initially choose an agent
from the advertisements received and when to possibly switch agents upon
hearing of a ``better'' one in some new advertisement.  It was agreed
that an IP protocol for agent discovery must be provided that could be
used possibly where no other support is available, but a clear consensus
was not reached on the exact mechanism to be used.  After much
discussion, the chair stated the following mechanism:


     In the absence of link-level indications, a mobile node which
     already has an association with a foreign agent would continue
     that association (even in the presence of newly received
     advertisements from other foreign agents) until either (1)
     upper-layer protocols on the mobile node have expressed
     ``frustration'' or (2) the mobile node would normally attempt
     to re-register with its foreign agent.


When initially searching for an agent with which to register, the group
decided that a mobile node should listen for some time period (possibly
zero) to collect advertisements before choosing one.  This time period
should probably be configurable, but the group did not decide on what
the recommended period should be.  Further discussion of this issue was
deferred to the mailing list.

The chair also suggested adding wording around this section in the draft
explaining that other mechanisms for choosing a foreign agent were
likely to be an area of some experimentation during the initial stages
of interoperability and other testing.  One possibility raised during
the meeting but not discussed due to lack of time was to, instead, allow
reregistration when a ``better'' agent was discovered, but to do
something to dampen the maximum registration frequency to avoid
thrashing.

The way in which the draft currently discusses possible link-level agent
discovery methods, such as its discussion of PPP, was questioned.  The
draft now implies that the described methods are the only possible
methods, but in fact, there are likely to be many other methods for
different types of network media.  It was suggested by some that this
section in the draft was incomplete, or that it was inconsistent, or
that it should simply be removed entirely from the draft and left to be
specified elsewhere for each type of media.  No decision on this issue
was reached though, and future discussion of it was deferred to the
mailing list.

Another question raised was whether the lifetime of a registration could
be different from the lifetime in the agent advertisement.  It was
agreed that these could be different.  The lifetime of an agent
advertisement is the time before which a mobile node should expect to
receive another advertisement from the same agent, in order to verify
that the agent is still alive.  The lifetime of a registration is the
time period for which the registration (once completed) remains valid
and the home agent and foreign agent agree to cooperate to forward
packets for the mobile node.

A question related to these two lifetimes raised during the meeting was
whether to allow advertisements more frequently than one per second (the
existing lower limit in the ICMP router discovery protocol).  If the
advertisement lifetime and the registration lifetime were required to be
the same, allowing advertisements more frequently than one per second
(which means an advertisement lifetime of less than one second) would
force reregistration this frequently as well.  Since it was agreed that
the two lifetime values could be different, it was agreed that
advertisements could be sent more frequently than the current limit of
one per second.  In this discussion, it was also decided to place a
separate limit on how frequently a mobile node could reregister with its
agent.  This implies that a mobile node should not send reregistration
attempts more frequently than this, and that a foreign agent should not
try to impose a registration lifetime of less than this.  The group did
not decide what an appropriate lower limit on reregistrations should be,
though.

A question was also raised about the preference levels listed in an ICMP
router discovery message in which a mobility extension also appears (an
agent advertisement message).  As defined now, there is only a single
list of preferences in the message, and thus the existing meaning for
router discovery is possibly being overloaded.  Perhaps a system
administrator should be able to configure one set of preferences for the
advertised addresses for router discovery, but to have a separate set of
preferences advertised for agent discovery.  Discussion of this issue
was deferred to the mailing list due to lack of time in the meeting.


Agent Advertisement ``Mobility Extension''

It was suggested that a method is needed for a mobile node to recognize
from an agent advertisement if the advertising agent is only a home
agent (and thus does not support any foreign registration) or if it is
only a foreign agent (and thus does not support home registration, even
though it may be located on the home network for some particular mobile
nodes).  There are really four cases to be covered:


   o If an agent is neither a home agent nor a foreign agent, it will
     not include the mobility extension in its ICMP router discovery
     advertisements, and thus will not be mistaken for an agent by any
     mobile nodes.

   o If an agent is a home agent but not a foreign agent, it must
     advertise so that its client mobile nodes can notice it and detect
     when they have returned home.  The group decided to add a bit in
     the mobility extension to indicate whether an agent is functioning
     (at least in part) as a foreign agent.  In this case, this bit
     would not be set in its advertisements, allowing mobile nodes
     looking for a foreign agent to not waste its time and their own
     time attempting to register with it.

   o If an agent is a foreign agent but not a home agent, it will simply
     advertise as normal with a mobility extension.  The bit should be
     set indicating that it is functioning as a foreign agent.  Mobile
     nodes must be able to recognize the advertisements of their own
     home agents, presumably because they recognize the IP address of
     their own home agents, and thus will not attempt home registration
     with this agent.

   o If an agent is both a foreign agent and a home agent, it will
     advertise as above.  Since it is the home agent for some mobile
     nodes, they will be able to recognize this for themselves by
     checking the IP address of the agent from the received
     advertisement.


It was suggested that a way is needed for an agent to deregister one or
more mobile nodes currently registered with it.  This question broke
down into the following three specific cases:


   o For an agent to deregister all existing mobile node clients, it
     should begin sending a lifetime value of zero in its multicast
     agent advertisement messages, for some number of advertisements.
     The group did not discuss how many such advertisements the agent
     should send, nor what to do if at least one of them was not
     received (or acted on) by one of its registered mobile node
     clients.

   o For an agent to deregister a specific individual mobile node
     client, it should unicast one or more agent advertisements to that
     client with a lifetime value of zero.  As above, there was no
     discussion on how many such advertisements the agent should send,
     and what to do if at least one of them was not received (or acted
     on) by this specific mobile node client.  The group also did not
     discuss how to handle any confusion that may be caused on the
     mobile node as it perhaps also continues to hear the regular
     multicast advertisements from the same agent, probably with a
     non-zero lifetime value.

   o To advise new clients that it is currently disallowing new
     registrations, a ``busy'' bit in the mobility extension of the
     agent advertisement message was added.  The agent must continue to
     advertise so that its current clients can tell that it is still
     there and alive, but this bit will discourage new clients from
     wasting time attempting to register with it.


It would be helpful for a mobile node to be able to detect from an
agent's advertisements that the agent has just crashed and rebooted, and
to be able to distinguish this from the sequence number in the agent's
advertisements simply ``rolling over.''  The group decided that upon
rebooting, an agent should multicast a ``reset'' signal in its
advertisements for some small multiple of that agent's configured
advertisement lifetime value.  This reset signal will be sent as a
normal agent advertisement with a reserved sequence number of zero in
the advertisement.  This implies that zero must not be used as a
``real'' sequence number value and that upon rolling over, the sequence
number should increment from its maximum value to one, skipping the
value zero.

Two other suggestions were made to include additional information in the
mobility extension:  including the IP subnet prefix in the advertisement
and including a list of other foreign agents on the same subnet in the
advertisement.  Both of these suggestions were withdrawn by their
proposer.


Packet Format/Protocol Issues

It was asked if a single type field value could be used in the
registration request message from the mobile node to the foreign agent,
and from the foreign agent (or the mobile node) to the home agent.
Right now, the draft specifies a different field from the foreign agent
to the home agent, but this then complicates the authentication question
in this case.  By using a single value, this can be included uniformly
in the computation of the authentication extension, and can be
authenticated by the mobile node and simply passed through the foreign
agent (since the foreign agent does not change the value) to the home
agent.  Then a bit is needed somewhere in the registration request
message to distinguish between the message sent from the mobile node and
that sent by the foreign agent.

In our discussion of the mobility extension in the agent advertisement
message, the request to include the IP subnet prefix in the
advertisement was withdrawn (above).  The group discussed here whether
to allow this information to be added to the advertisement in another
(different) extension.  The group agreed that this is where this
information properly belongs.  This information is intended to possibly
support whole mobile networks, rather than only simple mobile nodes.

There was much discussion as to the correct address to use as the IP
source address in the registration request packet sent to the home agent
when a mobile node is registering in ``popup'' mode (acting as its own
foreign agent, or registering without a foreign agent, depending on
which philosophy you view it as).  Some considered using the care-of
address (the newly assigned temporary address) to be the most natural
source address, but others argued just the same that using the home
address of the mobile node was more natural.  In the end, the group
decided to use the care-of address, since using the home address instead
would complicate returning a successful registration reply packet (it
would have to be tunneled), would make it very difficult to return a
rejection registration reply (how do you set up the tunnel from the home
agent if the registration was rejected?)  and would make it nearly
impossible to correctly return any ICMP error messages to the mobile
node that might possibly result from its registration request message.


Replay Protection (Timestamp Versus Nonce)

There was much discussion during the meeting, as well as before and
after the meeting, on the subject of how to protect against replay of
registration messages.  Specifically, the issue was whether to use
timestamps or nonces in the protocol.  A group of participants met over
dinner to discuss this topic and agreed on nonces.  This was then raised
before the whole working group in the meeting, and there seemed to be
support for this method, but the group did not completely agree on this
issue.  If nonces are used, it was questioned what the correct size for
the nonces should be, and the group agreed that 32 bits was the right
size.

In the end, on the issue of timestamps versus nonces, the group decided
that the chairs will go to to Security Area Director(ate) with a brief
on both proposals, and that the received advice will then be shared with
the working group on the mailing list.  It is suspected that if the
advice strongly favors one of the proposals, the working group will
adopt that proposal.  In the absence of strong advice, the working group
will further discuss the proposals on the mailing list and hopefully
reach consensus on one of them.


Additional Miscellaneous Topics

The current draft states that a foreign agent must drop arriving
encapsulated packets if it cannot deliver them locally to a visiting
mobile node.  It was asked if this ``must'' could be changed to a
``should,'' to allow room for smarter foreign agents to do something
else to eventually get the packet to the destination mobile node.  The
fear here, though, is that a foreign agent that thinks it is smart but
isn't could easily put the packet into a loop by trying something like
this.  The group acknowledged that extensions such as route optimization
could override such a ``must'' when defining suitable smarter methods
for foreign agents, but left unresolved whether to change the word in
the base draft.  This issue will be taken up on the mailing list.

Some people thought that the wording in the current draft was
inconsistent or incomplete in its description of how the authentication
on registration packets was computed.  One particular question was about
which bytes of the packet were included in the authentication
computation.  In the draft now, sometimes the UDP header is included,
and sometimes it is not included.  Also, if it is included, it is
necessary to specify what the UDP checksum should be set to when the
authentication is computed.  The group did not make any decision on this
topic, but instead deferred discussion to the mailing list.  It must be
considered if there is a good reason to ever do authentication over the
UDP header, and if there is no reason to, it should not be included.
Also, if there is some reason to include it, it should be considered
whether the IP header also needs to be included.

The group talked for a short time about how to ease the configuration
burden on a mobile node.  In particular, this discussion referred to how
to operate a mobile node without needing to configure into it the IP
address of its home agent.  For example, a site may want to change which
of its hosts serves as the home agent while some of its mobile nodes are
away from home, making it difficult to achieve this reconfiguration.
Two suggestions were proposed.  First, a mobile node could be allowed to
use a directed broadcast to its home network, such as to inquire who its
current home agent is.  This request and its reply would need to be
authenticated.  The second suggestion was to have some type of records
defined within the DNS to allow a mobile node to find its own (current)
home agent address.  This method, though, would require some cooperation
from the mobile node's prospective new foreign agent that it is then
trying to register with:  the mobile node needs to find its own home
agent address to register, but until the mobile node is registered, the
foreign agent will not pass packets (such as the reply) to it.
Discussion of this issue was deferred to the mailing list.

The use of ``soft state'' for tunneling, as used in the current draft
(and also used in IPAE), was questioned.  In IPAE, the tunnels are
fairly static in configuration, but in mobile IP they are likely to be
much more dynamic, as mobile nodes move around.  The question was
whether soft state still works or is appropriate in this environment.
Discussion of this question was deferred to the mailing list.

When a mobile node leaves its home network, its home agent may send a
gratuitous ARP for it, and when the mobile node later returns to its
home network, the mobile node may send a gratuitous ARP for itself.  The
current draft states that each such use of gratuitous ARP may be sent
only once, but it was suggested in the meeting that this restriction be
relaxed to allow some small number of retransmissions in case of dropped
packets.  The group did not reach any decision on this issue and
deferred discussion of it to the mailing list.

Finally, it was suggested that people should think about what issues are
involved in mobility for IPng, such as considering if any solutions that
were rejected for IPv4 could now be made to work in an IPng world.  The
chair stated that for now, the group should concentrate on finishing
IPv4 mobility, but Greg Minshall requested that people send thoughts on
IPng mobility to him.


Administrivia

It was suggested that the group should have an implementors' meeting in
October or November.  Discussion of this meeting, including possible
time and place, will take place on the mailing list.