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.
> 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.
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:
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]
--------------------------------------------------------------------
