Subject: Re: [MOBILE-IP] IPv6 Mobility draft comments

From: "Alan O'Neill" <[email-masked]>
Date: Fri, 12 May 2000 18:07:37 +0100

Thanks Charlie,

> -----Original Message-----
> From: Charles E. Perkins [SMTP:[email-masked]]
> Sent: Saturday, May 13, 2000 12:39 AM
> To:   [email-masked]
> Cc:   Mobile IP Mailing List
> Subject:      Re: [MOBILE-IP] IPv6 Mobility draft comments
>
>
> Hello Alan,
>
> >      on page 20 it states that  'Since correspondent nodes cache
> bindings,
> > it is expected that
> >    correspondent nodes usually will route packets directly to the mobile
> >    node's care-of address, so that the home agent is rarely involved
> >    with packet transmission to the mobile node'
>
> This means the the correspondent nodes usually have valid bindings
> for the mobile node, unless the mobile node wishes otherwise.
>
        [AWO]  Or the CN wishes otherwise. How big a concern do you think
the
        case of the large server might be wrt IPSEC, binding processing and
header
         manipulations ?

> > This clearly gives the right for the CN to send to MN-HA whilst the MH
> > assumes it won't, leading to repeated (but rate limited) sending of BU's
> to
> > CN. This seems overly loose to me, and the MH shouldn't be guessing like
> > this. Would it not be better if the CN sent something like a BR to
> trigger
> > BU from MN ?
>
> With the interpretation above, the CN is not granted such rights.
> Of course, we could not necessarily prevent the CN from abrogating
> those rights anyway, but thems the breaks.  I would much prefer to
> allow the mobile node to send unsolicited Binding Updates as it
> is in the current specification.
>
        [AWO]  Ok

> > Given the discussion on the list wrt forwarding control, reverse
> tunnelling
> > etc this would also enable CN to indicate it's policy directly, whilst
> > giving the MN some opportunity to override this policy based on it's
> > configured policy (from Home operator etc).
>
> I didn't get the part about how CNs were involved with reverse
> tunneling.
>
        [AWO]  There not, but people were discussing 'corporate'
        control over policy as to how the CN and MN forward using either
bindings
         or HA encaps or reverse tunneling. I felt if this was going to be
considered
        then the CN BR would at least enable the CN to express it's view
directly.
        Probably a rat hole given the diverse views on the subject.

> Furthermore, the mobile node should be able to execute whatever
> protocols it wants to execute without getting explicit permission
> from the Mobile IPv6 document.  Reverse tunneling in IPv6 does
> not have sufficient interaction with Mobile IPv6 to merit inclusion
> in that document.  If a node wishes to tunnel, I don't see that
> Mobile IPv6 should cause it to ask permission from anyone.
>
        [AWO]  Understood.

> > 2) I couldn't find any specific reference to reverse tunneling support,
> or
> > it's reasons for not being included (maybe should be mentioned for
> > continuity reasons wrt MIP4). We may also given above need to re-install
> > reverse tunneling support as I strongly agree with Fred's position on
> > this...
>
> I hope it is obvious from the above that I do not think we need
> this.  And, especially, I do not think it has to be resolved before
> we go to Proposed Standard.  If you would like to submit another
> Internet Draft detailing a reverse tunneling procedure, then that
> could be considered as a separate matter.
>
        [AWO]  Ok. Just trying to establish continuity from MIP4 which
        does explicitly mention reverse tunneling but as you say, even there
         the detail is still a separate spec.

> > On returning home whilst communicating, we may need to support
> forwarding
> > which I think that means that we need new text in 10.19, indicating that
> > the BU-HA = Previous CoA and Bu-CoA=MN-HA...(Bizarre I know but is it ok
> ?)
>
> I couldn't parse this.  Does it mean that the mobile node should
> tell the previous router that it has gone home?  In that case,
> I reckon that the previous router still has to tunnel the packet
> back to the mobile node, presumably with the tunnel destination
> set equal to the home address.
>
        [AWO]  Yes thats it. The present text does not cover the case of a
mobile
        returning home and wanting temporary forwarding from the previous
CoA to the
        home address. The text only covers forwarding from a previous CoA to
the
        present CoA (ie not home).

> > Also, in the case of rapid movement, policy or failed communication with
> HA,
> > the MN may still be receiving tunnelled packets when it changes CoA and
> > therefore won't we end up with multiple encapsulations ? It works but
> should
> > it be prevented...
>
> What is wrong with multiple encapsulations?  Are you suggesting that the
> intermediate encapsulator should first decapsulate?  This seems like
> it would be a nightmare to specify correctly
>
        [AWO]  I guess I was worried about any potential for these multiple
encaps
        to continue to build up. Certainly not suggesting decaps because it
would
        be a nightmare as you say.

> > Finally, the section does not mention how this forwarding state is
> > recommended to be eliminated (time-out or explicit cancel by MN). The
> latter
> > would seem better with the lifetime as a fail safe ?
>
> I thought that the mobile node should typically make an explicit
> determination to invalidate bindings at the appropriate correspondent
> nodes.
        [AWO]  Thats the sensible thing yes.

> > 7) General: Hand-over modes
> >
> > The 10.9 Forwarding section deals with 'unplanned' hand-over whereby the
> MH
> > is now at the new CoA, remembers the old CoA and old HA, and so installs
> > forwarding. The draft does not however deal with planned hand-over
> (routed
> > at old HA as in cellular) which may be useful for the IP fast hand-over
> > work. In planned hand-over (see EMA draft), the 'system' knows where you
> are
> > going and can therefore install the temporary tunnel before you leave
> and
> > subsequently lose the link to the HA. Probably out of scope for this
> draft
> > (big divergence from model) but worth looking at the cellular equivalent
> > messaging for comparison.
>
> I don't think that this belongs in the current Mobile IPv6 draft.
> Furthermore, it is possible that cellular handovers will become
> more initiated by the mobile nodes as IPv6 gains wider deployment.
>
        [AWO]  Agreed on both counts - but I'm not sure that the latter
statement
        eliminates the speed benefits of forward hand-over rooted at the old
node
        whether initiated by MH or node itself. Best to leave this for know
as a new
        draft from us will probably cover this in more detail soonish ok.

> Regards,
> Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 12 May 2000 11:29:17 -0700

Hello again Alan,

>         [AWO]  Or the CN wishes otherwise. How big a concern do you
>                think the case of the large server might be wrt IPSEC,
>                binding processing and header manipulations ?

I think that IPsec is likely to get major hardware assist,
and that the use of IPsec for other reasons will swamp out
any performance consideration for the processing of the
relatively infrequent Binding Updates that the server may
receive from mobile nodes.

Regards,
Charlie P.