Subject: Re: [mobile-ip] Coexistence with other uses for routing header

From: Alper Yegin <[email-masked]>
Date: Wed, 5 Sep 2001 11:34:53 -0700 (PDT)

>  > >  > If we are going to make route optimization work with other uses of 
routing 
>  > >  > headers, why not make it work even when Home Address of a mobile node 
is 
>  > not 
>  > >  > only the final destination of a packet, but also maybe an intermediate 
hop?
>  > > 
>  > >    Are you talking about the case where a mobile host is behind
>  > >    a mobile router? If so, how would CN know what order to put
>  > >    the routing headers in given two BU's?
>  > 
>  > I wasn't really thinking about that. It's just that CN is sending a packet 
that 
>  > has to go through a MN (which is away from home and CN knows its CoA).
> 
>    I guess I'm being really dense here, but...
>    something that allows a packet to traverse a
>    mobile node node is a router, no?

Mobile node doesn't have to be a "router", it just needs to "forward" the packet 
though. It's just like when it forwards the packet to itself when the 
destination of a packet is CoA and the next hop is Home_Address.

I can't think of any application that needs this right now, but I think the 
practice was to allow future protocols using routing header work with route 
optimization.

alper

alper

---

From: Michael Thomas <[email-masked]>
Date: Wed, 5 Sep 2001 12:22:13 -0700 (PDT)

> practice was to allow future protocols using routing header work with route 

   We're probably off in the definitional weeds here,
   but I'd think that something that moves packets
   toward their destination instead of toward
   themselves is acting like a router, regardless
   of what caused them to do so. Practically
   speaking, I'd sure like some knob -- like the
   router on/off switch -- which controls whether
   my node acts as a forwarder regardless of how
   something is trying to get me to forward.

		Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 05 Sep 2001 12:52:09 -0700

Hello folks,

For the purposes of what to put into the revised specification,
I think the main result of the recent discussion would be that
the mobile node's home address does not have to be the last stop
along the source route indicated in a routing header.  This part
of the revision should not be the deciding factor in any
specification about mobile routers or further route optimization,
and so I have reformulated the paragraph as follows:

     It is possible that a correspondent node, having no knowledge of the
     mobile node's care-of address, would still (for reasons unspecified
     here but not necessarily related to mobility) attempt to deliver a 
     packet, either to or by way of the mobile node's home address,
     by using a routing header.  If the correspondent node subsequently
     accepts a Binding Update and creates a Binding Cache entry for the
     mobile node, then afterwards, the routing header used by the
     corresponding node which includes the mobile node's home address
     SHOULD also include the mobile node's care-of address.
     The correspondent node SHOULD put the mobile node's care-of address
     as the intermediate node address immediately preceding the
     mobile node's home address.  When the care-of address is the
     first intermediate node address, this implies that the care-of
     address is to be placed in the Destination Address of the IPv6
     headerd, and the mobile node's home address is the first entry
     in the type 0 routing header.  Otherwise, the correspondent 
     node MUST place the mobile node's home address immediately 
     after the care-of address entry of the routing header, following
     all other intermediate node addresses that would have
     already been in the routing header before the creation
     of the Binding Cache entry for the care-of address.

I hope this is better.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Sep 2001 18:34:40 +0200

I hope this is better.
   
=> yes but you should add something about the possible reversing
of this by the receiver. This issue is easy to solve if it is MN
but difficult if it is not. Has someone a simple proposal?

Thanks

[email-masked]

PS: reference is RFC 2460 section 8.4