INTERNET DRAFT                                              C. Huitema
<draft-huitema-multi6-experiment-00.txt>                     Microsoft
June 20, 2003                                               D. Kessens
Expires December 20, 2003                                        Nokia

                   Simple Dual Homing Experiment

Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   The current Internet routing architecture does not provide for a
   scalable multi-homing solution. Scalability of the interdomain
   routing architecture is already a problem and is expected to become
   an even larger problem if millions of home users and small
   businesses will start to use multi-homing technology in order to
   achieve redundancy and reliability that traditionally can only be
   provided by BGP multi-homing.

   Authors believe that it is possible to solve the problems of end-
   users and small businesses with a multi-addressing mechanism and
   source address selection mechanism instead of using the routing

   This draft proposes a setup that will allow us to try a multi-
   addressing solution. Instead of trying to solve the problems for
   more complex network setups, it was decided to go for a solution
   that covers most simple setups but that cover the majority of home
   and small business networks. Authors believe that we can more easily
   reach progress by starting with a simple solution that can later be
   extended to solve the issues of a larger class of users.

   1.   Simple dual homing problem statement

   In order to make progress towards an IPv6 site multi-homing

Huitema & Kessens                                             [Page 1]

INTERNET-DRAFT     Simple Dual Homing Experiment        June 20, 2003

   solution, we propose to start with a simple problem: how to multi-
   home the simplest site, i.e. a site composed of a single link, e.g.
   a switched Ethernet network.

   We believe that addressing the problem of simple, small networks is
   both urgent and useful. Providing a simple solution for the most
   numerous networks drastically reduces the danger that generalized
   multi-homing poses to the Internet. A small network solution may or
   may not be easily extensible to larger networks, but we know that
   there are order of magnitude less large networks than small. If we
   have a solution for the small networks, the scope of the remaining
   problem will "only" be the hundreds of thousands of larger networks,
   rather than the hundreds of millions of home networks.

   Many small business networks use a simple pattern of multi-homing
   today: the very small business network is composed of a switched
   Ethernet, combining fixed line and wireless links; it connects to
   the Internet through two independent connections, such as two DSL
   lines. There is no coordination between the two providers. In a
   typical IPv4 set-up, each Internet connection terminates in a
   different NAT/Firewall; one connection is used as back-up, and is
   turned on if the other connection fails.

   Other examples of this simple multi-homing pattern include home
   networks connected to a broadband service but also maintaining a
   dial-up connection for back-up; and home networks connected to two
   broadband connections such as DSL and cable, or perhaps wireless

   2.   Define a simple set of requirements

   For the small networks, the basic motivation for multi-homing is
   redundancy and reliability. Reliability is defined, as a minimum, as
   the possibility to maintain operation in cases of failure of one the
   Internet provider connections [Black].

   We will expect the site to contain both "simple" and "smart" hosts.
   Simple hosts have an implementation of IPv6 conformant to RFC 2641;
   smart hosts are supposed to be upgraded to become "site multi-homing
   aware". The reliability expectation is slightly different for the
   two kinds of hosts. In case of failure of a provider connection, the
   simple hosts may suffer from a temporary loss of connectivity; the
   expectation is that operation will shortly resume over the remaining
   connection; this matches the expectation of current IPv4 "back-up"
   services. On the contrary, the smart hosts are expected to obtain
   better services: established TCP-IP connections should survive the
   loss of one of the provider connections; if connections cannot be
   maintained, operation should at least resume immediately; it should
   be possible to perform some amount of load balancing between the two

   We assume that it is entirely acceptable that the two Internet

Huitema & Kessens                                             [Page 2]

INTERNET-DRAFT     Simple Dual Homing Experiment        June 20, 2003

   providers each allocate a "provider aggregated" prefix to the small
   site. Simple hosts are expected to auto-configure addresses using at
   least one of these prefixes; smart hosts are expected to auto-
   configure addresses using both. It is reasonable to expect that
   hosts have to be renumbered after a connectivity event, although we
   also expect that addresses configured with one prefix will remain
   valid as long as this prefix is valid.

   The following section details specific problems that must be solved
   by the simple multi-homing solution.

   3.   Multi-homing issues

   The five multi-homing issues that we want to solve are ingress
   filtering, avoidance of a "dead connection" for outbound
   connections, avoidance of a dead address for inbound connections,
   connection maintenance and exit selection. We believe that the
   solution to these problems is in the realm of engineering, not
   research. For each problem, we give hint of one or several possible
   solutions. We also believe that relatively simple solutions are
   possible, and should be preferred to "innovative" constructs.

   3.1. Ingress filtering

   We assume that each of the ISP may perform ingress filtering, and
   will reject packets whose source address does not belong to the
   prefix allocated to the network by that ISP. This leads to a
   possible failure scenario:

   *    Host choose source address A
   *    Default route leads to router B
   *    Router B forwards the packet to ISP B
   *    Packet is dropped by ingress filtering.

   The multi-homing proposal must present a solution to this problem.
   We believe that this solution can be engineered by simple
   improvements in the small site exit routers, such as checking the
   source address of the Internet bound packets and redirecting these
   packets to the "right" exit router in case of problem. This solution
   should not depend on any particular host behavior, beyond what is
   mandated by the existing IPv6 specification, notably Neighbor
   Discovery and Stateless Address Autoconfiguration [RFC2640, RFC2641,
   RFC 2462]. However, smart hosts may improve on the basic solution,
   e.g. by selecting a next hop exit router as a function of the source

   3.2. Avoid using dead router for outbound connections

   The purpose of multi-homing is to provide redundancy, and to avoid
   the following failure scenario:

   *    Router A is dead, or link to ISP A is dead

Huitema & Kessens                                             [Page 3]

INTERNET-DRAFT     Simple Dual Homing Experiment        June 20, 2003

   *    Host continue sending using source address A

   Because of ingress filtering, router B cannot forward the packets
   The multi-homing proposal must present a solution to this problem,
   and the solution must work for both simple hosts and smart hosts. We
   believe that a solution can be engineered by an appropriate use of
   "router announce" messages, such as stopping advertisement of a
   provider prefix if the provider connection is unavailable, or
   possibly advertising this prefix as "deprecated." Smart host may
   improve on that solution by detecting the loss of connectivity
   independently of the router advertisements, and automatically
   preferring the other address for new connections.

   3.3. Avoid using dead address for outbound connections

   A variation of the previous failure scenario occurs when a service
   is hosted on the small network:

   *    Service advertises both address A and address B in the DNS
   *    Router A is dead, or link to ISP A is dead
   *    A remote client selects address A to reach the service
   *    The connection fails

   The multi-homing proposal must present a solution to this problem,
   and the solution must work for both simple hosts and smart hosts. A
   possible solution is to expect remote hosts to retry the connection
   attempt using the second address; another solution is to somehow
   update the DNS.

   3.4. Maintaining connections

   Solving the ingress filtering and dead router problem provides small
   site with a functional multi-homing solution, but does not resolve
   the following failure scenario:

   *    Host has connection with peer P using address A
   *    Router A or ISP A fails
   *    Existing connections break

   Obviously, the desired outcome is that connections should not break.
   However, in a similar IPv4 set-up today, e.g. main connection backed
   up by a DSL line, turning on backup actually breaks connections.
   Thus, we accept the loss of connections in the case of the simple
   hosts; the simple hosts will simply have to reestablish their

   However, the multi-homing proposal should provide smart hosts with a
   solution to this problem. We believe that it is possible to engineer
   this solution by using a variation of Mobile IPv6.

   3.5. Use the right exit/entrance

Huitema & Kessens                                             [Page 4]

INTERNET-DRAFT     Simple Dual Homing Experiment        June 20, 2003

   Even if we are able to provide redundancy and reliability, the dual
   homed networks are still exposed to the following failure mode:

   *    Peer picks address A rather than address B
   *    Resulting traffic is routed on a slower path or on a congested
   *    Performance looks terrible

   The multi-homing proposal should try to provide a solution to this
   problem, and this solution should be available at least to smart
   hosts. This is however not as strong a requirement as the other
   four, as this problem is not solved today in any technology short of
   full blown traffic engineering. In any case, the goal is not to
   obtain an absolute optimization of network usage, but rather to
   avoid the most obnoxious results of load imbalance.

   We believe that it is possible to engineer a solution using either a
   smart naming service (a.k.a. DNS load balancing), a routing level
   optimization such as a randomized choice of exit routers, or
   possibly a variation of Mobile IPv6 to move existing connections
   towards a less loaded path.

   4.   Further study

   The goal of the simple dual homing exercise is to provide a simple
   solution to the simple sites. We expect further revisions of this
   draft to report on the results of actual experiments, to detail how
   proposed solutions fared during these experiments, and to recommend
   those solutions that were found to work well.

   Once this goal is achieved, we believe that the solution can be
   extended in two directions: extend the solution to medium size
   sites; and extend the solution to accommodate a form of provider
   independent addressing.

   The extension to medium size sites can be thought as a progress on a
   scale of complexity: first, extend the solution to multilink
   subnets, where all exit routers are on the same link; second, extend
   the solution to routed network, where all exit routers are on the
   same link; and third, extend the solution to routed network, where
   exit routers are present at different locations.

   Provider independent addressing is often used today by large IPv4
   sites, which simply obtain a prefix form a registry, use this prefix
   for internal addresses, and insure that the prefix is distributed in
   the global routing tables. We believe that similar solutions will be
   available for large IPv6 sites, but we are also very aware that they
   cannot be extended to the majority of smaller IPv6 sites. Yet, the
   small IPv6 sites may benefit from some form of provider independent
   addresses, e.g. in order to advertise addresses that don't depend on
   a particular provider configuration. It may be possible for these
   sites to use a "virtual IP" solution, in which connectivity through

Huitema & Kessens                                             [Page 5]

INTERNET-DRAFT     Simple Dual Homing Experiment        June 20, 2003

   a PI address is overlaid on top of the regular provider based
   addressing. This can be thought of as an extension of the simple

   5.   Security Considerations

   The proposed solution doesn't change anything to the way Internet
   routing works. IP packets with a source address out of a prefix from
   ISP A will leave the exit router on the link that connects to ISP so
   packet spoofing will not be an issue (or at least, this solution
   will not make it worse).

   Smart hosts will not use any mechanisms that will make them more
   vulnerable for attack than simple hosts. Both smart and simple hosts
   are vulnerable to the same security risks that are associated with
   connecting hosts to the Internet and can be addressed with standard
   security technology.

   6.   IANA Considerations

   This document does not request any IANA action.

   7.   Copyright

   The following copyright notice is copied from RFC 2026 [Bradner,
   1996], Section 10.4, and describes the applicable copyright for this

   Copyright (C) The Internet Society March 21, 2001. All Rights

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an

Huitema & Kessens                                             [Page 6]

INTERNET-DRAFT     Simple Dual Homing Experiment        June 20, 2003


   8.   Intellectual Property

   The following notice is copied from RFC 2026 [Bradner, 1996],
   Section 10.4, and describes the position of the IETF concerning
   intellectual property claims made against this document.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use other technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances
   of licenses to be made available, or the result of an attempt made
   to obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification
   can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive

   9.   Acknowledgements

   The multi-addressing idea has been debated multiple times by members
   of the multi6 working group. This draft benefited from detailed
   comments provided by Tony Li and Lode Coene.

   10.  References

   Normative references

   [RFC2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6
   (IPv6) Specification", RFC 2460, December 1998.

   [RFC2460] Deering, S., and R. Hinden, "Internet Protocol, Version 6
   (IPv6) Specification", RFC 2460, December 1998.

   [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
   Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [Black] Benjamin Black, Vijay Gill, Joe Abley, "Goals for IPv6 Site-
   Multihoming Architectures", IETF work in progress, May 2003.

Huitema & Kessens                                             [Page 7]

INTERNET-DRAFT     Simple Dual Homing Experiment        June 20, 2003

   [Bradner] Bradner, S. [ed], "The Internet Standards Process --
   Revision 3", RFC 2026, October 1996

   Informative references

   11.  Authors' Address

   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399


   David Kessens
   313 Fairchild Drive
   Mountain View, CA 94041


Huitema & Kessens                                             [Page 8]

INTERNET-DRAFT     Simple Dual Homing Experiment        June 20, 2003

Table of Contents:

Huitema & Kessens                                             [Page 9]