Re: [rrg] Map and Encaps

Thanks for your detailed responses Pekka. You answered all my questions.

Dino

On Dec 28, 2008, at 12:01 PM, Pekka Nikander wrote:

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