[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Attachment: signature.asc
Description: This is a digitally signed message part