INTERNET-DRAFT M. Shand
IPv6 Work in Progress Digital Equipment Co. Ltd.
M. Thomas
Digital Equipment Corp.
Expiration Date: Aug. 1996 19 Feb. 1996
Multi-homing Support in IPv6
<draft-shand-ipv6-multi-homing-00.txt>
Status of this Memo
This document is a submission to the IPng Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the ipng@sunroof.eng.sun.com mailing list. This document is not at
this time a product of the IPng Working Group, but a proposal to
become a product of the IPng Working Group.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited.
Abstract
This document defines various forms of multihoming, identifies the
requirements associated with each and suggests means by which they
could be supported in the IPv6 environment. The intention is to
provoke discussion, leading to a general consensus as to which
scenarios and requirements are important, and which potential
solutions are appropriate for further study.
Expires August 1996 [Page 1]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
1. Introduction
The development of the new version of the Internet Protocol, IPv6,
while adhering to many of the architectural principles of IPv4,
nevertheless requires the definition of new pieces of architecture
and this offers the opportunity to provide support for features which
have not been available in IPv4.
One such feature is multihoming. Multihoming is currently a vaguely
defined term. One of the objectives of this paper is to provide some
well understood and agreed taxonomy with which to discuss the
subject. At its simplest, multihoming means a node having multiple
addresses and or multiple interfaces.
There are many existing reasons for requiring multiple addresses on a
host, and the desire to employ multiple interfaces for reasons of
resilience and bandwidth sharing is increasingly common.
In this document we identify the possible topologies and addressing
configurations associated with multihoming, and analyze which of
these are important. Suggested mechanisms by which these
configurations may be supported are then developed.
2. Types of Multihoming
In order to facilitate discussion, a number of different types of
multihoming are identified. Some features are common to multiple
types.
2.1 Type 1 (Single Interface)
This is the simplest form of multihoming. The host has a single
interface, which has multiple IP addresses. Each address may be used
independently.
Transmission of a packet from a type 1 multihomed host requires a
decision about which source address to use and possibly which
destination address (since there may be some correlation between
which address is used to reach a destination and which address the
destination should use for the return traffic).
There are two subtypes associated with this type, depending on the
surrounding network environment.
2.1.1 Type 1a (Equivalent addresses)
In this sub type the multiple addresses are exactly equivalent. i.e.
packets addressed to or from the interface are routed identically
Expires August 1996 [Page 2]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
irrespective of which address is used. In this case the choice of
source address for an initial packet is arbitrary. However for
subsequent packets associated with the same "conversation" (e.g. TCP
connection or UDP exchange) there will most likely be a requirement
to select a source address for a responding packet which is the same
as the destination address of the received packet.
============+=================
|
|A::x,B::y
H
2.1.2 Type 1b (Non-equivalent addresses)
In this sub type the choice of source address may be important even
for an initial packet. For example, if the multiple addresses
correspond to multiple service provider prefixes, then the choice of
source address may reflect the desired service provider. In
particular, it may influence the return destination address, and
hence which service provider is used for the return traffic. It may
be necessary to select different source addresses when establishing
conversations with different destinations. In some cases this may be
to ensure optimal routing. Communication would still be possible if
a different address were chosen. In other case certain sources may
be completely unreachable from certain destinations, and the correct
pairing must be selected before communication is possible.
Provider A Provider B
| |
R1 R2
| |
====+=======+=======+=========
|
|A::x,B::y
H
2.2 Type 2 (Multiple Interfaces - Multiple Addresses)
Here the host has multiple interfaces and each interface has one or
more independent addresses. In its simplest case each interface has
exactly one address, and that simplification will be assumed here for
Expires August 1996 [Page 3]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
clarity. Where there are multiple addresses per interface, the type
1 classification can be applied to each interface in addition to the
type 2 classification described below.
Transmission of a packet from a type 2 multihomed host requires a
decision about which interface to use and also about which address
pair should be used over that interface (although in the simple
single address per interface case the former may imply the latter).
Rather like type 1 multihoming there are two sub-types
2.2.1 Type 2a (Equivalent addresses)
In this sub type each interface has a distinct address, but the
addresses (and hence the interfaces) are exactly equivalent. For
example a host may have multiple interfaces onto the same physical
subnetwork.
============+=======+=========
\ /
A::x \ / B::y
\ /
H
2.2.1.1 Type 2a' (Single Address)
A variant of the above configuration theoretically exists in which
both interfaces have the same IP address (or set of addresses), but
retain distinct link-layer addresses. Note that to deal effectively
with this case would require that neighbor discovery caches allowed
multiple link-layer addresses for a single IP address. However it may
be possible to deal with this sub-type as a special case of type 3
configurations (see below).
The case where the two interfaces have both the same IP address and
the same link-layer address is not interesting. It is essentially a
single dual ported interface.
2.2.2 Type 2b (Non-equivalent addresses)
Here the addresses are not equivalent. The most common example of
this configuration is the case where the multiple interfaces are
connected to different physical subnetworks, and hence the
destination address used when sending a packet to the host determines
which physical interface is used to receive the packet.
Expires August 1996 [Page 4]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
Similarly the source address used when transmitting packets may
determine which interface is used to transmit the packet. (It may be
possible to transmit a packet over interface (a) using the source IP
address associated with interface (b). The result would probably be
that any responding packets would be addressed to, and received over,
interface (b) ).
============+=============
|
|A::x
H
|B::y
|
============+=============
The set of addresses reachable in the rest of the network from the
two interfaces may be:
1. Identical
i.e. any address reachable over interface A is also reachable
over interface B
2. Completely distinct
i.e. any address reachable over interface A is unreachable over
interface B and vice versa.
3. Partially overlapping
Clearly in cases 1 and 3 the reachability may be equivalent, or one
path may be more optimal. Which path is optimal may depend on the
destination address.
Case 2 might arise typically in firewall applications where the two
interface have deliberately been assigned to distinct partitions of
the network.
2.3 Type 3 (High Resilience Multiple Interfaces)
Here the host has multiple interfaces (typically two, although more
are possible) which are functionally equivalent, but have been dupli-
cated for reasons of resilience to failure. A typical configuration
Expires August 1996 [Page 5]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
might be as illustrated below.
========+========+==============+======== LAN1
| | |
| | |
H1 H2 R----------....----D
| | |
| | |
========+========+==============+======== LAN2
Two hosts H1, and H2 are both connected to LAN1 and LAN2. They can
communicate with each other using either LAN1 or LAN2. In the case of
the failure of one LAN (or the interface connecting either host to
that LAN) communication is still possible using the other LAN.
Typically these LANs (often called dual rail LANs) would both be con-
nected to one or more routers, which provide the connection to the
rest of the network and between the LANs. Even if one interface on
each host should fail, such that there is no common LAN, communica-
tion should still be possible via the router(s).
Some other host (D) in some other part of the network may require to
communicate with the multihomed hosts via one or more routers.
The following are common requirements for configurations of this type
(although not all requirements may exist in all situations, and some
requirements may be very difficult, if not impossible to achieve in
practice). It is not the intention that any solution adopted should
necessarily be required to meet all these requirements.
The word "conversation" is used to represent both TCP connections and
multi packet UDP pseudo-connections.
1. Failure of either LAN must not prevent establishment of new
conversations. i.e. they can be established over the alternate
LAN.
2. Failure of either LAN during a conversation must not require the
re-establishment of that conversation. i.e. it must be possible
to move traffic from one LAN to the other without breaking the
connection.
3. A remote host (i.e. D) must not require special knowledge that
Expires August 1996 [Page 6]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
the hosts H1 and H2 are operating in dual rail environment. i.e.
the algorithms for the multihomed and non-multihomed cases must
be the same.
4. When both LAN1 and LAN2 are operational the traffic must be
divided between them. Note that this does not necessarily imply
that traffic for a single conversation must be split (e.g. by
sending alternate packets over each LAN). The load splitting
could be achieved by assigning each conversation to a single
LAN, but distributing the assignments between the two LANs.
Exact load balancing is not required, but it is not acceptable
for one LAN to be approaching saturation, while the other
remains idle.
5. As 4 but path splitting of a single conversation is explicitly
forbidden (perhaps to avoid the possibility of out of order
packet delivery).
6. As 4, but path splitting of a single conversation is required.
7. As 4 and 6, but dynamic load balancing is required. i.e. the
distribution of the packets between the LANs should be dynami-
cally adjusted to maintain approximately equal loading on each
LAN.
8. The traffic is required to be partitioned between the LANs
according to some policy. A typical example might be for a
stock trading system. Under no fault conditions LAN1, is used
exclusively by the live data, and LAN2 is used exclusively for
management and other non-revenue generating traffic. Under
failure conditions, LAN2 is permitted to be used as a backup for
live data, but under no circumstance is LAN1 to be used for
non-revenue earning traffic. Note that requirement of this type
are mutually exclusive with requirements of types 4 to 7.
9. Failover from one LAN to the other must be rapid (of the order
of one second). i.e. the service interruption time must be short
and bounded.
10. Where path splitting or load balancing is a requirement, and
traffic has been moved off a LAN because of failure (or under
Expires August 1996 [Page 7]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
operator request), the traffic must be returned reasonably
quickly (say within a minute) once the LAN is again operational.
3. Some possible solutions
Since the type 3 case is the most interesting and potentially impor-
tant, we will focus on that case. The essential difficulty lies in
the fact that in order to treat the multiple interfaces as completely
equivalent it is necessary to allow data to and from the host to be
received and transmitted over either interface. However, the higher
level protocols use the addressing information associated with each
interface to identify conversation streams. For example TCP includes
the source and destination IP addresses as part of the connection
identifiers. Similar consideration apply to UDP based protocols.
There are essentially three possible approaches to solving this prob-
lem, each of which may exist in multiple variants.
a) Use a single IP address without modification of the TCP/UDP pro-
tocols
b) Use multiple IP addresses, but pass some other identification in
the IP packet to uniquely identify the end point.
c) Use multiple IP addresses, but modify TCP/UDP to deal with them.
We examine these in more detail below.
3.1 Using a single IP address
3.1.1 Multi-lan subnets
The IP (and IPv6) architecture effectively precludes this option.
However it would theoretically be possible to allow a single subnet
to span multiple physical subnetworks. It would be necessary for the
routers attached to those subnetworks to maintain host routes (i.e.
full addresses rather than subnet prefixes) for the multihomed
addresses. To achieve this they would have to perform neighbor
discovery on all the possible physical subnetworks and choose the
interface for forwarding on the basis of which addresses were visible
on which subnetwork. Where necessary they would also have to
exchange host routes with neighboring routers. However the scope of
this exchange could be limited to the immediate location of the
multi-lan subnet. Outside of this domain, the host routes can be
summarized under the subnet prefix.
To allow non-multihomed hosts to operate in this environment without
Expires August 1996 [Page 8]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
modification it would be necessary for the routers to provide proxy
neighbor solicitation responses for those hosts visible only on the
other subnetwork.
A multihomed host could have a conventional single subnet address on
each interface to allow specific per interface addressing, (for exam-
ple to ensure that traffic is confined to a specific subnetwork, or
for diagnostic purposes) in addition to the single address which is
present on both subnetworks.
3.1.2 Routing Hosts
Another alternative is for the multihomed hosts to appear as routers
with the single address present on a private subnet e.g.
============+===================
|
|a::x
(H)- c::z
|b::y
|
============+===================
In this scenario, the private subnet (C::) only exists local to the
host (H). A separate subnet is required for each multihomed host,
since the routing protocols will route all traffic for the subnet to
the associated host.
There are a number of problems with this approach.
a) The host must participate (at least to some extent) in the rout-
ing protocols. At its simplest this would mean sending RIP
advertisements. However the use of RIP as a routing protocol in
this environment doesn't meet the rapid failover requirements. A
more rapidly converging routing protocol, such as OSPF, would be
a major burden on the hosts, and would also increase the com-
plexity of the entire LSA database for the genuine routers.
b) The use of a separate subnet for each multihomed host seems a
profligate waste of addressing space. Although this is much less
of an issue with IPv6 than with IPv4, it still seems undesir-
able.
c) Each multihomed host would still necessitate an entry (for its
Expires August 1996 [Page 9]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
private subnet this time, rather than for its full address, but
there is a one to one correspondence between the two) in the
routing tables. As before these could all be summarized to a
single entry for distribution outside of the dual rail LAN
environment provided the private subnets were suitably struc-
tured.
d) Like the previous proposal, this goes against the conventional
wisdom of the IP architecture (See for example the architectural
assumptions in RFC 1122 Section 1.1.2 (c) quoted below.
"Routing complexity should be in the gateways.
Routing is a complex and difficult problem, and ought be
performed by the gateways, not the hosts. An important
objective is to insulate host software from changes by the
inevitable evolution of the Internet architecture."
3.1.3 Using an anycast address
In some ways the semantics associated with the single address of the
multihomed host resemble those of an anycast address. i.e. the
packet should be delivered at least once to the nearest instance of
the address. It might therefore be possible to use an anycast
address as the destination address of the multihomed node. The scope
of an anycast address can be controlled by its prefix, and is permit-
ted to be wider than a single LAN. However there are the following
problems.
1. The use of an anycast address for host addressing is currently
deprecated. This restriction is only in place until the use of
anycast addresses is more fully understood. It could potentially
be lifted for this use.
2. More seriously the use of anycast addresses as source addresses
is forbidden. This is with good reason, since the anycast
address does not uniquely identify a source of the transmission.
In the case of the normal use of anycast addresses this has the
potential to cause untold confusion, since multiple hosts might
attempt to participate in a single TCP connection. However, in
this specialized context it could be guaranteed that the sources
were indeed the same entity and confusion would not arise. It
might therefore be possible to allow the use of an anycast
address as a source address under these constraints.
Expires August 1996 [Page 10]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
Alternatively it might be possible to define another address
range similar to the anycast range, but with the modified con-
straints.
3. Delivery semantics do not preclude the delivery to multiple own-
ers of the same anycast address. It is not clear how anycast
routing will actually work, but it would clearly be unsatisfac-
tory if all packets were delivered to all interfaces.
4. Anycast addressing would appear to require routing information
to be held for the individual anycast addresses, at least within
the scope of the anycast address. i.e. the routing issues are
the same as with the previous two suggestions.
The subnet prefix chosen for the anycast address could follow one of
two possible models.
1. The anycast subnet prefix could be the same as the natural sub-
net prefix of one of the LANs. In this case traffic on that LAN
would be dealt with normally. On the other LANs, the routers
would have form specific host routes.
2. The anycast subnet prefix could be distinct from any of the
natural subnet prefixes. In this case all the LANs have to
employ host routes. Although requiring slightly more context in
the routers, this model might be preferable since it avoids the
asymmetry inherent in the first model.
3.2 Using multiple IP addresses with a single identifier
Again there are a number of possible variants of this scheme.
a) EIDs (Endpoint Identifiers)
b) use of destination headers
3.2.1 EIDs
This path has been thoroughly explored in the past and rejected, at
least as far as including EIDs in the IPv6 header is concerned. How-
ever it may still be possible to include some equivalent functional-
ity in an extension header. This leads to the next possibility
Expires August 1996 [Page 11]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
3.2.2 Use of destination headers
Note: These ideas are further developed in [BOUND].
3.2.2.1 EID like
It would be possible to include something like an EID in the destina-
tion header. Packets transmitted by the multihomed node would use
the IP address of the interface over which they were transmitted as
their source address, but would include the source 'EID' in the des-
tination header and compute any higher layer checksums as if that
were the source address (rather like the use of the routing header
for destination addresses). The recipient would, on processing the
destination option replace the original source address with the EID
and use that for checksum verification and TCP connection identifica-
tion.
It could also build a mapping between EID and source IP addresses.
When attempting to return a packet addressed by the upper layer to
the EID, it would consult its mapping for the EID, choose one of the
real IP addresses stored for that EID, place that address in the des-
tination address, and place the destination EID in the destination
option.
For communication between two multihomed hosts it would be necessary
to store both the source EID and destination EID in the destination
header. The option would therefore occupy at least 34 bytes, which
is a considerable overhead.
3.2.2.2 Anycast Addresses in destination headers
A variant of the above would be to use an anycast address as the des-
tination address when transmitting to the multihomed node. In pack-
ets transmitted by the multihomed node, the source address would be
the real IP address of the interface used, and the corresponding any-
cast address would be placed in the destination header. Substitution
for checksum and TCP identification would take place as before, but
the anycast address could be used directly as the destination address
of returned packets, without the need to maintain an EID mapping.
This effectively uses the anycast address as an EID which can be
routed.
There is considerable advantage in this approach, since it places the
burden of determining the best destination interface over which to
communicate with the multihomed node on the routing infrastructure.
In approaches which use multiple destination addresses, the burden of
selecting the correct destination address rests with the host.
Expires August 1996 [Page 12]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
3.2.2.3 Security considerations
Both the above schemes have serious security implications, since they
effectively provide a means to change a packet's apparent source
address by inserting a destination header. However, since the
address included in the destination header is the one used for pseu-
doheader construction, it doesn't provide any less security than the
albeit minimal security already existing for conventionally addressed
packets.
3.3 Modifications to TCP
An alternative approach which provides similar functionality to those
outlined above, but within the TCP layer rather than within the IP
layer, is that described in [HUITEMA], to which the reader is
referred for details.
In essence, rather than an EID with global uniqueness scope, a con-
text identifier with only local uniqueness is carried within an
extended TCP packet and used to identify connections. The initiator
proposes extended operation by including its locally unique context
ID. Any packets returned, from whatever address, quoting this con-
text ID will be accepted as belonging to that connection. This
allows the underlying IP addresses to be changed at will without
affecting the connection. For return traffic, the node maintains a
cache of recently seen source addresses associated with the specific
context ID and chooses one of those (using an appropriate algorithm;
least recently used, most recently seen, round robin etc.) for use as
the destination address of the packet.
While this provides an elegant solution to some of the issues sur-
rounding multihoming, as well as renumbering, by its very nature it
is applicable only to TCP. The author makes a good case that TCP
represents the most important case, but there are nevertheless many
UDP based applications which would wish to benefit from the use of
multihoming. NFS is a prime example.
Again, the burden of destination address (and hence interface) selec-
tion rests with the transmitting host.
3.4 Use of Mobile IP techniques
An alternative way of making use of destination option information is
to extend the mobile IP binding update option to be able to contain
multiple addresses. A multihomed node could then send packets using
the source address appropriate to the interface used (another possi-
bility would be to use some other address, but discussion below indi-
cates that using per interface source addresses has some advantages),
Expires August 1996 [Page 13]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
but add a binding update referencing all of its addresses. The
receiving node could then cache this information and use the
addresses in rotation as the destination address of returned packets.
Should the set of operational interfaces (or the addresses on them)
change, then a new binding update could be issues with the updated
information.
As with the other approaches which rely on the host to select
appropriate destination addresses, there is no guarantee that the
multihomed host is reachable use all (or indeed any) of the interface
addresses which it advertises in the binding update. This is dis-
cussed below.
3.5 Selection of destination address by the transmitting host
Just because the multihomed node thinks its interface is operational
doesn't mean that the destination node can actually reach that inter-
face. Indeed it is possible that the multihomed node could success-
fully transmit over a particular interface, but return traffic to
that interface's address would be dropped. This means that all
schemes which rely on the transmitting host to select the appropriate
destination address may attempt to send traffic to the wrong address.
One way around this would be for all nodes (multihomed or not) to
operate a similar scheme to that suggested below for determining the
output interface, but use it for determining the destination address
to use. i.e. if the node failed to make progress with the upper
layer protocol using one destination address it could leave that
address out of the set.
Clearly all schemes which use separate destination addresses for each
interface and rely on the sender to sort out the multiplexing will
suffer from this difficulty. With single destination address
schemes, it is the responsibility of routing to do the path split-
ting, and routing is in a position to determine which interface is
reachable. Especially if the decision is taken locally to the desti-
nation.
{But what about the simple dual railed LAN case. Suppose we have two
MH hosts and a router spanning the LANs. }
4. Selecting the output interface
In any of the above mechanisms it is still necessary for the multi-
homed host to be able to determine the correct output interface over
which to transmit packets. To be able to determine this accurately
Expires August 1996 [Page 14]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
would require the host to participate in the routing algorithms. As
has already been discussed, this is undesirable for the following
reasons
a) it would add significantly to the complexity of the host imple-
mentation, especially since simple routing protocols such as RIP
do not exhibit the required rapid failover characteristics.
b) it would pollute the routing databases of other routers.
However, a good approximation to the desired behavior may be possible
using neighbor discovery, neighbor unreachability detection, and some
heuristics.
The reachability of the destination over the two (or more) interfaces
can be classified as follows:-
a) The destination is reachable over both interfaces, and the two
paths are equivalent. i.e. in routing terms they both exhibit
the same metric value.
b) The destination is reachable over both interfaces, but one exhi-
bits a "better" metric than the other.
c) The destination is only reachable over one interface.
d) The destination is reachable over neither interface.
In case (a) the desired behavior is to split the traffic over both
interfaces. In cases (b) and (c), the traffic should be sent over
the "better" or "only" interface.
It is possible for the reachability to change dynamically and hence
one case may be transformed to another. It is necessary to adapt the
behavior to the new case as soon as possible.
The information which is available from neighbor discovery includes
the state (REACHABLE, INCOMPLETE, STALE, DELAY, PROBE) of the next
hop, and whether or not the next hop is the destination itself (the
isRouter flag).
For the purposes of determining the best path, these indications can
Expires August 1996 [Page 15]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
be ranked as follows, starting with the best
1) REACHABLE, isRouter false (i.e. the destination is directly
reachable on this interface)
2) REACHABLE, isRouter true (i.e. the destination may be reachable
over this interface via a router, which is itself known to be
reachable)
3) STALE, DELAY or PROBE (i.e. the destination was reachable over
this interface, but this needs to be re-verified)
4) INCOMPLETE (i.e. the destination doesn't (yet) appear to be
reachable over this interface).
Transmitted data should be round robinned between all the interfaces
with the highest equal ranking of reachability. No data (except pos-
sibly for probes, see later) should be sent over lower ranking inter-
faces. Note that this is different from the normal case, where data
for stale entries is still sent while the reachability is being re-
verified. In the normal case, the choice is only between sending or
not sending at all, and "to travel hopefully is a better thing than
to arrive" [ R L Stevenson]. However, in the multihomed case, where
we know we have a good path, we would rather concentrate the data on
that path than risk it to a path of dubious viability.
By setting the ReachableTime quite short, it is possible to allow
failing paths to be rapidly detected. Provided the traffic provides
"hints from the upper layers", this need not impose too much of an
overhead.
Note that where the next hop is NOT the destination, neighbor
discovery only provides confirmation (via NUD) that the next hop is
reachable. It does not confirm that the destination is reachable via
that next hop. However the "hints from the upper layer protocols"
that the connection is making forward progress, do confirm that the
destination is reachable, but not necessarily over that interface.
Suppose the data for a connection is being split over two interfaces,
both having a router as the next hop. Alternate packets are sent
over each interface, but the path over interface A always drops the
packet at some point in the path, while the path over interface B
always delivers it. Using a window size of one, packet 1 is sent
over interface A. No acknowledgement is received, so the TCP layer
Expires August 1996 [Page 16]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
retransmits the packet (1), this time over interface B. An ack-
nowledgement IS received for this packet, so packet 2 is now
transmitted over interface A. Again it is dropped, and re-
transmitted successfully over interface B. The connection is indeed
making forward progress (albeit, painfully slowly), but the path over
interface A is invalid. Indeed the same scenario applies if the next
hop router over interface A is broken.
In order to use forward progress as a path validator it is necessary
to tie the forward progress to the packets being sent over that par-
ticular interface. One way of doing this would be to keep a record
of the interface last used for the transmission of each sequence
number, and on receipt of an acknowledgement, only update the vali-
dity of the interfaces which had last transmitted the sequence
numbers covered by the acknowledgement. This requires the saving of
a large amount of state. Hopefully, rather more efficient algorithms
can be found. It might be possible to only initiate the validation
following a packet loss.
However, even assuming such an algorithm existed, this technique is
only suitable for use on TCP connections. An alternative might be to
actively probe the destination (perhaps with ICMP echo packets) over
each interface. This would impose an intolerable overhead on the net-
work, especially since to meet the required failover characteristics,
the probe frequency would have to be of the order of once a second.
Frequently it may be the case that although the next hop router is
reachable, the destination is unreachable from that router. Thus
neighbor reachability information alone is not sufficient to deter-
mine the best interface. If the router knows of a better path, it
will issue a redirect to the better router, however if it has no path
it will issue an ICMP unreachable error message back to the source.
Receipt of an ICMP unreachable message can therefore be used as an
indication that a path is failing and the interface concerned should
be downgraded. Note that the path may not be completely broken. The
unreachable message may just indicate a temporary condition, but in
the absence of any other information it is still probably better to
avoid that interface for a while.
A similar problem to that with forward progress monitoring arises in
this situation, since it is necessary to identify which interface was
used to transmit the failed packet. We cannot use the interface on
which the ICMP error message arrived, since it may well have been
delivered to the "good" interface. Fortunately the ICMP error mes-
sage holds the original packet header, and in particular the IP
source address used for that packet. Therefore (provided a multihom-
ing scheme which uses separate source addresses for the interfaces
has been chosen), the ICMP error message can be accurately associated
Expires August 1996 [Page 17]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
with the appropriate interface.
Although negative acknowledgement via ICMP messages allows some meas-
ure of detection of failed paths, nevertheless is cannot be relied
upon to give perfect notification, since the ICMP packets themselves
may be being lost for some reason. Only the positive acknowledgement
provided by the upper layer protocols can be relied upon to prove
that the packets are being correctly delivered. So where positive
acknowledgement is available it should be used.
Although the above mechanisms distinguish between the case of a
directly reachable destination and one which must be reached via a
router, they do not distinguish between paths which both reach a des-
tination via routers, but which have different metrics. This is prob-
ably unimportant, since it can be assumed that dual rail configura-
tions are generally constructed with a reasonable degree of symmetry.
It might be possible to have a mechanism whereby hosts could solicit
per destination routing metric information from their nearby router,
but this seems fraught with difficulty, not least that of keeping the
information up to date without involving large amounts of stored
state, or frequent message passing.
4.1 Probing for better paths.
When an interface is not being used because it has a lower ranking
than other interfaces, it is still necessary to occasionally poll the
state of that interface for the destination in question, in case the
situation has improved. There are 3 possible levels of polling:
1) Neighbor discovery probing.
2) Sending a duplicate packet over the suspect interface to deter-
mine if an ICMP error report is still generated.
3) Sending a data packet ONLY over that interface to determine if
the connection continues to make progress using that interface.
These should be used in order. Clearly there is no point in sending
any data until the next hop is known to be reachable. Sending a
duplicate packet then allows the new path to be assessed without com-
mitting the integrity of the data stream to that path. Finally the
positive acknowledgement can be obtained by sending a data packet
only over that interface.
An alternative to 2 and 3 would be to use an ICMP echo packet, and
check for the correct reception of the reply. Although this technique
Expires August 1996 [Page 18]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
would be impractical for verifying the continued viability of the
path (as discussed earlier), it may be acceptable in this case since
the frequency of polling need only be of the order of once per
minute.
5. Link Local Addresses
Currently Link Local Addresses have not been considered
6. Security Considerations
These will be addressed as they become apparent.
7. Author's Addresses
Mike Shand
REO2 F-D9
Digital Equipment Co. Ltd.
Digital Park
Imperial Way
Reading
Berkshire
RG2 0TE
UK
Tel: +44 1734 204424
Fax: +44 1734 203133
Email: shand@shand.reo.dec.com
Matt Thomas
Digital Equipment Corporation
550 King Street
Littleton
MA 01460 - 1289
Phone: (508) 486 -5074
Email: matthew.thomas@lkg.dec.com
8. References
[BOUND}
J. Bound, P Roque, "Dynamic Reassignment of IP Addresses for TCP
and UDP"
<draft-ietf-ipv6-dyn-ip-addrs-00.txt>
[HUITEMA]
C. Huitema, "Multi-homed TCP"
<draft-huitema-multi-homed-01.txt>
Expires August 1996 [Page 19]
Internet Draft Multihoming Support in IPv6 19 Feb. 1996
9. Acknowledgements
Many of the ideas contained in this document originated in discus-
sions which took place during the Dallas IETF meeting in December
1995 including (but not limited to) Mike Shand, Matt Thomas, Dan
McDonald, Jack McCann, Jim Bound, Keith Sklower, Thomas Narten.
(End of Draft)
Expires August 1996 [Page 20]