[rrg] Fundamental objections to a host-based scalable routing solution

Pekka Nikander pekka.nikander at nomadiclab.com
Mon Nov 24 21:32:58 PST 2008


>>> the RRG doesn't get to decide about this. A host based solution  
>>> will or
>>> won't deploy, and will or won't succeed, ... regardless of both the
>>> routing community and the ISPs. So I don't think we need to  
>>> discuss it
>>> here at all.
>>
>> What about solutions which are (as I mentioned in the original note)
>> initially deployed in first-hop routers (for reasons of pragmatism)  
>> but which
>> are intended to, over time, migrate into the hosts (to give the  
>> hosts direct
>> access to the new underlying semantics)?
>
> Good point, although of course first-hop routers are rarely under  
> ISP control
> for medium/large companies, where I suspect our "market" mainly lies.

Shameless plug from the wayside:  I think HIP as a host solution and  
HIP proxy
as a first-hop router solution fulfils most of your requirements, is  
mostly
RFCs, is fully implemented (like a few other solutions being discussed  
here),
and, most importantly, has enough of features so that *some*  
organisations may
have enough of incentive to use it even without official IETF blessing.
(And then most people at the IETF complain it has way too many  
features....)

 From the RRG point of view, IMHO the interesting HIP features are full
address agility (even between IPv4 and IPv6), backwards compatibility  
with
legacy applications, and, as I said, that it may have a good set of  
features
built-in so that there may be deployment incentives.  Oh, and, BTW, the
small kernel changes that are needed for efficient operation (ESP BEET  
mode)
are already in recent versions of Linux and FreeBSD.  (The Windows and
Mac OS X versions don't depend on those, but are slightly less  
efficient.)

Now, clearly it does not help (from the RRG point of view) if the  
other end
doesn't use HIP at all, and AFAIK that cannot be easily fixed.  But  
there the
RG seems to be going some sort-of NATted (NAT66?) way anyway....

References: RFC4423, RFC5201, RFC5203, RFC5204, RFC5205, RFC5206,  
RFC5338,
draft-melen-hip-mr-01, www.springerlink.com/index/m72v767465578741.pdf

--Pekka Nikander



More information about the rrg mailing list