Subject: RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 31 Jan 2002 09:05:34 +0100

Jari,

Late reply !

  > >  - if the end of the tunnel is a mobile router, the final
  > >   destination is behind the router so a DO doesn't work (the
  > >   missing thing is the capacity of a RH to advance from an
  > >   intermediate destination to the next one).
  > 
  > I agree here but want to mention that this applies only to a
  > route-optimized or triangle mobile router case, another
  > way of doing it without this affecting is discussed in a draft,
  > http://search.ietf.org/internet-drafts/draft-kniveton-mobrtr-00.txt
  > with the use of bidirectional tunneling. 

=> This is getting into monet issues but I think 
it needs to be addressed here.
I agree that it is relevant for route optimisation 
of monet. But I don't see a reason for not 
having the right tools to allow for route opt
anyway since it doesn't cost anything extra. 
Both IPv6_NO_SRC and new type RH would allow 
for the routability nature in the receiver. 
So I think one of those 2 would be ideal. 

Hesham

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 31 Jan 2002 14:13:09 +0100 (CET)

> So I think one of those 2 would be ideal. 

Hesham,

I understand that this is a bit speculative but 
I'm trying to understand the details of the tradeoffs ...

Do you think the other two possible encodings (destination option 
or a different extension header altogether) would not allow
this behavior in the receiver?
It seems to me that at least a different extension header would have
close to identical properties to IPv6_NO_SRC.

  Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 31 Jan 2002 10:31:45 -0800

Hello folks,

> close to identical properties to IPv6_NO_SRC.

I think a new destination option would be workable.  I think that
a new RH type would be better, because it would be more like the
existing routing header, which is known to work.  Any solution should
be aware of what is likely to happen when the mobile node is itself
a router -- even though this matter has been declared out of scope.

Let's say that a node is in the middle of a list of intermediate
routing points, in a Routing Header.  We don't get to say why this
is.  Then we have to make Mobile IPv6 work for the case where that
node is mobile, or else prepare our apologies for future engineers
who have to undo our mistake.

The routing header solves this problem artfully, and my fear is
that any other suffciently artful solution will take a long time
to understand, specify, build, and test.

Regards,
Charlie P.