RE: [RRG] loc/id split and HIP (was LISP)

[Sheng Jiang <shengjiang@huawei.com>]

*> For example, HIP, it requests ALL end devices change their stacks, ALL
*> applications to be modified in order to support HIT, and to deploy
*> a global
*> mapping real-time system in order to translate the identifier (HIT)
*> into
*> locator (IP).
*
*Well, that is not quite true.  While that all may be *eventually*
*required to reap all the potential benefits of HIP, in the short term
*much less is needed.  For example, in order to deploy HIP in a small
*scale, all that is needed is to *some* end devices to change their
*stacks.  There is no need to modify applications [1].  For stationary
*hosts, the mapping of HIT to locators can be stationary, requiring no
*new infrastructure.  Additionally, the HIP-enabled hosts can continue
*to communicate with non-HIP-enabled hosts as if HIP wasn't there at all.

You are partly right here. Yes, for stationary host, no modification is
needed. But for me, the most important benefit of HIP is the support for
mobility and multihoming. As [1] mentioned, "mobility will break in the
connectionless case when an application caches the IP address and repeatedly
calls sendto()." When I investigated applications porting to IPv6-enabled,
most of applications were IP-dependent. Therefore, most of them are needed
modified to be HIP-enabled too. However, HIP deployment may benefit from
current IPv6 deployment. If an application has been ported to be IP
independent, change the host stack might be enough.

Sheng

*Using HIP for a purpose similar to LISP would be a slightly different
*story.  Then all hosts would need to support HIP, either natively or
*through proxying [2].  However, still no modifications would be
*needed to applications.  A global mapping would be needed, but I fail
*to see how its cost would be considerably higher than a corresponding
*mapping for LISP.  Maybe someone can help me to understand how the
*investment or operational costs of a distributed, global HIT->IP
*address mapping service would be any larger than for a IP->IP mapping
*service?
*
*Incidentally, I happened to write yesterday some raw text about what
*would be needed in order to make HIP a better solution to help with
*routing scalability.  I'm copying that below, in its raw form.  Take
*it with a grain of salt.
*
*--Pekka
*
*[1] http://www.ietf.org/internet-drafts/draft-ietf-hip-
*applications-01.txt
*[2] http://tools.ietf.org/html/draft-nikander-ram-generix-proxying-00
*
*As briefly mentioned in the end of Section XXX, the separation of
*identifiers and locators allows HIP to provide for locator agility.
*When HIP is used, the actual underlying IP addresses do not matter
*any more.  Only the most central infrastructure services, such as DNS
*and Rendezvous servers, need to be reachable on well known
*addresses.  However, it is conceivable that one could use pre-defined
*anycast addresses for such services, allowing the hosts to
*autoconfigure themselves more easily.  In that way, the system
*bootstrapping information would be confined within the routing system
*and not exposed in the locator system at all. Such a practise would
*eventually lift pressure to hoard IP addresses or to stick to
*certain, pre-defined IP addresses, thereby allowing the routing
*system to assign the addresses in a topologically optimal way and to
*renumber whole networks rapidly as the topology changes.
*
*Even if we don't go that far as deprecating static IP addresses
*altogether, with the exception of a few well known anycast-based
*services, the routing system could benefit from wide spread use of
*HIP. As discussed above, the HIP mobility and multi-homing extension
*allows active hosts to signal changes in addressing without
*disrupting existing connections. Hence, in a situation where a
*network needs to be renumbered,  if the network provides the nodes
*with new addresses slightly before the existing ones are deprecated,
*HIP would allow renumbering to take place in minutes rather than days
*or months, as it requires today. The only services that need to
*remain accessible longer at their existing addresses are the DNS and
*the Rendezvous.
*
* From the routing system point of view, a big remaining problem is
*that HIP is unlikely to be deployed any time soon. One potential way
*to address this problem would be to add HIP proxies at strategic
*places in the system. Such proxies would allow large numbers of non-
*HIP-enabled hosts to appear as HIP-enabled to the rest of the
*network. Compared to some other approaches currently discussed at the
*IETF, a HIP-based approach appears better in the sense that there are
*also other incentives to implement HIP but to lift pressure from the
*routing system. Hence, it is easy to imagine that at least some end-
*nodes and a largish number of end-sites might be willing to invest in
*HIP proxies, while in the case of solely-routing based approaches the
*main pressure would need to be carried by the large ISPs, i.e., those
*that directly suffer the pain.
*
*While it is relatively easy to see how HIP with its identifier /
*locator split and the mobility and multi-homing protocol could form a
*baseline for allowing the routing system to better manage IP
*addresses, as outlined above, the details of large-scale HIP proxying
*remains to be engineered. According to the present discussions, the
*following sore points would need to be addresses:
*
*o In very large proxies the public key operations, as currently
*employed by HIP, may become a computational bottleneck. One potential
*approach would be to use the so called Light Weight variant of HIP
*(LHIP), defined by Tobias Heer [XXX], as the default protocol between
*HIP proxies. The main difference between LHIP and vanilla HIP is that
*in LHIP the public key operations are replaced with hash chains.  As
*a result, the protocol is computationally much lighter, but it does
*not allow the Host Identities to be authenticated. However, as a
*fallback, LHIP allows an existing association to be upgraded to use
*full HIP, for example, in the case more than one host claims
*ownership to a single Host Identity.
*
*o The only currently defined HIP data carrier protocol, ESP, appears
*excessive and unnecessary. However, as HIP allows new data carrier
*protocols to be defined, it would be relatively simple to support
*lighter alternatives, such as plain IP-in-IP wrapping [XXX] or the so
*called shim headers from the IPv6 multi-homing protocol SHIM6 [XXX].
*
*o It is unrealistic to imagine that all sites would update their
*configuration files any soon, even if they would be placed behind HIP
*proxies.  Consequently, even when most of the sites would have
*minimally upgraded to HIP by placing information about Host
*Identities and Rendezvous Servers into the DNS, some amount of
*vanilla IPv4 and IPv6 traffic would still reach the HIP proxies from
*the legacy side. Hence, there is a need to handle this remaining
*traffic even when the core network has been completely converted to
*HIP use and therefore unable to pass vanilla IP datagrams destined to
*legacy services.
*o At the baseline, a HIP proxies-based solution requires both that
*all hosts either upgrade to HIP or are placed behind HIP proxies and
*that the DNS and other configuration data is upgraded to include Host
*Identifiers and Rendezvous Servers. This is a clear drawback to some
*other proposals discussed in the IETF, which aim towards "jacking up"
*the IP stack by allowing hosts to continue to use their existing
*configuration while the core network uses new, differently allocated
*addresses. One potential way forward might be to allow existing IPv4
*and IPv6 addresses to be used as host identifiers for remote hosts,
*such as servers. Hence, by simply installing a HIP proxy in the front
*of a legacy network, all the outgoing packets would be interpreted as
*containing "legacy-look-alike" host identifiers in their destination
*address.  These look-alike identities would then be used in the LHIP
*protocol between the proxies. Unfortunately, there appears a number
*of thorny security problems related to such a practise; the exact
*details of the problems and their potential solutions fall beyond the
*scope of this paper.
*
*Hence, we can say that number of problems and starting points exist.
*
*
*--
*to unsubscribe send a message to rrg-request@psg.com with the
*word 'unsubscribe' in a single line as the message text body.
*archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg