Subject: WG Action - ACCEPT [LL32] Multihoming problems not solved but that is OK

From: Erik Guttman <[email-masked]>
Date: Tue, 03 Jun 2003 18:52:47 +0200

After fruitful discussion, I believe we have consensus around a revised
version of text for this section.

NOTES:

1 Mika asked

   But what does this mean, anyway? I hear developers asking: "Most
   TCP/IP stacks support multihoming. Is this specification supposed
   to be implementable on multihomed stacks or not?"

   Assuming the implementor of a multhomed stack does not want to wing
   it, is he supposed to:

   1) not implement LLs at all?
   2) turn LLs off if more than one interface is activated?
   3) provide per-interface configuration knobs and leave it to the
      user to deal with the problem?
   4) any of the above? (probably)

   I respond:

   We cannot (have not been able to, will not be able to) provide
   answers to these questions.  The best we can do is to provide
   guidance about what the problems are and how one might start on
   the way to solve them.  Once we have experience solving the
   problems we could undertake to standardize the successful
   approach(es).

------------------------------
Replace section 3 with the following text:

3. Considerations for Multiple Interfaces

These considerations apply whenever a host has multiple IP addresses
whether or not it has multiple physical interfaces. Other examples of
multiple interfaces include different logical endpoints (tunnels,
virtual private networks etc.) and multiple logical networks on the same
physical medium. This is often referred to as "multihoming".

Hosts which have more than one active interface and elect to implement
dynamic configuration of Link-Local IPv4 addresses on one or more of
those interfaces will face various problems. This section lists these
problems but does no more than indicate how one might solve them. At the
time of this writing, there is no silver bullet which solves these
problems in all cases, in a general way. Implementors must think through
these issues before implementing the protocol specified in this document
on a system which may have more than one active interface as part of a
multihoming capable TCP/IP stack.

3.1. Scoped addresses

The general problem here is that a host may be attached to more than one
network at the same time.  It would be nice if there was a single
address space used in every network, but this is not the case. Addresses
used in one network, be it a network behind a NAT or a link on which
Link-Local IPv4 addresses are used, cannot be used in another network
and have the same effect.

It would also be nice if addresses were not exposed to applications, but
they are. Most software using TCP/IP which await messages receives from
any interface at a particular port number, for a particular transport
protocol. Applications are generally only aware (and care) that they
have received a message. The application knows the source address of the
sender to whom the application will reply.

The first scoped address problem is source address selection. A
multihomed host has more than one address. Which address should be used
as the source address when sending to a particular destination? This
answer is usually answered by referring to a routing table, which
expresses which interface (with which address) to send, and how to send
(should one forward to a router, or send directly). The choice is made
complicated by scoped addresses because the address range in which the
destination lies may be ambiguous. The table may not be able to yield a
good answer.  This problem is bound up with next-hop selection, which
is discussed in Section 3.2.

The second scoped address problem arises from scoped parameters leaking
outside their scope. This is discussed in Section 7.

It is possible to overcome these problems. One way is to expose scope
information to applications such that they are always aware of what
scope a peer is in. This way, the correct interface could be selected, a
safe procedure could be followed with respect to forwarding addresses
and other scoped parameters. There are other possible approaches. None
of these methods have been standardized for IPv4 nor are they specified
in this document.  A good API design could mitigate the problems, either
by exposing address scopes to 'scoped-address aware' applications or by
cleverly encapsulating the scoping information and logic so that
applications do the right thing without being aware of address scoping.

An implementor could undertake to solve these problems, but cannot
simply ignore them. With sufficient experience, it is hoped that
specifications will emerge explaining how to overcome scoped address
multihoming problems.

3.2. Address Ambiguity

This is a core problem with respect to Link-Local IPv4 addresses
configured on more than one interface. What should a host do when it
needs to send to Link-Local destination L and L can be resolved using
ARP on more than one link?

One possibility is to support this only in the case where the
application specifically expresses which interface to send from.

There no standard or obvious solution to this problem.
Existing application software written for the Internet protocol suite is
largely incapable of dealing with address ambiguity. This does not
preclude an implementor from finding a solution, writing applications
which are able to use it, and providing a host which can support dynamic
configuration of Link-Local IPv4 addresses on more than one interface.
This solution will almost surely not be generally applicable to existing
software and transparent to higher layers, however.

3.3. Interaction with hosts with routable addresses on local links

Attention is paid in this specification to transition from the use of
Link-Local IPv4 addresses to routable addresses (see Section 1.5). The
intention is to allow a host with a single interface to first support
Link-Local configuration then gracefully transition to the use of a
routable address. Since the host transitioning to the use of a routable
address will not advertise scoped address information, the scoped
address issues described in Section 3.1 will apply. A host which
conforms to this specification will know that a Link-Local IPv4
destination must be reached by forwarding to the destination, not to a
router, even if the host is sending from a routable address.

A host with a Link-Local IPv4 address may send to a destination which
does not have a Link-Local IPv4 address. If the host is not multihomed,
the procedure is simple and unambiguous: Using ARP and forwarding
directly to on-link destinations is the default route. If the host is
multihomed, however, the routing policy is more complex, especially if
one of the interfaces is configured with a routable address and the
default route is (sensibly) directed at a router accessible through that
interface. The following example illustrates this problem and provides
a common solution to it.

                        i1 +---------+ i2   i3 +-------+
              ROUTER-------=  HOST1  =---------= HOST2 |
                     link1 +-------=-+  link2  +-------+

In the figure above, HOST1 is connected to link1 and link2. Interface
i1 is configured with a routable address, while i2 is a Link-Local IPv4
address. HOST1 has its default route set to ROUTER's address, through
i1. HOST1 will route to destinations in 169.254/16 to i2, sending
directly to the destination.

HOST2 has a configured (non-Link-Local) IPv4 address assigned to i3.

Using a name resolution or service discovery protocol HOST1 can discover
HOST2's address. Since HOST2's address is not in 169.254/16, HOST1's
routing policy will send datagrams to HOST2 via i1, to the ROUTER.
Unless there is a route from ROUTER to HOST2, the datagrams sent from
HOST1 to HOST2 will not reach it.

One solution to this problem is for a host to attempt to reach any host
locally (using ARP) for which it receives an unreachable ICMP error
message (ICMP message codes 0, 1, 6 or 7, see [RFC792]). The host tries
all its attached links in a round robin fashion. This has been
implemented successfully for some IPv6 hosts, to circumvent exactly this
problem. In terms of this example, HOST1 upon failing to reach HOST2
via the ROUTER, will attempt to forward to HOST2 via i2 and succeed.

It may also be possible to overcome this problem using techniques
described in section 3.2, or other means not discussed here. This
specification does not provide a standard solution, nor does it preclude
implementors from supporting multihomed configurations, provided that
they address the concerns in this section for the applications which
will be supported on the host.

3.4. Unintentional Autoimmunity

Care must be taken if a multihomed host can support more than one
interface onto the same link, all of which will support Link-Local
autoconfiguration. If these interfaces attempt to allocate the same
address, they will defend the host against itself - causing the claiming
algorithm to fail. The simplest solution to this problem is to run the
algorithm independently on each interface configured with Link-Local
IPv4 addresses.