Subject: RE: Newbie Question about addressing impacts

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 12 Aug 2004 06:31:54 -0700

This is an interesting idea. However, if we embed proxy functions into border routers it would potentially add overhead (as well as latency) and make them harder to manage. Specifically, the number of border routers is likely to increase as network perimeters become more porous. Thus, this idea carries with it the need to ensure that these distributed routers can be configured with consistent policies.

Simple is good in operations.

-----Original Message-----
From: marcelo bagnulo braun [mailto:[email-masked]]
Sent: Thursday, August 12, 2004 1:59 AM
To: Iljitsch van Beijnum
Cc: Multi6; Fleischman, Eric
Subject: Re: Newbie Question about addressing impacts

El 11/08/2004, a las 19:36, Iljitsch van Beijnum escribió:

> Hi Eric,
>
> On 11-aug-04, at 18:13, Fleischman, Eric wrote:
>
>> Newbie question: Assuming a multihomed environment with N ISPs 
>> supporting a corporate network of 2K+ routers and 200K+ computers. Is 
>> multi6 proposing that the interfaces of the routers and computers 
>> each have N different global addresses, one set for each of the N 
>> ISPs?
>
> At this time, multi6 isn't exactly proposing anything. But yes, pretty 
> much everything that's under discussion right now assumes this.
>
>> If so, has multi6 considered the impact of this approach to IGP and 
>> EGP performance? If so, what was the consensus conclusion to that 
>> evaluation?
>
> There hasn't been an evaluation.
>
> There is a feature that I'm very much in favor of that could help 
> here: the ability to implement a multihoming solution in middleboxes 
> or border routers. In such a scenario, there would be a set of 
> addresses for internal use in the site, and the proxy multihoming 
> devices add the multihoming capability somewhere close to the border 
> of the network. The good thing here is that there is no need to modify 
> each individual host to obtain multihoming benefits, and it's easier 
> to implement policy in a few central places rather than distributed 
> over all the hosts in the network.
>

Well, even if you do a per host locator selection you can still manage 
policy in a centralized fashion, if we define proper mechanisms to 
perform policy distribution, for instance a dhcp option for 
distributing RFC3484 policy table or something similar. However, i 
don't know how you can enforce policy in a centralized manner when 
locator selection is performed by the end hosts.

anyway, i agree that proxys are attractive, especially for supporting 
advanced features like session survivability in legacy hosts

regards, marcelo

---

From: Tony Li <[email-masked]>
Date: Thu, 12 Aug 2004 10:46:14 -0700

On Aug 12, 2004, at 6:31 AM, Fleischman, Eric wrote:

> This is an interesting idea. However, if we embed proxy functions into 
> border routers it would potentially add overhead (as well as latency) 
> and make them harder to manage. Specifically, the number of border 
> routers is likely to increase as network perimeters become more 
> porous. Thus, this idea carries with it the need to ensure that these 
> distributed routers can be configured with consistent policies.
>

Well, then the other architectural alternative that I can see is to 
embed NAT-like functionality in all of the hosts.

I find this scarier.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Aug 2004 10:01:21 +0200

> embed NAT-like functionality in all of the hosts.

Chair hat off:

I repeat my comment from when I first saw Mike O'Dell's original 8+8
proposal: "It's architected NAT." I think anything that massages locators,
whether it's in the host stack or in a proxy, comes down to architected
NAT. Which means there is going to be state, so that the massage can be
reversed, so that the ULP always sees the same e2e identifier. It's a
design choice whether that state is in hosts, proxies, or both.

Actually, we're kidding ourselves if we don't admit that this is what
we are going to end up doing.

Chair hat on:

The design team has been asked to develop one specific approach
to this, namely the IP wedge layer approach, because that is where
the proposals and interest in the WG seem to be concentrated.

    Brian

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Aug 2004 02:29:06 -0700

> we are going to end up doing.

I think that it is vitally important that we all understand this and
how we got here.  If we want a host to respond flexibly to
multiple addresses, then either (a) the protocol stack needs to know 
about
the various addresses and can swap between them on the fly, OR
(b) something NATty outside of the protocol stack has to "fool" the 
protocol
stack into responding consistently.

Years ago, we rejected (a) on the grounds that it would change IPv6.
Folks who want to reject (b) now need to understand that they will be 
rejecting
the entire solution space...

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 13 Aug 2004 12:16:42 +0200

> Years ago, we rejected (a) on the grounds that it would change IPv6.

Well, my understanding is that this is still a valid approach to the 
problem, and i didn't get the feeling that we have rejected it (at 
least since i am in this wg), so, may i ask why did you reject this 
approach?

> the entire solution space...

Yes, FWIW, i agree that these are the two options

regards, marcelo

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Aug 2004 03:21:34 -0700

>> Years ago, we rejected (a) on the grounds that it would change IPv6
>

Umm.... as I alluded "we" (not I ;-) rejected this approach because 
there are existing
IPv6 host implementations.  Those would have to be 'revised' to support 
this model.
At the time, the WG felt that this was unacceptable.

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 13 Aug 2004 12:45:00 +0200

El 13/08/2004, a las 12:21, Tony Li escribió:

> IPv6 host implementations.  Those would have to be 'revised' to 
> support this model.

Ok. But currently, i think that it seems clear that any of the both 
approaches will require modifications in both ends of the 
communication.
I mean, any solution for preserving established sessions will impose 
modifications in both ends, mainly because security issues, so i guess 
that from this p.o.v. both approaches are equally acceptable, right?

regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Aug 2004 13:34:12 +0200

> At the time, the WG felt that this was unacceptable.

In my biased opinion, this is why goals 3.2.2 and 3.2.3 in RFC 3582 were
written *exactly* as they are. And they are part of the WG consensus, and
they do *not* exclude host and router modifications.

     Brian