[rrg] Map and Encaps

[Dino Farinacci]

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

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

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

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

More interested in the details then the fore-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.

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

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

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?

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

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

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.

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

Thanks for taking the time to explain.

Dino

>
>
> --Pekka
>
> On 19 Dec 2008, at 19:41, Dino Farinacci wrote:
>
>> Can HIP proxies support an IPv4 site?
>>
>> Dino
>>
>> On Dec 19, 2008, at 12:57 AM, Pekka Nikander wrote:
>>
>>> 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/
>>>
>>> On 16 Dec 2008, at 21:00, Noel Chiappa wrote:
>>>
>>>> <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" <eric.fleischman at boeing.com>
>>>>> 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
>>>> rrg at irtf.org
>>>> https://www.irtf.org/mailman/listinfo/rrg
>>>>
>>>
>>> _______________________________________________
>>> rrg mailing list
>>> rrg at irtf.org
>>> https://www.irtf.org/mailman/listinfo/rrg
>>
>>
>