Subject: New Issue [LL32] Multihoming problems not solved but that is OK

From: Erik Guttman <[email-masked]>
Date: Mon, 26 May 2003 11:52:15 +0200

I thought I posted this last week, but I do not see it in the mailing
list archive.  The purpose of this issue is to

  * resolve the concern Mika raised about interoperation between a
    multihomed host communicating with a non-LL destination
    address through a LL address configured interface.

  * to rework the entire multihoming section so as to give advice and
    issue warnings, but not to treat the subject as if the text were
    definitive or multihoming and use of LL is a solved and well
    understood topic

Description of Issue Multihoming problems not solved but that is OK
Submitter Name Erik Guttman
Submitter Email Address [email-masked]
Date first submitted May 21, 2003
Reference zeroconf mailing list
Comment Type ['T'echnical | 'E'ditorial] T
Priority ['S' Must fix | '1' Should fix | '2' May fix ] S
Section 3 (entire section)
Rationale/Explanation of issue:

While the document does describe the problem of using dynamic
configuration for IPv4 LL on more than one link, it does not solve the
problem. It is not possible for this to be done transparently to upper
layer applications given existing interfaces and expectations. Further,
there are routing issues when LL is used on one link and another link is
active (whether it is LL or not). Lengthy description of problem:
Section 3 outlines options and strategies but does not definitively
solve the problem of multihoming used concurrently with IPv4 LL
autoconfiguration. Long discussion on the zeroconf mailing list shows
there is a tension between two objectives:

(1) Continuous use of LL on one or more interface - to ensure
availability of local communication in all cases and

(2) A process by which a scoped address architecture for IPv4 can be
avoided. A scoped address architecture presents problems for upper
layers and in any case has not yet been thought through so as to work
generally for IPv4.

The second objective has more support in the working group, but the
first objective is a real concern. The purpose of this issue is to

o Remove text in section 3 which could mislead or confuse implementors
   by presenting multihoming as an understood or solvable problem, simply
   by by following the steps given in the document.

o To not preclude those who have a plan on how to get multihoming from
   doing so and not then be non-compliant with the specification.

o To not stand in the way for later work to describe how to solve the
   multihoming problem of scoped addresses in a general and correct way.

All we can say in this document with certainty is how hosts use IPv4 LL
on a single link to configure addresses. We must also give guidance to
router vendors. In the multihoming section we will simply give warnings
about known problems and indicate that if you proceed there, you are on
your own.

----------------------------------
Requested Change:

Replace Section 3 with the following text:

3. Considerations for Multiple Interfaces

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
which will have more than one active interface.

3.1. Scoped addresses

The general problem here is that a host may be attached to more than one
network at the same time. This could be due to having more than one
interface attached to distinct physical networks, or due to support of a
tunnel, virtual private network, or some other interface termination at
the host over a single interface. 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.

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.

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.

Another possibility is to determine routes by expressing destinations
with a higher layer, unambiguous identifier. That is, if addresses are
not exposed to applications at all, routing decisions can be made by the
IPv4 stack without having to resort to routing decisions based on
ambiguous addresses.

The obvious candidate for this 'higher level identifier' is the Fully
Qualified Domain Name (FQDN). However caution is advisable since routing
on the basis of names is not standardized. Just as address spaces can be
scoped and ambiguous, so can name spaces. This is especially true for
self assigned or automatically generated names.

In short, 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. Interoperation with Legacy Hosts

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

---

From: Mika Liljeberg <[email-masked]>
Date: 27 May 2003 23:03:09 +0300

Hi,

Comments below.

On Mon, 2003-05-26 at 12:52, Erik Guttman wrote:
[...]
> about known problems and indicate that if you proceed there, you are on

Given this, section 1.5 should state explicitly that the text only
applies to singlehomed hosts, and refer multihomed implementations to
section 3.

[...]
> these issues before implementing the protocol specified in this document

something missing? I'll assume the sentence was supposed to end with
something like "...as part of a multihoming capable TCP/IP stack",
rather than

> which will have more than one active interface.

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)

> 3.1. Scoped addresses

This section seems to be primarily talking about ambiguous addresses.

[...]
> destination lies may be ambiguous. The table may not be able to yield a

This isn't really talking about source address selection, is it? This
describes a difficulty with next hop selection, caused by the ambiguity
of the destination address. Move this to section 3.2.

> of these methods have been standardized for IPv4 nor are they specified

The last sentence is stating the obvious, since IETF is not in the habit
of standardizing APIs. It would be more helpful to start off by
suggesting that good API design can mitigate the problems and then go on
to give a few pointers on how to do that.

[...]
> 3.2. Address Ambiguity
[...]
> self assigned or automatically generated names.

The above is going a bit far afield. Probably more confusing than
helpful.

> 3.3. Interoperation with Legacy Hosts

This section is mis-named. The discussion applies to all cases where a
node using a LL address communicates with a node using a routable
address. This is ESPECIALLY relevant when the other node is LL-compliant
but happens to have a routable address configured.

> directly to on-link destinations is the default route.

I have a problem with this claim. If you apply this rule to the figure
below, the routing table of interface i2 depends on whether interface i1
is UP (HOST1 is multihomed) or DOWN (HOST1 is singlehomed). That's
hardly simple or unambiguous.

>  If the host is
> message (ICMP message codes 0, 1, 6 or 7, see [RFC792]).

It looks like this will either block the ICMP error delivery to
transport and application layers or cause the applicatins to see some
interesting transient failures.

>  The host tries
> problem.

Interesting, I wasn't aware of that. Last time I asked about this on the
ipng list (maybe a couple of months ago), nobody owned up to having
implemented a solution. The KAME people actually said that they support
the "try on-link" rule but that it is turned off by default, because it
does not work with multihoming.

Can you point me to some implementations that actually do this?

	MikaL