[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
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