Subject: Re: draft-ietf-multi6-multihoming-requirements-06.txt

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 18 Jun 2003 12:30:58 -0400

> From: Jay Ford <[email-masked]> 

    > The problem I see is that (srcaddr,dstaddr) selection by a multihomed
    > IPv6 host in the context of provider-based addressing can preempt the
    > routing. That means that the loading will be determined by clueless
    > edge hosts, which is about the worst place for such decisions to be made.

First, I'm reminded of Churchill's famous line about democracy - about how it
was the worst form of government, except for all the others. Similarly,
having the edge-hosts make routing decisions seems like the worst place to do
it - except for all the other choices!

I don't understand why people get so worried about having the hosts be more
involved in routing - but then perhaps my perspective helps me. E.g. way back
when (i.e. the ARPANet), the network did congestion-avoidance, not the hosts,
in part because "we have to protect the network and oh of course it's too
complex for hosts to do". But having the network do it for the hosts turned
out to have disadvantages. Now every host has very fancy congestion-avoidance
algorithms in it, and it works fine, and everybody thinks its normal. Also,
every human being (well, almost :-) is perfectly OK with the concept of
hopping in their car/whatever and reading a map to get somewhere. It's not
quantum mechanics, people.

Second, you are right that (srcaddr,dstaddr) selection is something of a
routing decision. However, making that choice more intelligently requires a
far better routing architecture than the one we have now - one that is
prepared to provide more information to hosts to allow them to make those
choices. (See Figure 1.) Lacking that, flipping a virtual coin (perhaps a
loaded one) is about as good as we're going to do...

	Noel

---

From: Jay Ford <[email-masked]>
Date: Wed, 18 Jun 2003 12:06:45 -0500 (CDT)

> loaded one) is about as good as we're going to do...

Call me a control freak, but I (as campus network routing guy) would like to
get a little more determinism than is afforded by a virtual coin toss, even a
weighted one.  If the address selection must occur in the host, I at least
want a hook to influence the selection process (for srcaddr *and* dstaddr).

Also, what about the interaction between (srcaddr,dstaddr) selection &
anti-spoofing-type filtering?  The routers do the filtering, but the host
does the address selection.  How does that work?  I don't want to have more
spoofed attacks with IPv6 than we have now with IPv4.

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: [email-masked], phone: 319-335-5555, fax: 319-335-2951

---

From: "Craig A. Huegen" <[email-masked]>
Date: Wed, 18 Jun 2003 12:16:20 -0500 (Central Daylight Time)

> want a hook to influence the selection process (for srcaddr *and* dstaddr).

There have been many similar comments (from myself as well) asserting
your statement.  It needs to be OS-independent as well, meaning that any
device that speaks IPv6 should be able to follow my rules/hints for where
traffic needs to go.  Any solution without this should be deemed
unacceptable.

Network mechanisms *need* to have visibility into alternate paths for a
particular destination so that the path selection can be chosen via
policy.

/cah

-- 
Craig A. Huegen, Chief Network Architect      C i s c o  S y s t e m s
IT Transport, Network Technology & Design           ||        ||
Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
San Jose, CA  95134, (408) 526-8104                ||||      ||||
email: [email-masked]       CCIE #2100      ..:||||||:..:||||||:..

---

From: S Woodside <[email-masked]>
Date: Wed, 18 Jun 2003 14:53:12 -0400

> loaded one) is about as good as we're going to do...

If that's the routing problem that you mean, it's I think a situation 
where any improvement is better than the current situation where there 
is no auto-configure solution. The typical home DSL user, who knows 
enough to link to their neighbour with a Wi-Fi box but doesn't know 
routing, would still see (up to) a doubling of throughput.

simon

--
www.simonwoodside.com -- 99% Devil, 1% Angel

---

From: S Woodside <[email-masked]>
Date: Wed, 18 Jun 2003 14:57:22 -0400

I understand what you are saying, however, what about the opposite end, 
is there a need to /always/ have management of path selection?

simon

---

From: Jay Ford <[email-masked]>
Date: Wed, 18 Jun 2003 14:24:30 -0500 (CDT)

On Wed, 18 Jun 2003, Craig A. Huegen wrote:
> > Call me a control freak, but I (as campus network routing guy) would like
> > to get a little more determinism than is afforded by a virtual coin toss,
> > even a weighted one.  If the address selection must occur in the host, I
> > at least want a hook to influence the selection process (for srcaddr
> > *and* dstaddr).
>

Agreed.

> particular destination so that the path selection can be chosen via

Exactly.  Note that the (srcaddr,dstaddr) tuple has to be chosen as a unit
for a particular path in order to avoid trouble with (e.g. anti-spoofing)
filtering.

On Wed, 18 Jun 2003, S Woodside wrote:
} I understand what you are saying, however, what about the opposite end,

Is asymmetry more of an issue in IPv6 than with IPv4?  (I'm really asking.
It might be.)

} is there a need to /always/ have management of path selection?

I'm arguing that there is always a need to have the /option/ of managing the
path selection.  The option might not always have to be used, but if we don't
build in the option now, it won't be there when needed.

---

From: S Woodside <[email-masked]>
Date: Thu, 19 Jun 2003 01:11:10 -0400

> build in the option now, it won't be there when needed.

OK. That's good, because then it's possible to satisfy the naïve user 
with a system that allows NO management of path selection, and will 
"just work" (auto-configure).

simon

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Jun 2003 09:10:23 +0300 (EEST)

> want a hook to influence the selection process (for srcaddr *and* dstaddr).

What is the number of the destinations you typically want to influence the 
selection process?

Note that if it's a rather small one, this one:

Default Router Preferences, More-Specific Routes, and Load Sharing
draft-ietf-ipv6-router-selection-02.txt

might help you a bit.

> spoofed attacks with IPv6 than we have now with IPv4.

At the moment, there is no interaction.  The routers have to allow both.  
But that's one field that in particular should be worked at.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Cedric de Launois <[email-masked]>
Date: 19 Jun 2003 08:41:18 +0200

> But that's one field that in particular should be worked at.
There IS interaction between src address selection and
anti-spoofing-type filtering, at least in the multiaddressing solution.
Suppose a site has 2 providers : ISPA and ISPB. Each provider delegates
one prefix (PA and PB) to the hosts. When sending a packet, if a hosts
choose PA as src address, then the packet must be routed through ISPA,
not through ISPB, to avoid anti-spoofing-type filtering.

A general principle would be :

  IF a host receives prefix PA in a router advertisement coming from 
  router RA THEN choose src address PA if the host sends a packet with 
  RA as the first hop toward the destination (i.e. the packet is sent
  through ISPA).

I would insert this rule just after the 7th rule in RFC3484.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Jun 2003 10:17:37 +0300 (EEST)

> not through ISPB, to avoid anti-spoofing-type filtering.

Yes, this is the interaction there *should* be, but currently isn't :-)
 
> I would insert this rule just after the 7th rule in RFC3484.

This doesn't help in the most typical case, where there is a single router 
advertising both prefixes. (It would only help when there are two routers 
advertising two different prefixes to the host.)

Basically the simplest fix is using policy-based routing in your site
border routers.  Not typically implemented for IPv6, but should be quite
straightforward.

See draft-savola-bcp38-multihoming-update-00.txt for more thoughts on
this.

---

From: Cedric de Launois <[email-masked]>
Date: 19 Jun 2003 09:33:50 +0200

> advertising two different prefixes to the host.)

When there is a single router, source-based routing can be used. The
router routes all packets with src address PA through ISPA.

> border routers.  Not typically implemented for IPv6, but should be quite

Agreed. But if there are two routers, packets addressed to the wrong
router need to be redirected in some way to the right router. The basic
src address selection mechanism I propose just helps to avoid the
redirection in this case. This is an heuristic that could help and that
don't cost a lot...

> See draft-savola-bcp38-multihoming-update-00.txt for more thoughts on

Thanks, I'll read it.

---

From: Jay Ford <[email-masked]>
Date: Thu, 19 Jun 2003 08:43:13 -0500 (CDT)

> draft-ietf-ipv6-router-selection-02.txt

That might work from some cases, but not my current situation.  My net has a
single core router for each user subnet, with the path divergence occurring
in the core or border routers.  Therefore, the hosts can't choose the path
because they only have one.

> But that's one field that in particular should be worked at.

This is operationally burdensome, especially because the burden propagates
upstream.

---

From: Jay Ford <[email-masked]>
Date: Thu, 19 Jun 2003 08:55:34 -0500 (CDT)

> router routes all packets with src address PA through ISPA.

I don't want source-based routing.  I want destination-based routing, with a
source address which works on the path I choose to that destination.  That's
the key aspect of the (srcaddr,dstaddr) selection which makes it
difficult->impossible for the host to do correctly.  It might end up being
difficult for me to do, but I want a shot at it before giving up.  (I haven't
figured out how to deal with path transitions which invalidate the chosen
(srcaddr,dstaddr) due to tight anti-spoofing filtering..., but I'm still
pondering that angle.)

> redirection in this case. This is an heuristic that could help and that

That makes the srcaddr choice preempt the dstaddr choice.  I prefer it to be
the other way around.