[anonsec] btns-ipsec-apireq.txt

[Nicolas Williams]

On Tue, Apr 25, 2006 at 11:30:07AM +0300, Shinta Sugimoto wrote:
> On Sat, 22 Apr 2006 19:08:13 -0400
> Michael Richardson <mcr at sandelman.ottawa.on.ca> wrote:
> > or is it
> > better that it indicate what is reality at that moment, so that if the
> > purpose of the query was to start a second connection (i.e. FTP...) that
> > it can start with a better hint.
> 
> Apart from the above (that the locator change should not affect
> getsockname()/getpeername()), telling the 'reality' of the locator
> selection to the ULP might be helpful.  Not sure how much is it helpful
> though.  Such extension would allow application to get information
> about the locator which is bound to given socket.  Similary, we may
> extend sendmsg()/recvmsg() to deliver locator information to the
> application storing them in acillary data, for instance.  But again,
> I don't see clear need (good usecase) for that.  Do you see any ?

Ah, er, I see Michael's point.  What if the app wants to initiate a
connection to a peer for which it already has a connection.  Are there
such applications today?  (Yes!  NFSv4.)  How can such applications
continue to work then in this environment?  Ah, but there's no guarantee
that they'd work even if getsockname()/getpeername() returned the peer's
current locator because the peer and the application might be racing
around the next change.

Nico
--