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

[Xu Xiaohu <xuxh@huawei.com>]

> -----邮件原件-----
> 发件人: owner-rrg@psg.com [mailto:owner-rrg@psg.com] 代表 Pekka Nikander
> 发送时间: 2007年10月9日 8:59
> 收件人: Sheng Jiang
> 抄送: 'Noel Chiappa'; rrg@psg.com
> 主题: Re: [RRG] loc/id split and HIP (was LISP)
> 
> On 9 Oct 2007, at 04:22, Sheng Jiang wrote:
> > 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.
> 
> 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?
Site address and transit address split solution uses IP prefix->IP mapping
service, while HIP uses HIT->IP mapping service. There is some difference in
the database size. It should be a challenge to use a global HIT->IP mapping
service such as DHT, from the aspect of lookup efficiency, as HIT has no
semantic significance currently and it's a flat label. 

How about split host identifier into two parts, the first part is
organization ID and which is hierarchical, and the second part is
self-generated HIT which is flat, in this way, we can deploy hierarchical
DHT to improve the scalability of the mapping service system further. 

> 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