Subject: Re: Host-based may be the way to go, but network controls are neccessary

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 21 Nov 2002 13:16:12 -0500

> From: "Craig A. Huegen" <[email-masked]>

    > A host-based, host-only multihoming solution does not give the network
    > the visibility into alternate paths to a destination, and therefore
    > cannot apply policy to it.
    > The only point of control a network operator would have in that
    > environment is some kind of policy mechanism on hosts. I don't see it
    > scaling to hundreds of thousands of nodes unless the central policy
    > point is a function of the network.

Your message gives me a good launch pad for a rant I've been meaning to send
in for some months now. My previous message this morning alluded to it, and
here it is (in all its glory :-).

What you're asking for is, from the user's point of view, a subtle change to
the goals of "multi-homing", from reliability to control of paths. From the
architectural/ engineering point of view, however, it's an enormous change,
one which impacts the entire architecture of the network.

Look, the whole fundamental concept of the datagram network (as far as
traffic path selection goes), from Baran on through IPv6, was "you give your
packets to the network and it gets them there as best it can". *Everything*
is impacted by this decision, not just the routing - it extends down to the
internetwork-level packet headers, and the very form of the addresses
themselves.

E.g. at the time IPng was being discussed, there were two advanced routing
architectures (which could have given you the kind of capability you're
asking for) under way. Both prepared requirements documents, available as
RFC's 1668 and 1753 (the former is a bit sketchy, alas). The people involved
in both will tell you that IPv6 didn't provide what they needed. (Don't
bother looking at these documents - here in the age of photons, I think
they are both outdated.)

If you really want to be able to have meaningful control over the paths that
traffic takes, and not have traffic just take whatever path the routing
algorithm decides is current "the right thing" (usually based on a mechanism
that a) involves some sort of metric, and b) doesn't loop), you need to
completely re-architect, and then re-engineer, the entire internetwork layer.

First, you need to decide what you want your users to be able to do. Then
you have to design a routing system that will provide the users (and, to the
routing system, the corporate MIS people *are* 'the users) the information
they need. Then you have to figure out how the decisions the users make get
into the network. Only *then* can you say what will need to be in the
packets.

And trust me, the whole picture is not going to look *anything* like
"routing tables with longest match and detination addresses in the packets".

If all you really want is to be able to connect a fairly large number of
sites to two different ISP's, and have traffic still flow if one connection
is down, fine, that's one set of requirements, one that the existing
architecture can sort of handle, with a certain amount of painful changes
(like multiple addresses).

But if what you really want is much better control of where your traffic is
going, you're just bitten down on the entire RRG agenda - and a lot more,
because a routing architecture that can do that is going to be radical
enough that it's going to have ramifications everywhere.

Sure, you can probably clip off a small corner of the problem and add some
hacks which do a lot of what you want to do in that small corner (e.g. pick
the best exit gateway from your corporate network for this traffic). But
that's all it will be - just a quick kludge that fixes some specific little
goal - and, moreover, Yet One More Ugly Accretion that slowly kills the
entire architecteure by the Death of 1000 Ugly Kludges.

And, of course, that's exactly what this group will do - because doing the
Right Thing is impossible.

	Noel

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 21 Nov 2002 19:43:04 +0100 (CET)

> Right Thing is impossible.

So what's the right thing?

Being here in Atlanta was an eye-opener for me. It's unbelievable how
much work is still going on on IPv6 which by all accounts should have
been deployed by now.

The original TCP/IP architecture assumes that an interface on one host
communicates with an interface on another host, the network always knows
what connects where and nobody will try to disrupt all of this. Today,
most services run on several hosts (load balancers) or the other way
around (NAT). Most of the network has no idea if destinations are even
reachable, let alone what the shortest path is (CIDR). Every aspect of
the network is open to constant disruption (DDoS et al.). But IPv6 is
still just IPv4 with bigger addresses.

IPv6 is a reasonably good way to get packets across links. Routing and
layer 4 and up don't do what we need them to do so an architectural
overhaul is certainly in order.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 21 Nov 2002 20:44:51 +0100

> reachable, let alone what the shortest path is (CIDR). Every aspect of

Uhm, I would argue that pre-CIDR the network didn't know the 
shortest-path, not the other way around?

> still just IPv4 with bigger addresses.

Agree. However, addressspace and preventing DDOS are two completely 
different issues. We actually already today have both the tools and the 
knowledge to prevent many of the DDOS attacks, still people are not 
doing it. This has nothing to do with the architecture. Same goes for 
routing scaling. Announcing a /20 as multiple /24s is not a sign of a 
broken architecture.

> overhaul is certainly in order.
The above said, I do agree that there are things in the architecture 
that we need to change. I just don't think they are IPv6 specific.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 21 Nov 2002 21:16:21 +0100 (CET)

[I'll reply to your other message later, if not moot by then; yes, v6wg,
not ops, difference was not apparent to the untrained eye...]

> shortest-path, not the other way around?

I'm not saying pre-CIDR was the garden of eden, but today's aggreagation
hides information that could have been used for more optimal routing. I
think the benefit was worth it, but this is a clear example of current
practice falling outside the architectural assumptions, if not
foundations.

> doing it. This has nothing to do with the architecture.

You can hang a motor on a sailboat, but that only makes it a sailboat
with a motor, not a motorboat. If you have a sailboat and you need a
motor, this makes sense. When designing a new boat, not so much.

> that we need to change. I just don't think they are IPv6 specific.

Agree on the non-specific, disagree on the "change". We've done too much
changing already. I think we should forget the current protocols for a
while, and design a new architecture that can do what people are
actually trying to accomplish with current tools. If we have a good,
clean architecture, we can see how we can fit current protocols it, see
where we need to keep using hacks simply because they work, and build
whatever we don't have now but want. This part, we get to do right from
the start.

I'm not worried this is a waste of time. If the architecture is really
in dire need of an overhaul like we're saying here and elsewhere, a
better one will attract people that are trying to solve all kinds of
problems. A motorboat doesn't need to have a very big motor to pass a
sailboat.

Iljitsch

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Nov 2002 04:02:05 +0100

In your previous mail you wrote:

   different issues.

=> this is not 100% true: with the 2^64 addresses per link of IPv6,
you open the door to "in prefix" source spoofing, i.e., DDoS,
which defeats ingress filtering (look at the 3041 considered harmful
about the detailed argument).

Regards

[email-masked]

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 22 Nov 2002 04:06:15 +0100

> hides information that could have been used for more optimal routing. I

If what you are saying is that a single unaggregated prefix per site 
was a better choice to find the best paths,  I think that is to greatly 
oversimplify the problem. If what you are saying is that the current 
model is a problem in the sense that it creates problems in terms of 
routingtable growth as soon as we announce more specifics you are 
right. That is why we have this WG. A different problem is that it's 
only chartered to deal with this problem in IPv6...

However, I seriously doubt that a classful model would have worked 
better.

> motor, this makes sense. When designing a new boat, not so much.

Sorry, this analogy doesn't fly. Creating a architecture that will help 
us prevent DDOS or DOS is good, but will not only involve the 
multihoming model. It will require much more than that.

> while, and design a new architecture that can do what people are

I think was (actually currently is) discussed at the plenary.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 22 Nov 2002 04:09:37 +0100

> about the detailed argument).

The ip direct-broadcast problem is also in this way a addressing 
problem. I think it's not. It's an implementation issue. We create 
knobs for reasons, but we need to be careful with what we define as the 
default.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 22 Nov 2002 04:46:32 +0100 (CET)

On Fri, 22 Nov 2002, Kurt Erik Lindqvist wrote:

> > hides information that could have been used for more optimal routing.

> oversimplify the problem.

CIDR was a very good thing to do as we are essentially now solving this
problem 10 years later so it bought us 10 years. However, it does chip
away at the underlying IP architecture. You don't want to re-architect
at the drop of a hat but at some point it becomes inevitable. We're not
even there yet, but we are certainly feeling the pain of all the
previous chipping.

> multihoming model. It will require much more than that.

Of course changing the architecture involves much more than just
multihoming. So yes, this is off-topic on this list.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sat, 23 Nov 2002 18:28:10 +0100

> even there yet, but we are certainly feeling the pain of all the

Eh, as far as I remember CIDR was more a way to buy us time from 
address shortage and lead to more efficient usage of the IPv4 address 
space. It was never intended to solve the multihoming issue.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 23 Nov 2002 19:01:44 +0100 (CET)

On Sat, 23 Nov 2002, Kurt Erik Lindqvist wrote:

> > problem 10 years later so it bought us 10 years.

> space.

As I understand it (but I wasn't around) new assignments were made from
class C space because class B space was about to deplete. However, this
meant people who would have used a /16 (class B) before would now maybe
use a /20 (16 class Cs) -> routing table explosion. CIDR was implemented
to handle that problem.

> It was never intended to solve the multihoming issue.

Before CIDR there was no multihoming issue.  :-)

Iljitsch

---

From: Scott W Brim <[email-masked]>
Date: Sat, 23 Nov 2002 15:42:59 -0500

> Before CIDR there was no multihoming issue.  :-)

This statement doesn't make sense to me.  There was multihoming before
CIDR.  We had hierarchy arguments.  We had already overwhelmed some
routers with RIB size (iirc the first was when we hit 108 routes) and
route lookup time.  All the problems were there in potential.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 23 Nov 2002 22:47:01 +0100 (CET)

> route lookup time.  All the problems were there in potential.

I really want to put this thread to bed, as it doesn't help us much with
what we're doing here, but...

Pre-CIDR everyone who was connected announced their class A, B or C
blocks into the global routing table, whether they were multihomed or
single-homed. So there were issues (and they were similar in nature to
the ones we're trying to solve here), but they were unrelated to
multihoming.