Subject: RE: APIs, locator-identifiers, DNS security, [and Cartesius] (was Re: A strawman analysis...)

From: "Bound, Jim" <[email-masked]>
Date: Wed, 17 Sep 2003 11:29:52 -0400

Hi Pekka,

> Well, I do not exactly /want/ to change the APIs or tranport 
> protocols. I only *anticipate* that due to mobility, 
> multi-address multi-homing, and intermittend connectivity, we 
> end up making changes to the transport protocols, anyway.  I 
> also anticipate that if we take the id/loc separation to its 
> logical end, we will create a new set of APIs that will 
> slowly replace the current socket APIs in new applications.

I don't believe we need new base APIs, but just extensions to the new
3493 APIs for getaddrinfo, getaddrinfo, and more importantly
asynchronous event notification.  Getaddrinfo and getnameinfo can have
flags to parse the future if we do figure out EID an Locator separation
and I will look at that as engineer/architect/implementer once I
personally believe a real proposal within the IETF and implementer
community for consensus exists, which is not the case today.  What we
will need for much of the paradigm and architecture discussions I am
hearing is a need to notify applications in an asynchronous manner of
changes (e.g. state of network, new addresses, new security parameters)
in the IP stack.  What will be required that is new, is an application
asynchronous listener mechanism added to applications (similar to how
POSIX Pthreads can be integrated into an application module) for the
asynchronous network kernel events for multiple paradigms and
architecture changes under discussion, in the case where the IP stack
selects variations for communications like new addresses or security
parameters.  I also am thinking this would be better done as an IEEE
exercise for these APIs rather than IETF too.  But, first order of
business is get consensus on the perceived paradigm and architecture
changes for any new features for IPv6 to be implemented.  API debates at
this point I think are premature, other than making sure new paradigms
or architecture does not break existing implementations in the market,
the latter being a better use of WG time is my 2 cents.

As a note I am reviewing Dave Crocker's MAST proposal and analysis in
technical depth, and will respond in the near future on MULTI6 list
(could be three weeks given my work load), and this statement is not a
support of MAST solution, but that I will do technical investigation as
one member in our IETF community.

Lastly, I believe we need to view the identifier and locator as unary
operation.  What I mean by that, is identification and location must be
in an IPv6 address (I don't care about IPv4 anymore for this
discussion).  This does not preclude rendezvous points or processes to
determine that address at all in solutions, as a note.

/jim

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------