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

From: Pekka Nikander <[email-masked]>
Date: Tue, 9 Oct 2007 09:58:51 +0300

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 [email-masked] 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

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 09 Oct 2007 16:36:19 +0800

*> 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 [email-masked] 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

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 9 Oct 2007 13:25:53 +0300

>>> 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).
>>
>> 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()."

I think you have to think more carefully about the context of that  
statement; the draft states only what is most obvious.  For example,  
if you use a local policy to *statically* map some IP addresses to  
host identities, then the system will work even for UDP applications  
in mobility scenarios.  But you cannot do that in the general case,  
since in the general case you have no pre-existing knowledge if the  
host *currently* at an IP address is able to speak HIP or not.

Hence, the statement in the draft refers only to the case where you  
basically want to preserve existing Internet semantics, i.e., an IP  
address points to the host *currently* reachable at the location.   
Then, if the host moves, those UDP applications that cache the  
address break today.  In this scenario, HIP doesn't change anything  
since we don't want to change the semantics.

If you willing to work with different semantics where the meaning of  
an IP address is changed somewhat, you can "fix" the situation and  
make also UDP applications to work, even when they do cache IP  
addresses.  That won't be simple and it will configuration would be  
ugly -- therefore we don't recommend it.  It would be better to use  
LSIs (which would have different semantics anyway) or, preferably, HITs.

> 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.

Using LSIs instead of IP addresses in the IPv4 API should work,  
without modifications to the apps.  But then you need to provide the  
system with the mapping LSI->HI->IP address, which may not be trivial  
if you are not using the DNS or something similar.

What the draft doesn't state (since that would modify current  
semantics) is that you can basically use any IPv4 address as an LSI  
if, and importantly only if, you know for sure that you want that  
address to refer to a specific, HIP-enabled mobile host.  If you  
don't know that, you are looking for trouble through changing  
semantics in a way that may have unwanted side effects.

> 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.

There I agree.  With HIP, the semantics of using HITs through the  
IPv6 API are much cleaner than using LSIs or IP addresses through the  
IPv4 API.

--Pekka

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 09 Oct 2007 18:12:42 +0200

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Pekka Nikander
> 发送时间: 2007年10月9日 8:59
> 收件人: Sheng Jiang
> 抄送: 'Noel Chiappa'; [email-masked]
> 主题: Re: [RRG] loc/id split and HIP (was LISP)
> 
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.

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 9 Oct 2007 20:09:45 +0300

>> 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.
>
> self-generated HIT which is flat, in this way, we can deploy  
> hierarchical DHT to improve the scalability of the mapping service  
> system further.

Such a practise was there in the early drafts; see e.g. [1].  That  
was removed later since a) nobody implemented it and b) the people  
working on HIP at that time didn't see any reason for retaining it.

 From today's point of view, I think CGAs or some variant thereof,  
such as the one suggested by Christian Vogt [2] could serve such a  
purpose.  Architecturally, CGAs could well be used with HIP; however,  
the channel bindings property of HITs would be weakened quite a lot.

--Pekka Nikander

[1] http://www.watersprings.org/pub/id/draft-moskowitz-hip-arch-02.txt
[2] http://www.ietf.org/internet-drafts/draft-vogt-rrg-six- 
one-00.txt, Section 3.4

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 10 Oct 2007 11:41:31 +0800

*>>> 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()."
*
*I think you have to think more carefully about the context of that
*statement; the draft states only what is most obvious.  For example,
*if you use a local policy to *statically* map some IP addresses to
*host identities, then the system will work even for UDP applications
*in mobility scenarios.  But you cannot do that in the general case,
*since in the general case you have no pre-existing knowledge if the
*host *currently* at an IP address is able to speak HIP or not.
*
*Hence, the statement in the draft refers only to the case where you
*basically want to preserve existing Internet semantics, i.e., an IP
*address points to the host *currently* reachable at the location.
*Then, if the host moves, those UDP applications that cache the
*address break today.  In this scenario, HIP doesn't change anything
*since we don't want to change the semantics.
*
*If you willing to work with different semantics where the meaning of
*an IP address is changed somewhat, you can "fix" the situation and
*make also UDP applications to work, even when they do cache IP
*addresses.  That won't be simple and it will configuration would be
*ugly -- therefore we don't recommend it.  It would be better to use
*LSIs (which would have different semantics anyway) or, preferably, HITs.

Pekka, I think you mis-understood what I meant originally. When I said "ALL
applications to be modified in order to support HIT", I referred to those
applications that use IP as identifier within their implementations. For
those IP-independent applications, changing host stacks and mapping system
could be sufficient. However, before IPv6 motivated applications to be
IP-independent. More than 90 percent applications did use IP as identifier.

*> 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.
*
*Using LSIs instead of IP addresses in the IPv4 API should work,
*without modifications to the apps.  But then you need to provide the
*system with the mapping LSI->HI->IP address, which may not be trivial
*if you are not using the DNS or something similar.
*
*What the draft doesn't state (since that would modify current
*semantics) is that you can basically use any IPv4 address as an LSI
*if, and importantly only if, you know for sure that you want that
*address to refer to a specific, HIP-enabled mobile host.  If you
*don't know that, you are looking for trouble through changing
*semantics in a way that may have unwanted side effects.
*
*> 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.
*
*There I agree.  With HIP, the semantics of using HITs through the
*IPv6 API are much cleaner than using LSIs or IP addresses through the
*IPv4 API.
*
*--Pekka
*
*
*--
*to unsubscribe send a message to [email-masked] 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

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 10 Oct 2007 06:52:12 +0300

>> Hence, the [limitations w.r.t mobility] in the draft refers only  
>> to the case where you basically want to preserve existing Internet  
>> semantics, i.e., an IP address points to the host *currently*  
>> reachable at the location.  Then, if the host moves, those UDP  
>> applications that cache the address break today.  In this  
>> scenario, HIP doesn't change anything since we don't want to  
>> change the semantics.
>>
>> If you willing to work with different semantics where the meaning  
>> of an IP address is changed somewhat, you can "fix" the situation  
>> and make also UDP applications to work, even when they do cache IP  
>> addresses.  That won't be simple and it will configuration would  
>> be ugly -- therefore we don't recommend it.  It would be better to  
>> use LSIs (which would have different semantics anyway) or,  
>> preferably, HITs.
>
> Pekka, I think you mis-understood what I meant originally. When I  
> said "ALL applications to be modified in order to support HIT", I  
> referred to those applications that use IP as identifier within  
> their implementations.

I don't think I misunderstood you.  When I wrote about legacy  
applications, I really meant legacy applications that use IPv4  
addresses directly in their data structures and configuration files.

I really mean that you *can* make HIP to work with such legacy  
applications, but you pay for it.  In practise you have to have some  
"local" configuration (not necessarily host-local, though) that  
statically binds such statically used legacy IPv4 addresses into  
HITs.  That changes the semantics that people generally expect about  
IPv4 addresses today; OTOH, such changed semantics would be closer to  
what people expected from IPv4 addresses before NATs, DHCP, and  
mobility.

--Pekka Nikander

PS.  All that I'm trying to do here is to correct some common  
misconceptions about HIP.  You are not alone thinking that HIP  
doesn't work with legacy IPv4 applications, while it does.

As I have written a few times, I don't think that HIP, as it is  
today, would be able to solve the routing table scalability problem.   
See my previous messages for what would be needed in order to HIP  
help there.

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 10 Oct 2007 14:28:02 +0800

Pekka,

I don't misunderstand the HIP concept. Let's end our argument here. I know
HIP can work with legacy IP applications. You made it clear enough in your
hip-application draft, in section 3.

Back to my original points, I did not attack HIP as a solution. What I was
saying was there are deployment costs to pay, either by applications or by
mapping systems.

Regards,

Dr. Sheng JIANG

IP Research Department, Networking Research Department, Network Product
Line, Huawei Technologies Co. Ltd.

*-----Original Message-----
*From: [email-masked] [mailto:[email-masked]] On Behalf Of Pekka
Nikander
*Sent: Wednesday, October 10, 2007 11:52 AM
*To: Sheng Jiang
*Cc: Routing Research Group list
*Subject: Re: [RRG] loc/id split and HIP (was LISP)
*
*>> Hence, the [limitations w.r.t mobility] in the draft refers only
*>> to the case where you basically want to preserve existing Internet
*>> semantics, i.e., an IP address points to the host *currently*
*>> reachable at the location.  Then, if the host moves, those UDP
*>> applications that cache the address break today.  In this
*>> scenario, HIP doesn't change anything since we don't want to
*>> change the semantics.
*>>
*>> If you willing to work with different semantics where the meaning
*>> of an IP address is changed somewhat, you can "fix" the situation
*>> and make also UDP applications to work, even when they do cache IP
*>> addresses.  That won't be simple and it will configuration would
*>> be ugly -- therefore we don't recommend it.  It would be better to
*>> use LSIs (which would have different semantics anyway) or,
*>> preferably, HITs.
*>
*> Pekka, I think you mis-understood what I meant originally. When I
*> said "ALL applications to be modified in order to support HIT", I
*> referred to those applications that use IP as identifier within
*> their implementations.
*
*I don't think I misunderstood you.  When I wrote about legacy
*applications, I really meant legacy applications that use IPv4
*addresses directly in their data structures and configuration files.
*
*I really mean that you *can* make HIP to work with such legacy
*applications, but you pay for it.  In practise you have to have some
*"local" configuration (not necessarily host-local, though) that
*statically binds such statically used legacy IPv4 addresses into
*HITs.  That changes the semantics that people generally expect about
*IPv4 addresses today; OTOH, such changed semantics would be closer to
*what people expected from IPv4 addresses before NATs, DHCP, and
*mobility.
*
*--Pekka Nikander
*
*PS.  All that I'm trying to do here is to correct some common
*misconceptions about HIP.  You are not alone thinking that HIP
*doesn't work with legacy IPv4 applications, while it does.
*
*As I have written a few times, I don't think that HIP, as it is
*today, would be able to solve the routing table scalability problem.
*See my previous messages for what would be needed in order to HIP
*help there.
*
*
*--
*to unsubscribe send a message to [email-masked] 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