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

From: [email-masked] (Noel Chiappa)
Date: Mon, 24 Nov 2008 16:46:07 -0500 (EST)

> From: Brian E Carpenter <[email-masked]>

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Nov 2008 10:56:56 +1300

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

   Brian

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 25 Nov 2008 07:32:58 +0200

> 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

---

From: Steven Blake <[email-masked]>
Date: Tue, 25 Nov 2008 01:10:10 -0500

On Tue, 2008-11-25 at 07:32 +0200, Pekka Nikander wrote:

[Good stuff about HIP snipped]

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

Do you mean RRG?  I don't think there is any consensus to go towards
NAT66.

People in RRG Friday afternoon missed the NAT66 discussion in Behave.
To make a long story short: IPv6 NAT is happening in the market.  The
only questions for the IETF (IMHO) is whether or not to write a
specification for a more benign version (see draft-mrw-behave-nat66-01),
and whether or not to progress work to mitigate the damage.  

Regards,

// Steve