HIP section for shim6-applicability draft

["Henderson, Thomas R" <thomas.r.henderson@boeing.com>]

Below is a proposed section for the shim6-applicability draft.  I've
been through one round of comments with Marcelo and now am posting to
the list for any further comments.

Tom

5.5  shim6 and HIP

shim6 and the Host Identity Protocol (HIP) [RFC4423] are architecturally
similar in that both solutions allow a host, communicating with another
like-enabled host, to use possibly multiple or different locators to
support communications between stable ULIDs.  The signalling exchange to
establish demultiplexing context on both hosts is very similar between
the two protocols.  However, there are a few key differences.  First,
shim6 avoids defining a new namespace for ULIDs, preferring instead to
use a routable locator as a ULID, while HIP uses public keys and hashes
thereof as ULIDs.  The use of a routable locator as ULID better supports
deferred context establishment, application callbacks, and application
referrals, and avoids management and resolution costs of a new
namespace, but requires additional security mechanisms to securely bind
the ULID with the locators.  In HIP, the use of a public key or hash as
a ULID allows the context establishment protocol to use the key to sign
messages that bind the key to the locators.  Second, shim6 uses an
explicit context header on data packets for which the ULIDs differ from
the locators in use (this header is only needed after a failure/rehoming
event occurs), while HIP compresses this context tag into the ESP SPI
field of a BEET-mode security association [BEET].  Third, HIP as
presently defined requires the use of public-key operations in its
signalling exchange and ESP encryption in the data plane, while the use
of shim6 requires neither (if only HBA addresses are used).  HIP by
default provides data protection, while this is non-goal for shim6.

The shim6 working group was chartered to provide a solution to a
specific problem while minimizing deployment disruption, while HIP is
considered more of an experimental approach intended to solve several
more general problems (mobility, multihoming, loss of end-to-end
addressing transparency) through an explicit identifier/locator split.
Communicating hosts that are willing and interested to run HIP (perhaps
extended with shim6's failure detection protocol) likely have no reason
to also run shim6.  In this sense, HIP may be viewed as a possible
long-term evolution or extension of the shim6 architecture, or one
possible implementation of the extended shim6 design [ESD].