Thierry Ernst writes:
> Michael Thomas wrote:
> > I'm aware that this is only my scenario, but this is
> > what I think a naive implementation would do. Ie,
> > the mobile router would think it's supposed to send
> > a BU when it see something come in from its home agent
> > tunnel interface, the MN (or another MR) would
> > think it's supposed to send a BU...
>
> I agree that a MN behind the MR is supposed to send a BU, but I disagree
> that the MR "is supposed to" do it as well.
If this is true, what is the purpose of putting a subnet prefix
into the BU at all? How does the MR (ignoring MN for the moment)
eliminate triangular routing through its HA? Surely the purpose
of adding the prefix wasn't just to say that MN was reachable
at a range of IP addresses.
> First, the MR is not the
> final destination of the packet. Second, if you think about a naive
> implementation, MR would send a BU to the sender that appears in the
> inner header in the encapsulated packet, i.e. the CN of MN "behind"
> MR. And what would contain the BU ? A binding between the MR's home
> address and its COA. This does not give much usefuk information to the
> CN.
Remember it's the MR's home _prefix_, not address. That's
what my reference to the -13 draft was about below.
> Then, the issue your are describing (including two addresses in the
> routing header) would not happen with a naive implementation of MRs.
> If any proposal would advocate such use of the routing header, I think
> it should also describe how this should be done.
I think the problem here is that the addition of prefix
to the BU is not sufficient to support mobile routers,
and as such it's open to interpretation what the
implementation should do.
While I generally like the addition of subnet prefix
to BU's (mainly because it treats BU's like the routing
updates that they are), it may actually be better to
get the MIP WG to take the whole subject of MR's up
as working group item and delete it till then because
it may unfairly prejudice the final outcome.
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]
--------------------------------------------------------------------
