[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    (IPng 2664) Discussion about new direction for mobile IP
From:       Charlie Perkins <charliep () watson ! ibm ! com>
Date:       1996-12-31 20:00:45
[Download RAW message or body]


Dave Johnson and I have been puzzling lately over how mobile IPv6
can handle ingress filtering by border routers.  For IPv4, there
is a concerted effort going on now within the mobile-IP group
to solve this problem.  Results are supposed to be forthcoming
before the next IETF meeting, and will likely involve reverse
tunneling along with some new controls.

Since recent history indicates that such filtering will be
common in the future Internet, I think that we can expect
similar operations for IPv6 routers.  The bottom line is
that expecting the mobile node to use its home address as the
source IPv6 address when delivering packets to correspondent
nodes is asking for trouble.  If this is true, our current
mobile IP has to change.

Some time ago, a proposal was floated by Fumio Teraoka to
do mobility by a "source rebinding" procedure.  We had a number
of objections to his proposal, based on the need for way too
many authentications and amount of overhead in each packet.
However, taken more abstractly, the ideas of rebinding the
source address versus "rebinding" (say, by way of a routing header)
the destination address are dual (as has been noted by Christian
Huitema and others).  Thus, we (Dave and I) have been drawn to
reconsider the merits of source rebinding.  It is, of course,
essential in this regard to remember that a mobile node can
use the methods of stateless or stateful autoconfiguration to
obtain a topologically significant, but temporary, "care-of
address" (to use our existing terminology).  What we propose
to change is the way that the care-of address is used.

Briefly, we would like to send a new kind of Binding Update
to the correspondent node, so that it translates the source
address of received packets from the mobile node's care-of
address into the mobile node's home address.  This care-of
address could, symmetrically, be used as the destination address
of packets sent from the correspondent node to the mobile node.
All of the connection state information (e.g., in the correspondent
node's PCBs) would still be kept in terms of the mobile node's
care-of address.  The translation would occur as part of the
operation of the IPv6-layer destination-cache lookup for the
mobile node's home address.

One benefit of the above, is that routing headers are no longer
needed.  In fact, if life were sufficiently good and correspondent
nodes could be counted on to maintain all such source rebinding
information in nonvolatile storage, such a scheme is practically
minimal as far as packet overhead is concerned.

However, if the correspondent node loses track of the source
rebinding information for the mobile node, it will start to
get perfectly good packets that seem to emanate from the
mobile node's care-of address.  If that (rare) occurrence would
be acceptable, then life is good.  This note can be considered
over and done with.

========================================================================

If, on the other hand, the mobile node needs to protect against
such losses at the correspondent node, then we have to design more
protocol.

There are several possibilities:

1) We can require the mobile node to indicate, in each packet sent
   to the correspondent node, that the source address is not
   the "real" source address.  Then if the correspondent does
   not have a binding, it returns ICMP to the source address
   of the packet, and the mobile node (after receiving the ICMP)
   knows to reissue the source rebinding information.
   1a) We can have a bit in the header.
   1b) We design a new destination option for the forward indication
       by the mobile node.
2) The correspondent node can be required to use routing headers
   anyway.  Then, the mobile node will know that if it gets
   a datagram without a routing header, something is wrong.
   This strategy fails when the mobile node cannot expect to
   get an answer from the correspondent node.  Thus, it is
   really not acceptable.

If (1), it would be REALLY NICE to have a bit in the header for
this indication.  Especially before they get solidly used up.
Perhaps one of the bits earmarked for private use by ISPs in the
last IETF could be allocated for this use (the "source address
should actually be bound to something else" bit).  Otherwise,
if the mobile node has to use a destination option for this
purpose, the typical case will require enough padding to make
this an 8-byte overhead, by the rules for aligning options.
Note that the asymmetric 8-byte overhead is still better than
the asymmetric 24-byte overhead required by current mobile IPv6,
because routing headers take 24 bytes (minimum).

========================================================================

There are some other issues that need to be worked out, but
I think they are minor (involving, for instance, address lifetime
and multihoming at the mobile node).  At least I think we can
solve them.

The purpose of this note is to float this change in direction
for consideration by the working groups, and ask for comments.
It seems a shame to take on such a major change at this late
date, when we are practically done with the protocol.  However,
the need is great, given the ingress filtering we can expect.
To mitigate the impact of the change, I will observe that we
will actually be able to use quite a bit of the existing protocol
mechanism that already exists in the current Internet Drafts.

Your comments are earnestly solicited.

Thanks in advance,
Charlie P.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com/pub/ipng
IPng Home Page:          	      http://playground.sun.com/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com

[prev in list] [next in list] [prev in thread] [next in thread]