Subject: Re: [rrg] Map and Encaps

From: [email-masked] (Noel Chiappa)
Date: Tue, 16 Dec 2008 14:00:34 -0500 (EST)

<I know this is rather a slow reply, but it has some points at the end which
I really thought deserved a substantial reply...>

    > From: "Fleischman, Eric" <[email-masked]>
    > Date: Mon, 1 Dec 2008 10:45:43 -0800

    > Map-and-encaps shields the host from knowing the actual network
    > topology such that an arbitrarily complex network topology can be
    > created that is transparent to the end user host

This is also true of the existing internetwork layer, though... It's an
interesting point as to whether this is a correct architectural choice, or
whether some applications want/need to be _able_ to see more (i.e. it would
not be mandatory, and those applications which didn't need it could/would
continue in blissful ignorance, just as most applictions now don't care about
virtual memory) - but that's not the main point I want to go over here, so
I'll pass on, and leave that for another day/thread.

    > I believe that map-and-encaps should solely be a network infrastructure
    > design alternative. To be effective, the hosts should not be aware that
    > map-and-encaps .. exists.
    > .. claims such as "LISP provides an identifier-locator split" is
    > fundamentally unrelated to the fact that HIP provides an
    > identifier-locator split. Quite obviously, HIP does so in a manner that
    > is real to the host (including applications) while LISP does so in a
    > manner that is known to routers only. [My own bias is that LISP's
    > claims in this regard are marketing while HIP's claims are close to
    > what the ROAD Group originally intended.]

You've made a number of points here, both explicitly and implicitly, that I
want to respond to.

Most importantly, I want to talk about your point that LISP is a router-only
solution, and its implication that LISP is therefore a limited solution. If
one is only talking about what's in LISP documents so far, that's accurate,
but my hopes for the long-term future of LISP - or rather, the path on which
LISP is but a first step - are much larger than that. (Based on discussions
I've had, those hopes are to some degree shared by some - perhaps many? - of
the people working on LISP - although each individual will no doubt have
varying degrees of agreement with my ideas, and I'll have let them speak for
themselves.) And I wouldn't have the slightest interest in working on LISP if
all it was, and would ever be, was a router-based M+E system using IPv4/v6.
Why?

I think the past decade or so (as far back as ROAD, in some sense) has taught
us that replacing the internetwork layer with something superior is not easy.
Whether or not one believes that IPv6 is viable on an architectural level (a
discussion I don't want to derail into), its deployment history has made us
all aware that 'forklift upgrades' don't work, and that viable deployment
strategies for anything new have to have economic benefit for early adopters.

In fact, I'd now say that when analyzed from a practical angle, what's _most_
important about any replacement piece of the internetwork architecture is not
how nice a design it is, but how good its deployment path is - including
especially the very earliest stages. I might have the world's best
clean-slate design, but if I don't have a deployment plan which is
economically feasible, it's just a very mildly interesting piece of paper.

It is from that mindset that I look at LISP. LISP as currently documented is
just, to me, a first step on a longer road - but one that passes that key
test of 'can it take off, to start with'? I liken the problem of deploying
entirely new replacement subsystems (such as a new internetwork layer) to
rolling a snowball down a hill - unless you can start with a big enough
initial snowball to start with, and find a hill of the right steepness (i.e.
the right path for it to travel, once it starts moving), your snowball isn't
going to go anywhere.

In fact, even though LISP was designed with a heavy focus on passing this
'initial deployment' bar, there are still concerns that it won't make it,
through lack of enough compelling features for people to change. In
particular: i) simpler multihoming is a good feature, but people may be happy
with the existing expensive/unscalable solutions; ii) freeing up address
space (since EIDs can be allocated more densely, and the amount of address
space needed for RLOCs is an order of magnitude or more less than that needed
for end hosts) is nice, but 'tragedy of the commons' means if a site already
has addresses, they don't care about the new guys ('I'm all right, Jack -
they can NAT').

Yes, as initially deployed, LISP is targeted at deployment in routers at the
edge of sites (precisely to minimize the impact on existing plant), and uses
existing protocols. But the concept is that, _if done right, with the right
hooks, and thinking forward about the future_, it can be the first step on a
path to something better. The exact path is way too complicated to put in
this margin, but here are some examples. 

- The initial spec provides for use of IPv4 between xTRs - but with a system
of xTRs deployed, it would be feasible to replace that inter-xTR protocol
with something better - a layer that e.g. recognized traffic aggregates as
first-class objects (so that traffic engineering would no longer have to rely
on routing hacks), or had built-in tools for aggregation of routing
information (think a hierarchy of nested areas), instead of having to have it
be hand-configured as now. I think we've seen that deploying new stuff like
this is virtually impossible _if the hosts have to understand it_ - so it
makes great sense to initially hide it behind a set of mapping boxes - but
how does one get the mapping boxes deployed to do it? Well, you have to offer
them some short-term benefit....

- The initial concept is that routers and hosts would not need to be
modified, to make deployment feasible. (See Figure 1.) However, once there is
some added value to what's on the other side of the xTR, it might make sense
to incrementally move that boundary closer and closer to the hosts, and
perhaps eventually expose the hosts to the new inter-xTR protocol directly.
I'm not sure the xTRs would ever go away completely; as long as we have
unmodified hosts - which is something we _have_ to support, and support well
- we'll need them. However, there is at least a feasible and viable migration
path which allows us to eventually see a new architecture deployed.

The key is to have this future path in mind while one is building the initial
snowball, as it were. For example, any identity->locator resolution system
needs to be able to handle mappings that map not just to IPv4/6 addresses,
but other syntaxes as well, so it would be possible (without a great
headache) deploy a new locator namespace in the future.

So far, there aren't many people, and not a lot of resources, so the future
can only get so much thought. Right now it has to all be focussed on getting
that initial snowball moving - because with that, detailed plans for the
future are a waste of energy...

In any event, as I recently pointed out to a bunch of LISP people, the lesson
of large projects is that one can't plan it all out beforehand (even if we
had the resources/personnel for such an effort, which we don't), and expect
it to work. One has to have, as Corbato said, an ability to change course
based on experience, without which a large project is a ship without a rudder
(which, IIRC, was his simile). So the basic concept is to get something
rolling down the hill, and then go around the design -> implement -> deploy
-> gather-real-experience loop as fast as possible, while proceeding down the
general path to a more capable system.

As far as HIP goes, I think it's a neat concept, includes good ideas, and I
hope it catches on. However, two things. First, the installed-base/evolution
issues are significant - while new applications can use it, HIP isn't a great
deal of help when dealing with legacy hosts/applications/etc. Second, HIP
does nothing to provide us with a superior internetwork layer (including a
new routing architecture).

Please, do not take this is a smack against HIP - as I said above, I think
it's good, and I hope it catches on. But it is primarily a shim layer between
the internetwork layer and transport/application modules - and it's the
internetwork layer which I am interested in.

While LISP clearly doesn't provide the same degree of separation of location
and identity as HIP, I think it's incorrect to say any claims it makes to
separation of location and identity are '[purely] marketing'. LISP EIDs may
initially have limited location scope, but they certainly don't have global
location scope - and the design is the way it is for seem like good reasons:
the ability to work with _unmodified_ hosts and routers - needed to make that
initial snowball feasible. We either have to give up making EIDs purely
identifiers (i.e. retain some location semantics, within a local scope), or
else we have to modify all the internal routers at a site - and the latter is
a non-starter for deployment.

LISP certainly does allow an organization to do a number of _practical_
things, like change its ISP without changing its host addresses - and not
just inside the site, but in external places as well, such as configuration
data on other sites (e.g. for access control).

If LISP wasn't intended to allow _some_ degree of separation of location and
identity, we wouldn't have put so much time into CONS, which does nothing
more than... provide a mapping from identity to location! (Although I do
concede that in a blank-slate architecture, this function might not be
needed, alas, we have to deal with the deployed base/architecture we have.)
The fact that it's not on the front burner has a lot more to do with 'focus
on getting that initial snowball together' than anything else.

LISP is certainly not the architecture I would come up with, given a clean
slate - but we obviously don't have the luxury of a clean slate.

	Noel
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 19 Dec 2008 10:57:56 +0200

Noel,

I fully agree with your argumentation about the importance of a  
deployment path.  I am painfully aware we did not see the issue when  
we were developing the original HIP in 1999-2006.

However, I disagree with your assessment of the present situation with  
HIP.  The HIP proxy approach [1] is structurally very similar to what  
you do with LISP.  From the practical point of view, you just install  
a magic box (the HIP proxy) between your legacy IP subnetwork and the  
rest of the network, and when there is the same box at the other end,  
the subnetwork becomes mobile, multi-homed, and reachable with IPv4,  
NATted IPv4, and IPv6.  (Of course, for reachability you need STUN  
servers and/or HIP rendezvous servers, depending on the exact flavour  
of HIP NAT traversal you use.)  When there is no such box in the other  
end, you continue just like today (or deploy some NAT-like solution  
towards the legacy sites).

Considering your list of LISP "features", I think HIP proxy does  
"better" than LISP does:

- The current HIP proxy specs and implementation provide the use of  
IPv4, IPv6, and even NATed IPv4 between the proxies (which are equal  
to the xTRs in LISP).

- With HIP proxies, the routers and hosts do not need to be modified  
at all, just like with LISP.  However, the boundary can be trivially  
moved closer to and eventually to the hosts.

So, in this light, I don't understand your statement that "HIP does  
nothing to provide us with a superior internetwork layer (including a  
new routing architecture)".  It is true that HIP was not designed with  
that in mind, but AFAICS, there is no real difference in this respect  
between the present LISP approach and the HIP proxy approach.  The big  
difference is that HIP is more "future friendly"; there is a clear and  
tested way how to make it to work in hosts.

IMHO, most probably the technically best solution might be achievable  
by combining the HIP proxy approach and the LISP approach, e.g. by  
taking the signalling, reachability, mobility and multi-homing  
functions from HIP and taking the mapping function and routing related  
aspects from LISP.

--Pekka

[1] Patrik Salmela and Jan Melen, "Host Identity Protocol Proxy", E- 
business and Telecommunication Networks Second International  
Conference, ICETE 2005, Reading, UK, October 3-7, 2005. Selected Papers.

http://www.springerlink.com/content/m72v767465578741/

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 19 Dec 2008 09:41:04 -0800

Can HIP proxies support an IPv4 site?

Dino

On Dec 19, 2008, at 12:57 AM, Pekka Nikander wrote:

> However, I disagree with your assessment of the present situation  
> with HIP.  The HIP proxy approach [1] is structurally very similar  
> to what you do with LISP.  From the practical point of view, you  
> just install a magic box (the HIP proxy) between your legacy IP  
> subnetwork and the rest of the network, and when there is the same  
> box at the other end, the subnetwork becomes mobile, multi-homed,  
> and reachable with IPv4, NATted IPv4, and IPv6.  (Of course, for  
> reachability you need STUN servers and/or HIP rendezvous servers,  
> depending on the exact flavour of HIP NAT traversal you use.)  When  
> there is no such box in the other end, you continue just like today  
> (or deploy some NAT-like solution towards the legacy sites).
>
> nothing to provide us with a superior internetwork layer (including  
> a new routing architecture)".  It is true that HIP was not designed  
> with that in mind, but AFAICS, there is no real difference in this  
> respect between the present LISP approach and the HIP proxy  
> approach.  The big difference is that HIP is more "future friendly";  
> there is a clear and tested way how to make it to work in hosts.
>
> IMHO, most probably the technically best solution might be  
> achievable by combining the HIP proxy approach and the LISP  
> approach, e.g. by taking the signalling, reachability, mobility and  
> multi-homing functions from HIP and taking the mapping function and  
> routing related aspects from LISP.
>
> --Pekka
>
>> rolling down the hill, and then go around the design -> implement - 
>> > deploy

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 20 Dec 2008 13:15:38 +0200

The current implementation supports both IPv4 and IPv6 legacy hosts.   
So, it does support an IPv4 legacy site, if that is what you ask.   
IIRC, currently you manually configure the mapping between Host  
Identities and the IPv4 addresses given to the legacy hosts.  But that  
could be automated.

The current implementation supports connecting to both IPv4 and IPv6  
hosts from legacy IPv4 and IPv6 hosts.  Just like host HIP, the proxy  
can do IPv4-IPv6 protocol translation in the fly if needed.  (Apps  
that carry IP addresses in the payload are likely to break, unless you  
do ALG, too.)

 From the RRG point of view, of course, there are a number of  
operational issues that we haven't thought, and that I think you LISP  
folks have thought a lot, like managing the mappings automatically and  
in a large scale.

(You can ignore the reset unless you are interested in the details.)

In more detail, from the functional point of view, the proxy does as  
follows:

1. The IP addresses in an incoming packet from a proxied legacy host  
are mapped to Host Identities.  (If the destination address cannot be  
mapped, the packet is not processed by the proxy and typically NATed  
out.  Furthermore, as this mapping is a one-to-one mapping  
(equivalence relation), and therefore the implementation does not have  
to do it in practise.

 From here on, from the functional point of view the processing  
doesn't differ from plain HIP:

2. The "tunnels" (encapsulation format + destination locator)  
associated with destination Host Identity are determined, and one of  
them is selected for the packet, according to a policy.  Right now HIP  
supports only ESP BEET mode tunnels, but adding other types of tunnels  
(like IPv4 encapsulation) is quite easy, mostly details.

3. The packet is encapsulated and sent out.

At the other end, the processing continues:

4. The packet is decapsulated and the right Host Identities are  
determined.

As this is the proxy, it performs another additional step:

5. The Host Identities are mapped to the legacy IP addresses (v4 or  
v6), the outgoing packet header is formed, and the packet is sent out.

This is quite flexible.  For example, I don't see any reason why the  
LISP IPv4-in-IPv4 encapsulation header format couldn't be used, if so  
desired.  The only data plane "difference" would be that the Source  
and Destination EID in the inner header would not be "actual EIDs",  
but handles to the HIP HIs, which in turn are cryptographic public  
keys (probably ephemeral and uncertified in this case).  However, the  
present HIP ESP encapsulation is actually quite more compact, since  
all the required encapsulation information is "condensed" into the  
SPI.  At the receiving end, the SPI points to a piece of state that  
allows the "inner header" to be reconstructed.

The real difference would be in the signalling and keeping track of  
the mappings between the proxies.  Unfortunately I don't know the  
details of LISP signalling, and therefore I cannot really comment the  
differences.

--Pekka

On 19 Dec 2008, at 19:41, Dino Farinacci wrote:

>> deployment path.  I am painfully aware we did not see the issue  
>> when we were developing the original HIP in 1999-2006.
>>
>> IPv4, IPv6, and even NATed IPv4 between the proxies (which are  
>> equal to the xTRs in LISP).
>>
>> - With HIP proxies, the routers and hosts do not need to be  
>> modified at all, just like with LISP.  However, the boundary can be  
>> trivially moved closer to and eventually to the hosts.
>>
>> approach.  The big difference is that HIP is more "future  
>> friendly"; there is a clear and tested way how to make it to work  
>> in hosts.
>>

---

From: Scott Brim <[email-masked]>
Date: Fri, 19 Dec 2008 15:40:02 -0500

(I'm rarely connecting to mail right now; please forgive if this
thread is old)

Excerpts from Noel Chiappa on Tue, Dec 16, 2008 02:00:34PM -0500:
> - The initial spec provides for use of IPv4 between xTRs - but with
> a system of xTRs deployed, it would be feasible to replace that
> inter-xTR protocol with something better - a layer that e.g.
> recognized traffic aggregates as first-class objects (so that
> traffic engineering would no longer have to rely on routing hacks),
> or had built-in tools for aggregation of routing information (think
> a hierarchy of nested areas), instead of having to have it be
> hand-configured as now. I think we've seen that deploying new stuff
> like this is virtually impossible _if the hosts have to understand
> it_ - so it makes great sense to initially hide it behind a set of
> mapping boxes - but how does one get the mapping boxes deployed to
> do it? Well, you have to offer them some short-term benefit....

afaict the only way to replace a protocol that is shared among all
DFZ-edge routers is either to (1) do yet another jack-up, or (2) do it
in a particular part of the Internet and interwork.  Does having a
map-and-encap mechanism in place help you in either of these cases?

The best thing, to me, about having something in the core that is a
routing solution but does not provide session identifiers is that
those two problems are decoupled, and you can evolve solutions to them
independently.  Identification and session control are endpoint
problems and should be dealt with by the endpoints.  

> modified, to make deployment feasible. (See Figure 1.) However, once
> there is some added value to what's on the other side of the xTR, it
> might make sense to incrementally move that boundary closer and
> closer to the hosts, and perhaps eventually expose the hosts to the
> new inter-xTR protocol directly.

Or let there be xTRs wherever it is convenient for any of the parties
along the path, and simultaneously -- independently -- deploy
something for e2e session control.

> While LISP clearly doesn't provide the same degree of separation of
> location and identity as HIP, I think it's incorrect to say any
> claims it makes to separation of location and identity are '[purely]
> marketing'. LISP EIDs may initially have limited location scope, but
> they certainly don't have global location scope - and the design is
> the way it is for seem like good reasons: the ability to work with
> _unmodified_ hosts and routers - needed to make that initial
> snowball feasible. We either have to give up making EIDs purely
> identifiers (i.e. retain some location semantics, within a local
> scope), or else we have to modify all the internal routers at a site
> - and the latter is a non-starter for deployment.
> 
> LISP certainly does allow an organization to do a number of
> _practical_ things, like change its ISP without changing its host
> addresses - and not just inside the site, but in external places as
> well, such as configuration data on other sites (e.g. for access
> control).

Right.  It provides site-level liberation from topological location.

Scott

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 26 Dec 2008 11:57:16 -0800

> The current implementation supports both IPv4 and IPv6 legacy  
> hosts.  So, it does support an IPv4 legacy site, if that is what you  
> ask.  IIRC, currently you manually configure the mapping between  
> Host Identities and the IPv4 addresses given to the legacy hosts.   
> But that could be automated.

And is it one-to-one? Or is the IPv4 address the HIP-proxy box at the  
edge of a site perhaps?

> hosts from legacy IPv4 and IPv6 hosts.  Just like host HIP, the  
> proxy can do IPv4-IPv6 protocol translation in the fly if needed.   
> (Apps that carry IP addresses in the payload are likely to break,  
> unless you do ALG, too.)

The translation is a big deal when it comes to details. How does an  
IPv6 HIT get translated into an IPv4 address, presumably used as a HIT  
on IPv4 system?

> operational issues that we haven't thought, and that I think you  
> LISP folks have thought a lot, like managing the mappings  
> automatically and in a large scale.

Meaning that HIP-proxy isn't ready to be deployed yet?

> (You can ignore the reset unless you are interested in the details.)

More interested in the details then the fore-details.  ;-)

> are mapped to Host Identities.  (If the destination address cannot  
> be mapped, the packet is not processed by the proxy and typically  
> NATed out.  Furthermore, as this mapping is a one-to-one mapping  
> (equivalence relation), and therefore the implementation does not  
> have to do it in practise.

So a mapping database would have to hold entries for all globally  
reachable hosts?

> them is selected for the packet, according to a policy.  Right now  
> HIP supports only ESP BEET mode tunnels, but adding other types of  
> tunnels (like IPv4 encapsulation) is quite easy, mostly details.
>

Do you know ahead of time the destination locator is reachable? That  
is, by another means than having the destination locator's route in  
the routing table?

> 4. The packet is decapsulated and the right Host Identities are  

If the mapping is 1-to-1, how does the HIP-proxy know to decapsulate?  
And how does it know a HIP encapsulated packet is transited through  
the box that shouldn't be decapsualted?

> LISP IPv4-in-IPv4 encapsulation header format couldn't be used, if  
> so desired.  The only data plane "difference"

The encapsulation format in LISP is one of many values LISP brings,  
but there are more important ones.

> would be that the Source and Destination EID in the inner header  
> would not be "actual EIDs", but handles to the HIP HIs, which in  
> turn are cryptographic public keys (probably ephemeral and

Well, we know today (haven't proved it yet) that two HIP hosts can  
talk to each other over an IPv4 Internet using LISP encapsulation. And  
since the packets to the LISP ITR look like regular IPv6 packets,  
those embedded addresses (the HITs) *are* EIDs from the LISP router  
point of view. So they would be used as keys for the mapping database  
lookup to get locators returned.

> uncertified in this case).  However, the present HIP ESP  
> encapsulation is actually quite more compact, since all the required  
> encapsulation information is "condensed" into the SPI.  At the  
> receiving end, the SPI points to a piece of state that allows the  
> "inner header" to be reconstructed.

Yes, but the Netflow advocates will want to see header data.

> details of LISP signalling, and therefore I cannot really comment  
> the differences.

Thanks for taking the time to explain.

Dino

>>> depending on the exact flavour of HIP NAT traversal you use.)   
>>> When there is no such box in the other end, you continue just like  
>>> today (or deploy some NAT-like solution towards the legacy sites).
>>>
>>> - The current HIP proxy specs and implementation provide the use  
>>> of IPv4, IPv6, and even NATed IPv4 between the proxies (which are  
>>> modified at all, just like with LISP.  However, the boundary can  
>>> be trivially moved closer to and eventually to the hosts.
>>>
>>> So, in this light, I don't understand your statement that "HIP  
>>> does nothing to provide us with a superior internetwork layer  
>>> (including a new routing architecture)".  It is true that HIP was  
>>> not designed with that in mind, but AFAICS, there is no real  
>>> difference in this respect between the present LISP approach and  
>>> the HIP proxy approach.  The big difference is that HIP is more  
>>> "future friendly"; there is a clear and tested way how to make it  
>>> to work in hosts.
>>>
>>> approach, e.g. by taking the signalling, reachability, mobility  
>>> and multi-homing functions from HIP and taking the mapping  
>>> function and routing related aspects from LISP.
>>>
>>> --Pekka
>>>
>>> [1] Patrik Salmela and Jan Melen, "Host Identity Protocol Proxy",  
>>> E-business and Telecommunication Networks Second International  
>>>> scope), or
>>>> _practical_

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 28 Dec 2008 22:01:34 +0200

[Those who do not care about details, may skip to the end where I  
generalise.]

>> hosts.  So, it does support an IPv4 legacy site, if that is what  
>> you ask.  IIRC, currently you manually configure the mapping  
>> between Host Identities and the IPv4 addresses given to the legacy  
>> hosts.  But that could be automated.
>
> And is it one-to-one? Or is the IPv4 address the HIP-proxy box at  
> the edge of a site perhaps?

In the implementation today, the mapping between the internal legacy  
IPv4 or IPv6 addresses (EIDs in LISPish) and the HIP Host Identies  
maintained at the proxy is one-to-one.  The external IPv4 or IPv6  
address of the HIP-proxy box is just liked the RLOC in LISP.  I can  
imagine a HIP-based box that has only one Host Identity (HI), or fewer  
HIs than there are internal legacy hosts, but I wouldn't call it a  
proxy but perhaps a "HIP tunnel box" or something else instead.  (It  
wouldn't be too different from an IPsec security GW, and therefore it  
wouldn't be very interesting to me.)

The idea of the proxy is that from the HIP point of view a proxy looks  
like a number of HIP hosts sitting at one shared IP address (or a few  
shared IP addresses if the proxy is multihomed).  Hence, from the HIP  
protocol point of view, it doesn't really matter if what looks like a  
proxy is really a proxy, a host having a number of Host Identities, or  
perhaps a host running a number of virtual machines each having a  
separate Host Identity.  (HIP allows multiple Host Identities to be  
assigned to a single host.)

>> The current implementation supports connecting to both IPv4 and  
>> IPv6 hosts from legacy IPv4 and IPv6 hosts.  Just like host HIP,  
>> the proxy can do IPv4-IPv6 protocol translation in the fly if  
>> needed.  (Apps that carry IP addresses in the payload are likely to  
>> break, unless you do ALG, too.)
>
> IPv6 HIT get translated into an IPv4 address, presumably used as a  
> HIT on IPv4 system?

The HIT is the internal representation (handle) for a Host Identity,  
used in the protocol itself.  When proxied, the internal legacy IP  
addresses (EIDs) used between the proxy and the legacy hosts do not  
need to be HITs -- they can be basically any IP addresses.  Such  
addresses, at least when used at the host-internal legacy socket API  
for HIP hosts, are called Local Scope Identifiers (LSIs) in the HIP  
architecture document.  For the proxy, the usage could probably be  
extended, so that LISPish EID would be LSI in HIPpish.  :-)

For IPv6, it might well make sense to use ORCHID-based HITs as LSIs,  
but obviously you cannot use that for IPv4.

When there is an incoming packet, either internally at a host through  
the legacy API, or through the internal interface at a proxy, the LSIs  
are mapped to the HIs, as I already explained.  At the same time, the  
TCP (and UDP) checksums are recomputed as if there was an IPv6 pseudo- 
header and the SRC and DST address fields contained the HITs.  See  
Section 4.5.1. of RFC 5201 for the exact details.

Hence, in the packets between any two HIP hosts, the checksums are  
always based on the HITs, using the IPv6 pseudo-header format.  Then,  
obviously, if something else is used between the HIP proxy and legacy  
hosts, the checksums must be recomputed.  This then leads to the  
situation where simple protocols, such as SSH, benefit from an  
implicit IPv4-IPv6 conversion in the case where one end uses IPv4 LSIs  
and the other end IPv6 LSIs.

But as you say, once you go to more complex protocols, such as tunnel- 
mode IPsec or protocols carrying IP addresses in the playloads, things  
get complicated and typically require that the same LSIs are used at  
both ends.

> Meaning that HIP-proxy isn't ready to be deployed yet?

The HIP proxy has never been meant to solve the RRG problem, at least  
not until now :-).   The proxy was developed to solve a completely  
different problem: to make it possible to provide simultaneous  
mobility and multi-homing to a number of co-operating legacy sites and  
hosts.

So, the HIP proxy is ready to be deployed if you have a single  
organisation that cares about its internal connectivity over the  
Internet and wants to make such communication more robust.

For multi-organisation situation, the protocols themselves work.   
However, AFAIK, nobody has cared to think about the operational  
aspects, such as how to maintain the mappings between the  
organisations etc.  Hence, if you mean that HIP-proxy is not ready to  
be deployed in such a situation, you are right.

>> In more detail, from the functional point of view, the proxy does  
>> as follows:
>>
>> 1. The IP addresses in an incoming packet from a proxied legacy  
>> host are mapped to Host Identities.  (If the destination address  
>> cannot be mapped, the packet is not processed by the proxy and  
>> typically NATed out.  Furthermore, as this mapping is a one-to-one  
>> mapping (equivalence relation), and therefore the implementation  
>> does not have to do it in practise.
>

As you can see from above, the focus has been on the single- 
organisation situation, where one can easily maintain the LSI->HI  
mappings for all reachable destinations.

OTOH, if you consider a situation where the destination LSI is a  
legacy IP address and there is no information about how to map it into  
a HI, I could imagine opportunistic HIP could be used; see Section  
4.1.6. of RFC 5201.  That could probably be combined with some  
additional mapping mechanism, such as any of those proposed for LISP.   
The result would still support HIP-based combined mobility and multi- 
homing, as the database would only be used for the initial HIP  
association setup.

>> associated with destination Host Identity are determined, and one  
>> of them is selected for the packet, according to a policy.  Right  
>> now HIP supports only ESP BEET mode tunnels, but adding other types  
>> of tunnels (like IPv4 encapsulation) is quite easy, mostly details.
>>

That is addressed in the HIP mobility and multihoming RFC.  See  
Section 5.4. of RFC 5206.  Furthermore, as the HIP control packet  
format is bit-by-bit compatible with the SHIM6 control packet format,  
the protocol defined in draft-ietf-shim6-failure-detection-09 can be  
trivially reused.  (AFAIK, some HIP implementations do so already now.)

> If the mapping is 1-to-1, how does the HIP-proxy know to  
> decapsulate? And how does it know a HIP encapsulated packet is  
> transited through the box that shouldn't be decapsualted?

I don't quite understand your questions, so forgive me if I don't  
address just what you ask for.

The HIP proxy knows that it needs to decapsulate since a) the packet  
has, as its destination address, one of the local addresses configured  
to the proxy box and b) the packet has the encapsulation format  
(currently ESP).  As the packet is destined to the proxy itself, the  
packet is handed up in the stack and not forwarded.  As a result, the  
packet goes to the protocol module that handles the decapsulation.   
So, there is no magic involved in that.

In the light of that, I don't understand your latter question at all.

------------------

>> This is quite flexible.  For example, I don't see any reason why  
>> the LISP IPv4-in-IPv4 encapsulation header format couldn't be used,  
>> if so desired.  The only data plane "difference"
>

I completely agree that LISP has lots of functions, and many functions  
that AFAICS could be reused for HIP-proxy based solution.  HIP also  
has lots of values that it brings.  Like baseline security, mobility  
at different levels of granularity from sites to individual flows, and  
multi-homing tightly integrated with mobility.

-------------------

> talk to each other over an IPv4 Internet using LISP encapsulation.  
> And since the packets to the LISP ITR look like regular IPv6  
> packets, those embedded addresses (the HITs) *are* EIDs from the  
> LISP router point of view. So they would be used as keys for the  
> mapping database lookup to get locators returned.

So, if I understand you Dino correctly, we seem to agree that from the  
functional point of view, a HIP proxy and LISP xTRs perform a pretty  
similar function.  That was the point I had, in reaction to what Noel  
wrote:

>>>>> (including a

In the light of the discussion above, I believe that it should now be  
clear that Noel was wrong in what comes to HIP being able to help  
legacy hosts or applications, and what comes to its *potential* in  
helping to build a superior internetworking layer.  Granted, HIP and  
not even the HIP proxy does not as such provide "a superior  
internetworking layer".  But it *could* help building one, if so  
desired.

At this point, my only addition would be to again refer to the expired  
"generix" draft, http://tools.ietf.org/html/draft-nikander-ram-generix-proxying-00 
, from two years ago.  I still maintain that there is no real  
difference, from the deployment point of view, between host-based and  
network-based solutions.  One can implement a host-based solution in  
the network, as the HIP proxy example shows.  Or one can "squeeze" a  
network-based solution into a host.

When solving the final target architecture, I think people should  
think about the eventual, potential features it could give.  And then  
work out the deployment path.

My understanding is that the LISP folks have done a great job in terms  
of thinking how it could be widely deployed already at step 1.   
Obviously, the HIP community has had a completely different focus,  
thinking in small and trying to figure out how to deploy HIP first  
within single organisations, and then gradually get benefits from  
other organisations perhaps also adopting HIP.

--Pekka

---

From: Dan Jen <[email-masked]>
Date: Mon, 29 Dec 2008 19:59:03 -0800

On Sun, 2008-12-28 at 22:01 +0200, Pekka Nikander wrote:
> One can implement a host-based solution in  

Just because parties *can* do something doesn't mean they will.  The
tricky part is not to come up with a proposal that solves the problem,
but to come up with a proposal that offers the right incentives to the
right parties.

> work out the deployment path.

Well, the proposal needs to solve the main objective, which is to shrink
the global routing table.  As long as proposals meet that requirement,
I'd take the deployable proposal over the feature-packed proposal that
has zero chance of getting used by anyone.  

Deployability issues have hung up a lot of proposals on the RRG, and if
it were easy to come up with a good deployment path for any proposal, I
think a lot of the proposal authors would have put up convincing
deployability stories by now, doncha think?

- Dan Jen