Subject: RE: The state of IPv6 multihoming development

From: "Michel Py" <[email-masked]>
Date: Wed, 23 Oct 2002 22:52:36 -0700

Noel,

> J. Noel Chiappa wrote:
> 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.

I totally disagree, and this sounds rather surprising to me considering
what you have written in the past about identity/location separation.
Would you be more specific about why you find this unlikely, and what
you call "widely spaced" (which I read as "from different PA blocks).

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

There is a difference between the solution itself using multiple
addresses and each host using multiple addresses. If each host has to
use multiple addresses, I regret to report that Craig's statement is not
an opinion, but a fact. Any people that disagree with this and that
actually have renumbered a 1000+ subnet enterprise network, please speak
up; otherwise, don't.

However, a solution that involves multiple addresses at the edge of the
organization but single addresses on the internal network and hosts does
not look unfeasible to me (Craig, please comment).

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

No disagreement here. That being said, we are not pursuing the UMS
without new code, are we?

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

All on the multihomed end seems unrealistic, but there are ways to avoid
impact on the source single-homed end.

Michel.

---

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

> not look unfeasible to me (Craig, please comment).

From a routing perspective, this doesn't look unfeasible.  Care must be
given to those applications which currently embed end-to-end addresses in
the upper-layer payload (H.323); this type of solution would imply a
knowledge base in the routing infrastructure to perform embedded
translation or an acceptance that these applications do not work.

/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: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Oct 2002 21:49:13 +0200 (CEST)

> translation or an acceptance that these applications do not work.

If there is a "primary" address known as such by all (the apps,
transport layers at both ends and the onimous boxes in the middle) this
shouldn't be a problem. As an enterprise, you'd want a good set of
primary addresses anyway, because those would be the
provider/connectivity independent ones.

---

From: Peter Tattam <[email-masked]>
Date: Fri, 25 Oct 2002 07:20:31 +1100 (EST)

> translation or an acceptance that these applications do not work.

This is fine if one can accept the level of insecurity within a site.  WHat
about sites that don't necessarily look like an edge router but rather a cloud
with multiple entry points.  You then have the possibility of a host not
knowing which source address to select.

Source address selection has been a much overlooked issue in the debate since
most of the descussion seems to me to be focused on delivery.

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Oct 2002 08:51:33 +0859 ()

Huegen;

> translation or an acceptance that these applications do not work.

According to the end to end principle, routing infrastructure MUST be
dumb that there is no room for perspective.

If an address of an end system is known, reverse and forward DNS look
up gives all the addresses of the end system.

It is an end system local issue having nothing to do with the routing
infrastructure.

People are free not to register the information to DNS, though they
can not enjoy robust internet connectivity with multihoming.

							Masataka Ohta

---

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

> up gives all the addresses of the end system.

As an enterprise network operator I do not have reasonable policy controls
when path selection is performed by the originating host's selection of
source and destination addresses from the system's set of source addresses
and the destination's set of DNS-registered addresses.

DNS as a routing policy specification language seems inappropriate to me.

I can accept some interaction between the host and network infrastructure
in order to determine the best path to use to a multi-address destination
host; however, we still run into the support issues associated with
applying and maintaining several, multi-PA prefixes to tens of thousands
of subnets.

/cah

---

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 25 Oct 2002 09:41:49 +0859 ()

Huegen;

> DNS as a routing policy specification language seems inappropriate to me.

Your assumption that the originating host source and destination
for path selection is self contradictory.

Originating host can control forward path with proper selection
of destination.

There is no such issue of source address selection.

> applying and maintaining several, multi-PA prefixes to tens of thousands

In draft-ohta-e2e-multihoming-02.txt, I wrote:

   Once a full routing table is available on all the end systems, it is
   easy for the end systems try all the destination addresses, from the
   most and to the least favorable ones, based on the routing metric.

   Note that end to end multihoming works with the separation between
   inter domain BGP and intra domain routing protocols, if BGP routers,
   based on domain policy, assign external routes preference values
   (metric) of intra domain routing protocols.

All we need is a RIP-like mechanism to distribute global routing table
with proper metric to all the hosts, to let the hosts control forward
pathes with proper selection of destinations.

Note that dumb hosts relying on intelligent default routers are the
first step for intelligent networking and is a major design flaw
of IPv6.

							Masataka Ohta