Re: [rrg] Map and Encaps

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

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

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

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.

>> 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.
>
> 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.
>
> So a mapping database would have to hold entries for all globally  
> reachable hosts?

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.

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

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

>> At the other end, the processing continues:
>>
>> 4. The packet is decapsulated and the right Host Identities are  
>> determined.
>
> 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"
>
> The encapsulation format in LISP is one of many values LISP brings,  
> but there are more important ones.

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.

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

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

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:

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

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

_______________________________________________
rrg mailing list
rrg@irtf.org
https://www.irtf.org/mailman/listinfo/rrg