Subject: RE: multihomed host

From: "Michel Py" <[email-masked]>
Date: Wed, 9 Oct 2002 15:21:34 -0700

> Yoshihiro Ohba wrote:
> I don't know if there is an official definition, but I
> have usually heard the term "multihomed host" used to
> refer to multi-interface systems that do not function
> as routers (i.e. they don't forward packets).

Here is my reading of this:

1. Multi-interface host:
> Margaret Wasserman wrote:
> I don't know if there is an official definition, but I
> have usually heard the term "multihomed host" used to
> refer to multi-interface systems that do not function
> as routers (i.e. they don't forward packets).

I agree with Margaret. A host that has multiple interfaces connected to
multiple subnets *is* a multihomed host, but...

2. A host that has multiple interfaces with addresses in the same subnet
(either to increase throughput or to provide redundancy) is *not* a
multihomed host.

3. Single interface, multiple address host:
> Bill Sommerfeld wrote:
> For what it's worth, I've occasionally heard the
> term used in an application-layer context to refer
> to hosts having multiple IP addresses rather than/in
> addition to multiple interfaces.

For v4, I agree with Bill *if* the multiple addresses belong to
different subnets.

For v6, this is blurry. Would you call multihomed a host that has both a
link-local and a regular unicast address on the same interface? I don't
think so.

On the other hand,
> Yoshihiro Ohba wrote:
> There may be some scenario in which a single-interface
> host is connected to multiple ISPs on the same link, which
> seems to be not covered in the usual definition for
> "multihomed host". I don't know what to call the model,
> but is such a model already common? Or is there any
> ongoing work on this model?

This is possible as of today; a host that has multiple PA addresses is
certainly considered a multihomed host. However, this alone is not a
multihoming solution.

4. A host that has a single address but is part of a multihomed site:
This would be the case for hosts belonging to a multihomed LIR, or the
case of hosts connecting to a MHAP network. I do not call these hosts
multihomed.

In other words: semantically speaking, the fact that the host is
connected to a multihomed router does not make the host itself
multihomed, IMHO.

Michel.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 09 Oct 2002 18:48:32 -0400

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

>From the point of view of what applications need to do, it's safest to
assume that all V6 hosts are multiaddressed.

						- Bill

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 9 Oct 2002 19:20:56 -0400

Thank you all for helping me understand.

I have additional question below.

> certainly considered a multihomed host. However, this alone is not a

What additional things need to be considered for this usage to become
a multihoming solution?

Yoshihiro Ohba

---

From: "Michel Py" <[email-masked]>
Date: Wed, 9 Oct 2002 23:11:09 -0700

>> Michel Py wrote:
>> This is possible as of today; a host that has multiple PA
>> addresses is certainly considered a multihomed host.
>> However, this alone is not a multihoming solution.

> What additional things need to be considered for this
> usage to become a multihoming solution?

There is no simple answer to this question. Here is one approach:
http://arneill-py.sacramento.ca.us/ipv6mh/draft-bagnulo-mhExtHdr-00.txt

Michel.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 10 Oct 2002 09:02:34 +0200 (CEST)

> What additional things need to be considered for this usage to become

A good multihoming solution keeps working if there are failures. So the
applications must be smart enough to try all the addresses rather than
just one. Telnet and FTP do this, WWW clients typically don't.
Unfortunately, this must be done at the remote end and not on the
multi(homed|addressed) host itself.

When there is a session, and the path over one ISP becomes unavailable,
the multihomed host must switch to the path over the other ISP. There are
many problems with this. First of all, the failure must be detected. Then
the host can reroute outgoing packets. But if the host still uses the same
source address (from the address space from the failed ISP), it is likely
the packets won't be accepted by the alternate ISP because the source
addresses are "spoofed". And even if they are, the communications partner
keeps sending packets back to th source address tied to the first ISP,
which isn't reachable any more.

One solution for the address problem would be the adoption of new or
improved transport protocols that can handle this. There have been
experiments with modifications to TCP to support this, and the new SCTP
protocol can also handle this. However, modifying all transport protocols
might be problematic.

Another solution is tunnelling/aliasing the packet to hide the original
address while the packet is rerouted over the alternative path. The
destination host or a box very close to the destination host strips of the
tunnel header or replaces the original address so TCP and other transport
protocols don't see the change in address.

Some of us are working on this stuff on a non-IETF mailinglist. The latest
idea is to come up with a common tunnelling/aliasing framework so
different solutions in this area may interoperate.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 10 Oct 2002 11:20:35 -0400

Thanks Iljitsch for detailed answer and Michel for the pointer.

Actually, I'm working in the PANA WG and viewing this kind of
multihomed host scenario from network access authentication
perspective, and wondering whether the PANA WG needs to consider this
scenario for now.  (My impression is that there is a lot of work to
consider before considering network access authentication)

Yoshihiro Ohba