Hi all,
I have cc to the MIP WG because I think this discussion falls in its
interest.
Michael Thomas wrote:
> Steve Deering writes:
> > At 1:03 PM -0700 5/29/01, Michael Thomas wrote:
> > > Where there is ambiguity, however, is in the host's construction
> > > of the routing header. Consider the situation where you have a
> > > mobile host behind a mobile router, each of which send binding
> > > updates to a correspondent node. How does the correspondent
> > > node know which order to put the routing headers in?
> >
> > Mike,
> >
> > You'll have to spend more time educating me on the details of the
> > scenario you have in mind. I would hope and expect that some
> > encapsulation/decapsulation is going on at the mobile router,
> > in which case you might have one routing header as part of the
> > inner (encapsulated) packet, and one routing header as part of
> > the outer (encapsulating) packet,
>
> I don't think there are any answers for this at
> within mipv6.
This case was never really considered so far in any of the MIP specs.
There is no answer to this specific case for the reason that mobile
networks are not explicitly addressed in any of the WG specs (indeed,
HMIPv6 which is a WG item does have a word about this and in this case
the CN wouldn't endup with 2 BUs).
> > which is a different case than
> > having multiple routing headers in a single extension-header
> > chain. I was assuming the question applied to the latter case,
> > though the semantics of encapsulation case is also obvious.
>
> This is mostly a mipv6 issue, but suppose you have:
>
> MN------->MR------------------------>CN
>
> When the mobile node moves, it sends a BU to the CN.
> When the mobile router moves, it too sends a BU to the CN.
This is only your scenario. You could think of any scenario you want.
Anyway, this is something I have already raised in the MIP WG and this
is presumably a case where MIPv6 would fail.
> The CN now has a binding entry for both the mobile node
> and the mobile router in its cache. Now if this
> is going to work at all (which I think is the $64
> "if") CN would need to construct a packet like:
But, first, why should the CN get two BUs ? The CN is not a CN for the
MR. Unless you refer to my draft
http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt
which proposes that the MR be in charge of all the mobility management
of the mobile network. But this is just a proposition, and it mainly
focus on the case where the nodes behind the router wired and fixed
nodes, not mobile nodes.
Then, your issue is rather a proposal for a solution, and it would be
better if you could first specify your solution, this would highly
highlight the issue you are trying to discuss.
>
> IP: dst=CoA(mr); RH: dst=CoA(mn); RH: dst=Home(mn);
>
> to prevent the packet from going through the
> home agent of either the MN or MR.
>
> Yet, MN and MR might know nothing about each
> other (the general case, I'd think) and CN
> doesn't have any clue about the far end
> topology either. It just has two binding
> entries in its binding cache with no way
> to correlate them, let alone set the proper
> ordering.
>
> > In the absence of such specs, the Routing header contents will just
> > continue to be provided manually, as in source-routed pings and
> > traceroutes.
>
> Yes, I should make it clear that this isn't a
> ipng ambiguity.
>
> Mike
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
--
* mailto:[EMAIL PROTECTED] Tel +33 (0) 4 76 61 52 69
* INRIA Rhone-Alpes Projet PLANETE (fax 52 52)
* and MOTOROLA Labs Paris
* http://www.inrialpes.fr/planete/people/ernst/Welcome.html
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
