Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api

["Henderson, Thomas R" <[e-mail]>]

> -----Original Message-----
> From: Miika Komu [mailto:[e-mail]]
> Sent: Tuesday, October 12, 2010 10:00 PM
> To: Henderson, Thomas R
> Cc: Jari Arkko; shim6; [e-mail]
> Subject: Re: [shim6] AD review of draft-ietf-shim6-multihome-shim-api
>
> Hi,
>
> On 12/10/10 20:54, Henderson, Thomas R wrote:
>
> >> -----Original Message----- From: Miika Komu
> >> [mailto:[e-mail]] Sent: Friday, October 08, 2010 4:35 AM To:
> >> Jari Arkko Cc: Shinta Sugimoto; shim6;
> >> [e-mail]; Henderson, Thomas R Subject: Re:
> >> [shim6] AD review of draft-ietf-shim6-multihome-shim-api
> >>
> > <snip>
> >
> >>> However, IIRC in HIP you cannot propose a locator for the other
> >>> side, only for yourself. Or is your plan that you move the
> >> session to
> >>> another locator and that if that node happens to be the
> >> wrong one, then
> >>> it cannot decrypt the traffic anyway, so there's no damage?
> >>
> >> (There has to be a successful return routability check before any
> >> traffic is transported)
> >>
> >> There's two use cases:
> >>
> >> 1. No HIP session (i.e. SHIM context) yet and application knows the
> >> IP address of the peer. 2. An existing HIP session, connectivity
> >> lost but the application (with the assistance from the user) can
> >> help to rediscover the peer.
> >>
> >> Now remembering this "unknown" part again, I think the MAY was
> >> referring to the first case described above. It should be ok for
> >> the application give a hint especially in the absence of better
> >> knowledge from the SHIM.
> >
> > I agree; that was my understanding of the main intent of this clause
> > (to allow the application to provide the shim with a hint of the
> > binding to IP address).
> >
> > However, in reviewing section 6.2, it seems like this would fail
> > since there is no shim context for the socket.  If I'm not mistaken,
> > the draft seems to forbid applications running in opportunistic HIP
> > mode because this API requires that shim context be associated with
> > the socket for the ancillary data to be accepted.
>
> right:
>
> http://tools.ietf.org/html/draft-ietf-hip-native-api-12#section-4.6
>
> "Another use case is to use the opportunistic mode.."

Yes, but the HIP native API draft does not say anything about
overriding the rules in the shim6 API specification concerning
the need for shim context.  Maybe that should be clarified in
the HIP API draft.

- Tom