Subject: [MOBILE-IP] Reverse Tunneling (encapsulated delivery)

From: "Kevin Purser (EUS)" <[email-masked]>
Date: Wed, 10 May 2000 15:52:57 -0500

Hello all,

A couple of questions regarding the draft on reverse tunneling
(draft-ietf-mobileip-rfc2344-bis-01.txt), encapsulated delivery method:

1) As described in Sec 3.3, the encapsulated delivery style extension must
be included after the MN-HA Auth extension and before the MN-FA Auth
extension.  Additionally, the FA must consume the extension.  The problem
that arises is that the authentication value calculated by the MN includes
this extension (by virtue of it's placement among the extensions) and this
authentication value can only be verified by the HA/AAA, not the FA.  So
after the FA removes the encapsulated delivery extension, it invalidates the
authentication value, and is incapable of calculating a new value.  How
could this be remedied?  It is imperative that the FA remove this extension?

2) I have not seen any mention of the protocol behavior from the FA-->MN for
regular data packets.  Shouldn't these packets be encapsulated as well to
allow the MN to receive multi-/broadcast packets from it's home network?

Kevin Purser
Software Engineer III
ERICSSON, INC.
2100 Shattuck Avenue
(Enter on Addison Street)
Berkeley, CA  94704-1209
Phone: (510) 305-6100
Fax: (510) 981-4016

> -----Original Message-----
> From: Gopal Dommety [SMTP:[email-masked]]
> Sent: Wednesday, May 10, 2000 10:38 AM
> To:   [email-masked]
> Subject:      Re: [MOBILE-IP] Presentation slides LA '96 / Adelaide
>
> Charlie:
>
> >I believe that the functionality described by Gopal is a
> >subset of the functionality in our Regional Registration
> >draft, where basically our GFA entity is allowed to be
> >selected dynamically and associated with the mobile node
> >at the time of the regional registration.  If there is
>
>         Could you elobrate a bit more on how the Regional
>  Registration covers this draft?
>
> The basic difference is that the Regionalized Tunnels is based on a
> centralized approach and the local anchoring
> is a distributed approach.
>
>
> >Since we have had this draft available for quite a long
> >while now, I also do not believe that there can be any
> >new intellectual property assigned to Cisco for this approach.
> >But, I am not a lawyer, am not authoritative on patent law,
> >and I do not wish to be held liable for my legally-untrained
> >opinions.
>
> Standard Disclaimer: I am not a lawyer, so my opinions are
> legally-untrained.
>
> Dave Johnson's  LA presentation is the same as the local anchoring.
> Will work with Dave on that. So, most of the IPR claim may be moot.
>
> Moreover the licencing, if there is any, is apprently provided free of
> cost.
>
> thanks
> Gopal
>
>
> >
> >Regards,
> >Charlie P.
> >
> >
> >Jochen Grimminger wrote:
> >>
> >>
> >>
> >> Hallo Dave, hello everybody on the MIP mailing list
> >>
> >> in Adelaide Gopal Dommety made his presentation (draft) in MIP about
> "Fast
> >> Handover" described in the draft
> >> "draft-dommety-mobileip-anchor-handoff-00.txt" ... the topic was quite
> >> interesting ... and Dave Johnson made quite clear that in LA he has
> presented
> >> something similar (draft-whatwasitsname). I was searching for your
> >> presentation and the according draft, but all i found on your homepage
> was
> >> ....
> >>
> >>
> >>    * The 35th Internet Engineering Task Force meeting, Los Angeles, CA,
> March
> >>      4-8, 1996:
> >>
> >>           "Design Questions in Route Optimization", Mobile IP Working
> Group
> >> Meeting, March 7, 1996.
> >>           "Location Areas in Mobile IP", Mobile IP Working Group
> meeting,
> >> David B. Johnson, March 7, 1996
> >>
> >>
> >> I'm working in the MIP / MIP IPv6/MicroMobility enviroment. Could you
> or
> >> somebody on the list please send the documents directly to me or just
> make
> >> them available on any public homepage or via the MIP mailinglist.
> >>
> >> Best regards and many thanks in advance
> >>
> >> Jochen Grimminger
> >>
> >> PS: I'm pretty sure i'm not the only one who was interested ;-) with
> respect
> >> to the fast handover discussions
> >> on the list. By the way what about the state of all the micro mobility
> >drafts,
> >> most of them are and cellularIP is about to expire .
> >>
> >>
> >
>
> --------------------------------------------------------------------------
> -----------------------------------
> Gopal Dommety    408 525 1404   [email-masked]
> Cisco Systems, San Jose, CA, 95051
>
> It is preoccupation with possessions, more than anything else, that
> prevents us from living freely and nobly. -Bertrand Russell

---

From: Steven Glass - Solaris Software <[email-masked]>
Date: Wed, 10 May 2000 17:45:02 -0400

> extension.

    So it looks like this:

     <----- direction of packet -----
    {Registration Request, MN-HA auth, EDS extentino, MN-FA auth}

> Additionally, the FA must consume the extension.  The problem
> authentication value can only be verified by the HA/AAA, not the FA.

    Not true.  The last two items above are consumed after the FA verifies the
MN-FA auth.

> allow the MN to receive multi-/broadcast packets from it's home network?

    There is no change here as this is NOT a reverse tunneling issue.  These
packets are multiply encapsulated by the HA so the FA knows where they are
going.  That is, the packet looks like:

     <------direction of travel----
    { (FAdst, HAsrc), (MNdst, HAsrc), (MCASTdst, CNsrc), data }

    The HA adds the two "forward-most" IP headers.

    In the inverse, when the MN wants to send a multi/broadcast message to
it's home subnet, it MUST use reverse tunneling, and it MUST encapsulate the
packet itself (the FA just reverse tunnels it as usual).  If not, it would be
sending to the multi/broadcast ip address, and the FA's HW address.  The
packet then looks like:

     <------direction of travel----
    { (FAdst, MNsrc), (MCASTdst, MNsrc), data }

    The FA consumes the first IP header, and puts the reverse tunnel header on
the packet.  When the HA gets it, it strips off the outer header, then just
delivers the packet to the MN's link as usual.

    Hope this clears things up!

                              Cheers,
                                  Steve