Internet DRAFT - draft-bragg-ipv6-multihoming
draft-bragg-ipv6-multihoming
Internet Engineering Task Force Nigel Bragg
Internet Draft Nortel Networks
Document: <draft-bragg-ipv6-multihoming-00.txt> November 2000
Routing support for IPv6 Multi-homing
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document will expire before May 2000. Distribution of this
draft is unlimited.
1. Abstract
The IPv6 Addressing scheme mandates provider addressing to achieve
aggregation. Multi-homing is a fact of life. Current proposals to
reconcile these requirements involve mitigation, by constraining
deployment topologies to avoid loss of aggregation in the backbone
only. This draft views the combined requirement as equivalent to
the use of loose source routing by hosts, and makes some outline
proposals as to how this can be achieved.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
Bragg 1
Routing support for IPv6 Multi-homing November 2000
3. Introduction
The addressing scheme of IPv6 [2] is motivated by the need to
perform the aggressive route aggregation required to keep routing
tables in the default-free zone of the Internet to a manageable
size. This leads to "provider addressing", a consequence of which
is that nodes with multiple connections to the Internet via multiple
Service Providers have multiple addresses, with a global prefix
inherited from each provider's address space.
However, multi-homed nodes must make their selections of address for
communication in ignorance of the actual state of the network. This
can result under fault conditions in a multi-homed node becoming
unreachable by a corresponding node, even though connectivity
exists, which directly contradicts one of the major motivations for
multi-homing.
Other authors eg [3][4], have demonstrated that the "traditional"
solution to this problem is incompatible with the route aggregation
objectives of IPv6, because it requires the explicit exposure of the
prefix of the multi-homed entity in the default-free zone. A
solution is presented in [4]. However, this solution requires a
bilateral agreement between the two Service Providers directly
serving a multi-homed client network; it also leaves the client
critically dependent on one of them. This document describes an
alternative more general solution, which builds on the analysis
given in [3].
4. Problem statement
The problem is illustrated in conjunction with the figure below;
although the scenario illustrated is simple, the proposed solution
generalises to any depth of address space delegation or number of
routes.
TLA1 TLA2
/|\ /|\
| |
| |
NLA1 NLA2
/|\ /|\
\____/
\ /
NLA3
|
H
Any node within NLA3 will inherit two prefixes of the form:
Tx:Nx:N3::/16+nx+n3 (x=1,2, where Tx is the prefix of TLAx, etc)
Bragg 2
Routing support for IPv6 Multi-homing November 2000
Consider the communications of node H with a corresponding node
elsewhere on the Internet. If the path TLA1 to NLA1 fails, the
address of H with the prefix derived from TLA1 becomes unreachable.
If the corresponding node initiates communication using that
address, it can be expected to re-try using the alternative address
(delegated from TLA2, etc) on receipt of an ICMP unreachable
message, and no great harm is done. However, if H initiates
communication, local routing mechanisms within NLA3 will deliver
outbound packets upwards via TLA2, but potentially selecting the
unreachable source address as a result of the mechanisms defined in
[5]; no communication can be established, and H will receive no
indication of the cause, even though it is H's choice of address
that is a contributory factor. If the fault occurs during an
established communication, once again H receives no indication of
the cause of failure, and so no clue as to a viable recovery
strategy.
This proposal addresses these cases, which are at root caused by
node H unwittingly using a valid but unreachable address.
5. Routing-based Solution
The essence of the concept is that each AS advertises its own prefix
as a route downwards through all border routers offering transit
facilities to lower level aggregators, and also propagates down to
lower level aggregators the prefixes of this type received from
higher level aggregator(s). Referring to the figure:
TLA1 advertises T1::/16 to NLA1,
NLA1 advertises T1:N1::/16+n1 and propagates T1::/16 to NLA3,
TLA2 advertises T2::/16 to NLA2,
NLA2 advertises T2:N2::/16+n2 and propagates T2::/16 to NLA3.
This is clearly redundant for upward routing purposes (TLA1 will
advertise ::/0 downwards to subtended NLAs), but the semantic is
subtly different; a recipient of this advertisement can infer that
traffic routed from the general Internet using an address derived
from the received prefix can reach him, which is precisely the
indication we are seeking to provide. Conversely, withdrawal of a
route of this type indicates to the receiving AS that the addresses
inherited as a result of the connectivity represented by that route
are no longer reachable from the Internet at large.
- this is entirely consistent with the IPv6 addressing scheme;
when a multi-homed node selects a Source Address, it is defining
a loose source route for the return path, and this proposal is
ensuring that the status of that return path, over its most
sensitive region, is known
Bragg 3
Routing support for IPv6 Multi-homing November 2000
These routes should not be aggregated by an AS. Within an AS, these
routes are injected into the IGP for distribution. The lack of
aggregation is not seen as a problem, because the number of routes
required in any one AS is only one per aggregator (total, over all
the chains by which the AS inherits its address spaces). Normal
routing mechanisms will then ensure that fault propagation is
minimised. So, if there are two paths from TLA1 to NLA1 in the
earlier figure, and only one fails, the effects are limited to local
recovery (there is still a route from T1::/16, and the address space
inherited from TLA1 is still reachable from TLA1).
So far, the scheme as outlined propagates upward reachability only
throughout the routing network, and has not so far reached the hosts
which must use it in source address selection.
A simple strategy would be to inject and propagate down only the
top-level prefix (Tx::/16), and use this single indicator of
reachability from the general Internet. Defined host auto-
configuration mechanisms [6] allow routers to set the lifetime of
the affected global prefix to zero, thus causing the derived host
addresses to become deprecated.
However, this simple strategy will not yield the most robust
behaviour. Referring to the figure, and recalling that the path
TLA1 to NLA1 has failed, what if the corresponding node is actually
within, or on a network subtended by, NLA1 ? If the corresponding
node is single homed, the address of H derived from the "faulted"
prefix T1::/16 is precisely the one that must be used in
communication (it may of course be that the fault causing the loss
of T1::/16 lies within NLA1, and will actually render communication
impossible, but an assumption of connectivity within NLA1 is the
best chance on offer). The full mechanism described earlier, where
each aggregator in the hierarchy injects a route defined by its own
prefix, would allow a host to handle this condition. This is
described informally below as extensions to the address selection
procedures defined in [5].
TLA1 TLA2
/|\ /|\
| X
| |
NLA1 NLA2
/|\ /|\
\____/ \
\ / \
NLA3 D
|
H
Source Address selection for a Destination D - add initial logic :
Bragg 4
Routing support for IPv6 Multi-homing November 2000
FOR each faulted route to backbone /* ie Tx::/16 prefix withdrawn)*/
IF prefixmatch (D, shortest remaining prefix on that route)
/* the destination D is connected below the fault */
THEN leave Source Address from faulted route in Candidate Set
/* and assume that it will be selected in preference to other
global scope addresses because of longest prefix match */
ELSE remove Source Address from faulted route from Candidate Set
It does not appear that any explicit modifications are required to
the Destination Address selection process. If D is single homed,
the NLA3 routing system must route packets to D via NLA2, and the
source address selection procedure above will provide a usable
return path. If D is itself dual-homed (by a second route not shown
above), the choice of destination address will drive the Source
Address selection appropriately.
In the event that the fault occurs during a session, the host can
use the IP Mobility mechanisms defined in [7] to preserve the
session, by selecting a reachable care-of address.
This scheme is more robust, but requires extension of existing
router-host communication mechanisms. A straightforward approach is
to extend the semantics of the Router Advertisement message's Prefix
Option [6]. Already used for interface auto-configuration, the
Option could be extended to allow prefixes to define reachability as
described above.
6. Security Considerations
Because this scheme uses existing routing protocols, it is not
believed that it raises new security issues in this area. However,
the use of Router Advertisements to convey reachability information
to hosts raises the denial of service threats addressed in [6];
indeed, these are more acute, because ignoring short lifetime
prefixes is not a valid option for reachability information.
Accordingly, use of these mechanisms will require the existence of a
Security Association between router and host as described in [6].
Similarly, the use of IP Mobility mechanisms to maintain existing
connections does not raise any additional security concerns over and
above those described in [7], but does require there to be Security
Associations between the multi-homed host and any destination where
service is to be maintained across a failure
Bragg 5
Routing support for IPv6 Multi-homing November 2000
7. References
1. Bradner, S, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, Harvard University, March 1997
2. R. Hinden, M. O'Dell, S. Deering, "An IPv6 Aggregatable Global
Unicast Address Format", RFC 2374, July 1998
3. F. Dupont, "Multihomed routing domain issues for IPv6
aggregatable scheme", <draft-ietf-ipngwg-multi-isp-00.txt>,
September 1999
4. J. Yu, "IPv6 Multihoming with Route Aggregation", <draft-ietf-
ipngwg-ipv6multihome-with-aggr-01.txt>, August 2000
5. R. Draves, "Default Address Selection for IPv6", <draft-ietf-
ipngwg-default-addr-select-01.txt>, July 2000
6. S. Thomson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998
7. D. Johnson, C. Perkins, "Mobility Support in IPv6", <draft-ietf-
mobileip-ipv6-12.txt>, April 2000
8. Acknowledgments
The use of the Mobility mechanism for maintaining connections was
suggested by Elwyn Davies, Nortel Networks.
9. Author's Addresses
Nigel Bragg
Nortel Networks plc
Harlow Laboratories
London Road
Harlow
Essex CM17 9NA
U.K
Email: nigel.bragg@nortelnetworks.com
Bragg 6
