RE: shim - transport/app communication

["Bound, Jim" <jim.bound@hp.com>]

this is exactly what we need to be drilling down on and I am still
concerned about net centric communications.

thx
/jim 

> -----Original Message-----
> From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On 
> Behalf Of Jeroen Massar
> Sent: Wednesday, March 16, 2005 8:42 AM
> To: Pasi Sarolahti
> Cc: shim6@psg.com
> Subject: RE: shim - transport/app communication
> 
> [I trimmed the cc list btw]
> 
> On Wed, 2005-03-16 at 13:44 +0200, Pasi Sarolahti wrote:
> <SNIP>
> >>  But the minimal requirement we could
> >> set is "use a getaddrinfo() loop to cycle through all the 
> addresses",
> >> the ULID magic can be put in the getaddrinfo() function 
> which returns
> >> ULID's instead of the routing IP's.
> >
> >I was not so concerned about the techniques of conversions between
> >strings and address structures, but the semantic issues that 
> might arise
> >when the address the application sees might not anymore be 
> the same as
> >the address actually used in communication. I was wondering 
> what would
> >happen, for example, when these addresses are being advertised out in
> >the network as a part of some application protocol.
> 
> Applications will not know that the packets traveling on the Internet
> will actually have translated headers, just like they don't know that
> their packets go over Ethernet, over a PPPoE tunnel, ATM, IPv6 in IPv4
> in ATM or whatever magic there is. The ID's on both sides stay stable.
> 
> >Another example, I guess that bind() with IP address should 
> still select
> >the interface used for the socket, right? In principle, if assuming
> >ULIDs, the parameter address would represent the host, not the
> >interface. So some of the socket API functions would seem a bit
> >ambiguous to me.
> 
> ULID's could be given to a host based on a 'service' context just like
> you assign eg 2001:db8::80 to the webserver and 2001:db8::993 to the
> secure IMAP box. For the machine and for the applications it should be
> completely transparent and they should never notice at all 
> that there is
> anything happening to the packets as they are translated on 
> both sides.
> 
> 
> The biggest concerns I can currently come up with are:
>  - translation table size (128bits x 2 per entry, entry per site/host)
>    When talking to 100k hosts, is this feasible?
>  - how to fill the translation table and keep it up-to-date 
> in a secure
> manner.
> 
> Especially the second entry has to be worked out and is the boiling
> point. eg if you multihome a DNS server, it can't be used for 
> doing the
> resolving of the translation table (if we would go for DNS) and other
> nice problems, but these will be solved in time.
> The first entry is mostly a concern to small computers, eg 
> mobile phones
> but could be avoided by letting a gateway doing the 
> translation, eg per
> site. In a mobile phone context, this could mean that the IPv6 address
> is the phonenumber and the current ISP (connectivity supplier) you are
> connected to does the translation for you. Would need some 
> quick updates
> though, but should not hurt the apps nor the phone in anyway.
> 
> Greets,
>  Jeroen
> 
>