Subject: RE: The state of IPv6 multihoming development

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 24 Oct 2002 00:03:06 -0400

> From: Iljitsch van Beijnum <[email-masked]>

    > If we look at a huge enterprise as one example of someone who needs
    > multihoming, and at a single host with two interfaces or one interface
    > with two addresses as another .. they could both use a multi address
    > solution.

This is an excellent point, part of one I was about to make myself, actually,
as a result of my previous message mentioning the difference between "site
multi-homing" and "host multi-homing".

If you have a host which is multi-homed to widely spaced points in the
topology, there's unlikely to be a routing-based solution, i.e. one where that
host has only one address.

    > For the host, this could be something like Marcelo Bagnulo's extension
    > header, modified mobility, Peter Tattam's modified TCP or my own
    > "BALTS" idea. These all boil down to a host having several addresses
    > and being able to receive packets on a secondary address and trick the
    > transport layer into thinking it's still using the primary address.

Two points. First, Craig Huegen seems to think that any solution involving
multiple addresses is infeasible for a large organization. What's your reply
to him?

Second, I seem to recall some people objecting to multiple addresses because
it's too much code/complexity. It would seem to me that once you have
multiple addresses, the details on exactly how they are used are somewhat in
the noise; whether one tricks the transport layer, or gets it to understand
the possibility of multiple addresses, there's a certain amount of code
involved.

About the only way I could see it making a difference is if you can figure out
some way to do all on the multi-homed end. Some multiple-address schemes
involve both ends, which is obviously more perturbing. The downside, of
course, is that then there are probably things you can't do it you only
involve the multi-homed end. (Too tired to figure them all out right at the
moment - although I suppose you could use the "aliasing/tunneling devices"
at the non-multi-homed end to get around this.)

Of couse, then it starts to get ugly pretty quickly... lots of different hacks
and kludges.

	Noel

---

From: Shane Kerr <[email-masked]>
Date: Thu, 24 Oct 2002 10:04:18 +0200

On 2002-10-24 00:03:06 -0400, J. Noel Chiappa wrote:
> 
> Two points. First, Craig Huegen seems to think that any solution
> involving multiple addresses is infeasible for a large organization.
> What's your reply to him?

Even if he's right, I think he's wrong to argue against end-point
solutions based on multiple addresses.  Given the current
understanding of the problem and the approaches that have been
outlined, doesn't it seem like wishful thinking to want One True
Multihoming strategy?  For small sites, binding multiple PA addresses
into a single end-point seems like a straightforward, cheap, and
effective solution.

I'm not even 100% sure he's correct that multihoming needs to be in
the network in order to do traffic engineering.  At least, I can
envision end-site solutions that solve some (simple) classes of
traffic engineering requirements.  :)

-- 
Shane Kerr
RIPE NCC

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Oct 2002 10:06:31 +0200 (CEST)

> host has only one address.

Disagree with you there, but I think that's nothing new by now.

Maybe we should have a look at source routing?

> multiple addresses is infeasible for a large organization. What's your reply

I was talking specifically about a multihomed host in the above. Looking
at a large multihomed organization as simply a collection of individual
hosts that are all multihomed is unmanagable. So remove the multihoming
processing to the edges where you can control it. I think that could
work well.

> it's too much code/complexity.

My objection is that it will take too long to develop to simply wait for
it, we must have something in the mean time. But other than that I don't
think the complexity is too bad.

> It would seem to me that once you have

Well, yes, sort of.

> some way to do all on the multi-homed end.

I don't see this happening. If the destination is multihomed using
several addresses, and the source is single homed, the best we can do is
move the necessary processing from the source to a box a little
upstream. This could be a router/firewall or maybe ISPs can do this for
their customers. But if the destination has several addresses and the
one used becomes unreachable, someone somewhere will have to switch to a
secondary address.

> Some multiple-address schemes

> Of couse, then it starts to get ugly pretty quickly... lots of different hacks

It's no worse than mobility. And have a look at the v4 routing table,
that's not exactly a thing of beauty either.

---

From: "Michael H. Lambert" <[email-masked]>
Date: Thu, 24 Oct 2002 08:11:37 -0400

--On Thursday, 24 October 2002 10:06 +0200 Iljitsch van Beijnum 
<[email-masked]> wrote:

[...]

>From S's perspective, I can see that this scenario would make it easy to 
use the right path (from N1, N2, ...) to reach D.  However, wouldn't it 
require the edge to maintain state for each flow which crosses it?

Michael

+-----------------------------------------------------------------------+
| Michael H. Lambert, Network Engineer           Phone: +1 412 268-4960 |
| Pittsburgh Supercomputing Center               FAX:   +1 412 268-8200 |
| 4400 Fifth Avenue, Pittsburgh, PA  15213       [email-masked]        |
+-----------------------------------------------------------------------+

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Oct 2002 14:20:03 +0200 (CEST)

On Thu, 24 Oct 2002, Michael H. Lambert wrote:

> > Looking

> require the edge to maintain state for each flow which crosses it?

It shouldn't if these boxes just replace prefixes. In current NAT setups
much more is changed: the entire address, not just a prefix, for
starters, and also a port number and the TCP/UDP checksum. In the setup
I'm talking about just the prefix (presumably, the 48 most significant
bits) change and everything else remains the same, so no need to keep
state.

---

From: Tim Chown <[email-masked]>
Date: Thu, 24 Oct 2002 13:32:23 +0100

> bits) change and everything else remains the same, so no need to keep

Well, that has been punted around as an idea for some time (8+8 or 6+2+8).

e.g. from 1995/6:
http://www.wcug.wwu.edu/lists/ipng/199612/msg00116.html

Tim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Oct 2002 14:57:36 +0200 (CEST)

> Well, that has been punted around as an idea for some time (8+8 or 6+2+8).

I'm not claiming to have come up with this, let alone that I'd be the
first one. What I have in mind is Michel Py's MHAP draft, although the
part where a multi-addressed host interacts with the MHAP infrastructure
isn't in there, you can blame me for that part.

> http://www.wcug.wwu.edu/lists/ipng/199612/msg00116.html

On the ipv6mh list we've pretty much disected GSE, which is along the
same lines. While this would certainly make for an interesting new
direction for further development of the IP family, it doesn't actually
solve multihoming while at the same time being so radical it will be
hard to get off the ground.

If we want to move into the direction of separating identifiers and
locators it's probably easier to keep a globally unique and
(potentially) routable IPv6 address as the identifier since that way we
don't need changes to transport protocols and no "flag day".

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Oct 2002 14:59:53 +0200

> http://www.wcug.wwu.edu/lists/ipng/199612/msg00116.html

And it is not part of the IPv6 that is being rolled out today, so
I don't think rehashing the debate is relevant to multihoming that IPv6.

  Brian

---

From: "Craig A. Huegen" <[email-masked]>
Date: Thu, 24 Oct 2002 14:35:49 -0500 (Central Daylight Time)

> into a single end-point seems like a straightforward, cheap, and

I'm not arguing against multi-PA for small organizations.  I can
anticipate it working for the small sites with less than 100 segments or
so (actual number may vary).  Some limitations still exist -- for example,
the deprecation of all of the subnets within a prefix when the link
serving that prefix goes away (or using a NAT function).

I do know, however, that it isn't reasonable in a network with tens of
thousands of segments.

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