Subject: Re: multihomed host

From: Margaret Wasserman <[email-masked]>
Date: Wed, 09 Oct 2002 15:42:47 -0400

>
>
>Is there any definition for multihomed "host"?

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

Margaret

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 9 Oct 2002 15:28:41 -0400

Hi,

I have one question about multihomed host.

In the multi6 WG charter, there is the following definition 
for multihomed "site":

  A multihomed site is a site that has more than one connection to the
  public internet with those connections through either the same or
  different ISPs.  Sites choose to multihome for several reasons,
  especially to improve fault tolerence, perform load balancing, etc.

Of cource, a definition would be quickly made by just replacing a
word "site" in the above definition with "host", but please let me
know if there is other definition.

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 9 Oct 2002 16:09:20 -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! ]

Thanks for your quick response.

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?

> as routers (i.e. they don't forward packets).

Thanks,

Yoshihiro Ohba

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 09 Oct 2002 16:31:28 -0400

> as routers (i.e. they don't forward packets).

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. 

						- Bill

---

From: William Waites <[email-masked]>
Date: 10 Oct 2002 14:44:54 -0400

>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:

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

This  just  looks like  the  degenerate  case  -- multiple  addresses,
multiple  interfaces,  except that  each  of  the multiple  interfaces
happen to  be the  same. It seems  to me  that the network  layer code
should treat both cases identically. Does this make sense?

-w
-- 
William Waites <[email-masked]>
Idiosyntactix Research Laboratories	Any sufficiently advanced technology
http://www.irl.styx.org			is indistinguishable from a rigged demo.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 10 Oct 2002 21:26:59 +0200 (CEST)

> should treat both cases identically. Does this make sense?

There is one difference that may be important sometimes, but
inconsequential at other times: a host can detect that an interface is
down. It can't necessarily detect the link to an ISP is down.

---

From: William Waites <[email-masked]>
Date: 10 Oct 2002 16:04:48 -0400

>>> "Iljitsch" == Iljitsch van Beijnum <[email-masked]> writes:

    Iljitsch> There is one difference that may be important sometimes,
    Iljitsch> but inconsequential  at other  times: a host  can detect
    Iljitsch> that an  interface is down. It  can't necessarily detect
    Iljitsch> the link to an ISP is down.

But the "physical  interface is down" failure mode  is relatively rare
-- as soon  as an ethernet switch,  or ethernet to atm  or mpls bridge
is thrown into  the mix, the "physical interface is  up but link layer
is down"  failure mode becomes much  more common. In  fact it subsumes
the first case since if there's no physical interface, there's no link
layer. 

Is the correct place to implement detection of these types of failures
in the link layer? But then  the providers have to play nicely, and it
says  nothing  about problems  more  than one  hop  out  in the  ISP's
network. Or beyond the ISP's AS even...

I  guess I  am  not sure  where  in the  stack  the failure  detection
belongs, or which types of failures are to be addressed here...

-w
-- 
William Waites <[email-masked]>            Any sufficiently advanced
Idiosyntactix Research Laboratories	technology is indistinguishable
http://www.irl.styx.org			from a rigged demo.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 10 Oct 2002 22:15:37 +0200 (CEST)

> is down"

That's the whole problem with switched networks: you can't detect failures
at layer 2, so you have to do it at layer 3. (The problem could have been
in layer 3 in the first place, so you have to detect layer 3 problems
anyway.) I wouldn't discount the usefulness of being able to detect
failures at layer 1: this is much, much faster than anything else.

> belongs, or which types of failures are to be addressed here...

Failure detection is one of the major challenges in multihoming solutions
that aren't router-based. My thinking is that TCP should signal the IP
layer that there _may_ be a problem and the IP layer should either act as
if there is, or make sure first.

In any event, it has to be end-to-end. Unfortunately, this doesn't mean
you can leave it out at the lower layers, since failure detection at layer
4 is very slow (TCP timeout...) and you don't want to have to do this time
and time again when going back to the same destination.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 11 Oct 2002 15:15:30 +0200 (CEST)

> should treat both cases identically. Does this make sense?

There are some important differences when it comes to the relationship
between IP source address and routes that are used.

draft-ietf-ipv6-default-addr-select-09.txt
specifies that the candidate source address are related to the
interface on which a packet is sent.

Hence there is a difference  between 
case 1:
	Host with one interface, two routers, two global addresses with
	different prefixes (whether one router advertises each addrconf prefix
	or both routers advertise both prefixes).

	In this case the candidate source address will be both global
	addresses, and the other rules in the source address selection
	will determine which source address is used.

	Note that there is no relationship between the source address selected
	and which (default) router is used for sending packets.

case 2:
	Host with two interface, one router on each interface, one global
	address being configured on each interface with different prefixes
	(each router advertises a single addrconf prefix)

	In this case the candidate source address set will be coupled
	to the (default) route used to send the packet, since there
	are two interfaces.

In both cases there are issues of what happens when e.g. one of the routers
fail, which have to do with not only how the host behaves but also how
routing works beyond the first hop routers.

  Erik