[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                                 J. Palet
Internet-Draft                                                   M. Diaz
Expires: January 10, 2005                                      C. Olvera
                                                                A. Vives
                                                           E. Fleischman
                                                             D. Lanciani
                                                           July 12, 2004

                 Analysis of IPv6 Multihoming Scenarios

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 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://

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

   This Internet-Draft will expire on January 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   Multihoming seems to be one of the key pieces for the deployment of
   IPv6 in the enterprise scenario, but is becoming a frequent

Palet, et al.           Expires January 10, 2005                [Page 1]

Internet-Draft         IPv6 Multihoming Scenarios              July 2004

   requirement in all kinds of networks.  In addition, other factors
   including the deployment of broadband networks, the increase in the
   variety of access technologies, the increase in the demand for
   resilience/redundancy, etc., in non-enterprise environments, for
   example in SOHO/home, necessarily imply the increase of IPv6
   multihoming demand for a number of scenarios, which are described in
   this memo.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Multihoming Motivations  . . . . . . . . . . . . . . . . . . .  3
     2.1   Technical motivations  . . . . . . . . . . . . . . . . . .  3
     2.2   Non-technical motivations  . . . . . . . . . . . . . . . .  4
   3.  Multihoming Scenarios  . . . . . . . . . . . . . . . . . . . .  4
     3.1   Internet Service Provider (ISP)  . . . . . . . . . . . . .  4
     3.2   IX . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.3   Enterprise . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.4   University/Campus  . . . . . . . . . . . . . . . . . . . .  6
     3.5   Security, Defense and Emergency  . . . . . . . . . . . . .  6
     3.6   SOHO and Home  . . . . . . . . . . . . . . . . . . . . . .  7
     3.7   3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.8   Add-hoc  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.9   Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Special Services and Applications within the Multihoming
       Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.1   GRIDs and other temporary networks . . . . . . . . . . . .  9
     4.2   Mobility . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.3   Multihomed devices . . . . . . . . . . . . . . . . . . . .  9
     4.4   Renumbering  . . . . . . . . . . . . . . . . . . . . . . .  9
     4.5   Real Time Traffic  . . . . . . . . . . . . . . . . . . . .  9
     4.6   Specific protocols/applications  . . . . . . . . . . . . . 10
     4.7   Others . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 10
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
       Intellectual Property and Copyright Statements . . . . . . . . 13

Palet, et al.           Expires January 10, 2005                [Page 2]

Internet-Draft         IPv6 Multihoming Scenarios              July 2004

1.  Introduction

   The term multihoming refers to the practice of having a network
   connected to more than one ISP (connectivity provider, transit
   provider, upstream provider, etc.).

   A device can also be multihomed (e.g.  host-centric multihoming),
   when it has more than one interface, and each of the interfaces is
   attached to different networks (may be within a multihomed network).

   In addition to that, in IPv6, each interface can have multiple
   addresses, which also means than even with a single interface, a host
   can be multihomed.

   Multihoming provides certain degree of resilience/redundancy against
   failures (link, hardware, protocols, others) and also enables
   features such as load balancing.  Moreover, multihoming can be used
   in order to differentiate traffic based on policy, for non-technical
   reasons, such as cost associated with different flows, time of the
   day, etc.  For highly distributed enterprises, it can also occur as
   an aid to address that enterprise's geographical distribution, and as
   a traffic engineering mechanism to improve local performance such as
   latency and hop count reductions for real time protocols.

   The scope of this document is to provide a brief description of the
   motivations for multihoming and an analysis of different scenarios
   where IPv6 multihoming could be relevant.

2.  Multihoming Motivations

   Considering the goals for requiring multihoming described in [1], as
   well as other frequent issues, we can classify the motivations as
   both technical and non-technical.

2.1  Technical motivations

   The technical motivations are intended to provide resilience for the
   multihomed networks.

   1.  Redundancy: In order to protect the network against failures.
       These failures could be either in the multihomed network itself,
       or in the upstream (e.g.  provider) network.  The failures can be
       of very different types, including and not limited to: Link
       failures (physical, logical, configuration, ...), hardware
       failures (interfaces, routers, other equipment), protocol
       failures (routing protocol, others).

   2.  Load sharing/balancing: In order to distribute the inbound and/or

Palet, et al.           Expires January 10, 2005                [Page 3]

Internet-Draft         IPv6 Multihoming Scenarios              July 2004

       outbound traffic (e.g.  between multiple providers).

   3.  Performance: As a traffic engineering mechanism to dampen the
       affects of upstream hub congestion through the use of
       "complementary" providers (e.g., in case the local Internet
       Exchanges are congested), avoiding for example, the traffic being
       forwarded thru longer routes than logically required.

   Some of these technical motivations could be partially solved by
   multi-attaching the network to the same ISP (i.e.  load balancing),
   either in the same point-of-presence (POP) or via geographically
   separated POPs.  Resilience can also be increased by using different
   routers, instead of just different interfaces.  But in any case, load
   balancing alone doesn't provide a complete protection from failures
   in the upstream provider.  For this reason, many sites may choose to
   attach to multiple ISPs (i.e.  multihoming) so that a failure within
   the ISP will not necessarily isolate that site from the Internet as a

2.2  Non-technical motivations

   A network can require multihoming for non-technical reasons.
   Financial considerations may influence the deployment, such as
   different cost or fees associated with with different traffic flows
   (with different priorities), or differing costs at different times of
   the day use, destination networks, accumulated bandwidth used, etc.

   Political motivations may exist such as the desire to be able to
   quickly change the provider, without renumbering.  This motivation
   could stem from a wide variety of considerations including service
   charges, improved SLA, ISP bankruptcy, etc.

   Another non-technical motivation, which occurs very frequently in
   some scenarios (e.g.  research and educations networks), is
   acceptable usage policy, where commodity traffic is not accepted, in

3.  Multihoming Scenarios

   Different networking scenarios provide different multihoming cases or
   scenarios, which may have different peculiarities and requirements.
   They are listed below with no specific order or priority.

3.1  Internet Service Provider (ISP)

   An ISP is naturally multihomed when connected to two or more upstream
   providers.  Actually this is a very common case, especially for
   medium and large ISPs.

Palet, et al.           Expires January 10, 2005                [Page 4]

Internet-Draft         IPv6 Multihoming Scenarios              July 2004

   In this scenario, the ISP will usually have its own address pool, in
   a provider independent fashion, allocated from a Regional Internet
   Registry (RIR).  A multihomed ISP uses routing protocols to advertise
   its address space to several upstream providers.

   Some small ISPs only use one upstream provider, so in this case,
   multihoming will not apply.

   The National Research and Education Networks (NRENs) can be
   considered, from the multihoming perspective, as ISPs, because they
   are usually connected to several upstream providers, but they also
   have their own addressing space (allocated from a RIR).

3.2  IX

   Can an IX be multihomed, for example if they are layer 3 transit
   providers, distributed IXs ???.


3.3  Enterprise

   The size of any given enterprise network is a function of the size of
   the corporation it supports.  Enterprise networks can therefore range
   from being small to being enormous.  Larger enterprises may link
   together multiple buildings within a campus, multiple campuses within
   a region, multiple regions within a country, as well as have sites of
   various sizes within multiple countries.  A few corporations even
   have corporate sites located within every country of the world.
   These sites may themselves be linked together via public (e.g., ISP)
   or private (e.g., dark fiber, satellite communications, modem
   connections over telephone networks) means.  A distinction therefore
   needs to be made between a large corporation's private use of public
   (ISP) networking facilities to privately link together disparate
   parts of that corporation and that same corporation's public POPs to
   the worldwide Internet.  The former is solely known (or, at least, it
   should be solely known) to the corporation and the supplier, the
   latter is advertised to the worldwide Internet infrastructure as the
   standard mechanism by which that corporation can be accessed.  This
   distinction is important because the security mechanisms protecting
   these different uses (e.g., firewalls) are often very distinct from
   each other.

   Medium and large corporations are frequently attached to several
   ISPs, often for multihoming and load balancing reasons.  Highly
   distributed corporations often have additional motivations for
   connectivity to multiple ISPs stemming from traffic engineering and
   performance considerations, particularly if real time traffic (e.g.

Palet, et al.           Expires January 10, 2005                [Page 5]

Internet-Draft         IPv6 Multihoming Scenarios              July 2004

   VoIP) is being internally supported.

   This kind of networks usually require a high resilience, because any
   outage, even when minimal, could mean a very high cost, that could
   justify the adoption of a multihoming solution even if this is

   Medium and small enterprise networks could fall in the category of
   Enterprise or in the SOHO one, which is very dependent on the
   specific resilience requirements.

3.4  University/Campus

   In principle, it seems that a University or Campus network fits in
   the same category as the enterprise network, except that its policies
   and security systems are very different, particularly because the
   university will not go out of business if the information contained
   within its computers becomes compromised.

   Is also important to recognize one more special non-technical
   requirement.  Often they are connected in addition to commercial ISPs
   to non-commercial ISPs (NRENs), which don't allow commodity traffic,
   and consequently the network must control traffic based on policy.

3.5  Security, Defense and Emergency

   Military networks differ from university and corporate networks in
   that their computers and the networks themselves operate at specific
   classification levels.  In military jargon, these are known as "Red
   networks".  Each red network instance operates at a specific
   classification level (e.g., secret, sensitive-but-unclassified,
   etc.).  Red networks operating at different classification levels may
   have disjoint (i.e., unrelated) address spaces from each other.  In
   some military environments, Red networks are conveyed over physical
   media that can be protected.  This is in contrast to Black networks,
   whose media cannot be similarly protected (e.g., wireless
   transmissions).  Packets from Red networks may be conveyed over Black
   networks if the Red packets are first encrypted.  In some cases, the
   encrypted Red packet may be encapsulated within an appropriate IP
   header of the Black network.

   But from the multihoming perspective, in principle, it seems that
   security and military networks fit into the same category as the
   enterprise network (for instance, as different networks for the Red
   and Black ones, and both could be also multihomed).

   This is also the case for civil and emergency networks, for example
   those used in airports, or by police/law enforcement, fireman, health

Palet, et al.           Expires January 10, 2005                [Page 6]

Internet-Draft         IPv6 Multihoming Scenarios              July 2004

   care, etc.  and specially in the avenue of catastrophic events.

   The importance of multihoming here is related to the need of high
   reliability, because the failure could potentially increase the risk
   for human life.

3.6  SOHO and Home

   A Small Office/Home Office or Home, can fall into the category of a
   managed or unmanaged network.  Usually there is a minimum management
   of the network, that could be done in-house, or as part of the
   service provided by the ISP, external consultants or systems

   Is becoming very frequent the case where different ISPs provide
   service to the same SOHO/Home network, by means of different access
   networks (xDSL, Cable, Wireless, PLC/BPL, etc.).

   A SOHO/Home network was usually a very small network with a single
   subnet, but this is also rapidly changing, and several subnets will
   be more frequently present in this scenario.

   Some times this network can be part of an enterprise network, and
   consequently managed, usually connected via a VPN to the corporate
   network, so in this case, the multihoming could depend on the VPN
   access itself.  But is also the case when different hosts or
   different applications need to chose either the VPN (for example
   email or corporate applications), or the ISP (for example regular web
   access); in this case the multihoming case is the same as in the
   enterprise network scenario (the VPN behaves as a separate ISP).

   Today, the complete resilience of this network is already required,
   even if the solution cost is usually still too high.  We can envision
   that the requirement for multihoming will become more frequent,
   specially considering the increase of tele-work and the usage of
   Internet for voice and video applications.

   So the SOHO/Home network is positioned to enjoy the greatest benefit
   from multihoming.  Although those networks typically do not have
   access to "enterprise-class" links with guaranteed uptime (or any
   guarantee at all) it is not uncommon for multiple providers to offer
   technologically diverse residential services in a single area.
   Multihoming to two or more such services (e.g., DSL, cable,
   satellite, BPL/PLC, etc.) can dramatically increase the resistance of
   a SOHO/Home network to external single points of failure.  Resilience
   in those networks is becoming an important issue in the face of
   residential VoIP deployment.  While it is unlikely that an enterprise
   environment will be without any conventional phone lines in the near

Palet, et al.           Expires January 10, 2005                [Page 7]

Internet-Draft         IPv6 Multihoming Scenarios              July 2004

   future, residential consumers are already experimenting with
   Internet-only phone service.  It will become critical to deliver
   reliability approaching that of conventional phone lines if we are to
   maintain E911 service, fire alarm monitoring, and similar life safety
   functions at their current levels of effectiveness.  While such
   reliability may be delivered by a single provider in select areas,
   multihoming should allow a larger set of consumers to set and meet
   their own standards through multiple attachment.

   SOHO/Home networks may ultimately support life safety functions
   (e.g., health care, detectors, surveillance, etc.).  The required
   reliability to monitor a smoke detector while a family sleeps is as
   least as great as that required by an enterprise where the most
   serious consequence of a network failure is likely financial.

   In some cases, a host-centric multihoming approach could be
   sufficient for this scenario.  This could be the case when single
   devices are directly connected to several access networks, for
   example for safety or security reasons.

3.7  3GPP

   Is this the same as the mobility case ???.

   Can a GGSN be multi-homed ???.

   As IPv6 allows to have multiple addresses in each interface, the 3GPP
   terminal with a single interface can be multihomed using multiple
   IPv6 addresses with a single radio connection.  Furthermore some 3GPP
   terminals are available with more than one interface (3GPP and WLAN)
   can be multihomed using one or several IP addresses in each

   Similarly, a GGSN can have multiple IPv6 addresses per interface and
   several upstream links.

3.8  Add-hoc

   is this a special case ???.  what about managed ad-hoc networks for
   the military domain ?

3.9  Mesh

   Mesh networks are those that use its nodes as routers so that every
   node does not have to hear every other node directly (as in the
   classic ad-hoc case).  It is more likely in this case that the entire
   network may touch more than one "external" provider, and consequently
   is multihomed.

Palet, et al.           Expires January 10, 2005                [Page 8]

Internet-Draft         IPv6 Multihoming Scenarios              July 2004

4.  Special Services and Applications within the Multihoming Scenarios

   In addition to the generic scenarios, there are some special
   situations, services or applications, that could be parallel to any
   of the previously described cases, and should be considered in order
   to have a complete perspective for each of the above mentioned

4.1  GRIDs and other temporary networks

   An organization with his own network and addressing being connected
   to a bigger network, for example in a GRID situation, in a temporary
   or quasi-permanent basis.  This can be also the example for research
   institutions that often connect their networks to other networks and
   may receive new addressing space creating a multi-homing situation.

4.2  Mobility

   A mobile host or a mobile network can be simultaneously moving and
   still be attached to more than just one ISP.  For example when
   connected simultaneously to a GPRS or 3GPP networks and a WISP (WLAN

   Much more text needed here !.

4.3  Multihomed devices

   Cellular phones with for example 3GPP and WLAN interfaces, laptops
   with 3GPP and Ethernet or even WLAN, all those are good examples of
   multihomed devices.  This seems to be same as the host-centric
   multihoming case, but could also be related to the mobility scenario.

4.4  Renumbering

   When a network is being renumbered, temporarily, during the
   renumbering process itself, it may become a multihomed network.

4.5  Real Time Traffic

   The increase of the usage data networks and Internet for real time
   traffic (VoIP, video/audio streaming, videoconferencing, etc.).

   For example, the impact of the penetration of VoIP for residential
   usage (SOHO, home), could bring situations where the conventional
   phone lines disappear, while several access networks connect those
   sites.  In this case, multihoming is much more critical to maintain
   the level of service required for emergency (e.g.  E911, medical,
   security, ...) and similar life facilities that today depend on the

Palet, et al.           Expires January 10, 2005                [Page 9]

Internet-Draft         IPv6 Multihoming Scenarios              July 2004


   This is also specially relevant for rural areas, which today don't
   have copper connectivity, but are already attached to Internet by
   other means (satellite, PLC, WLAN, etc.).

   Of course this could be also true for other kind of networks, like
   enterprise, emergency, etc.

4.6  Specific protocols/applications

   Content Delivery Networks (CDNs), Internet Data Centers (IDC), DNS,
   DHCP, RA, ????.


4.7  Others

   any ??? TBD.

5.  Security Considerations

   This memo does not generate any new security considerations.

6.  IANA Considerations

   This document requests no action for IANA.

   [[Note to RFC-editor: this section can be removed upon publication.]]

7.  Acknowledgements

   The authors would like to acknowledge the inputs from Jim Bound,
   Munechika Sumikawa, Antonio Tapiador, and the European Commission
   support in the co-funding of the Euro6IX project, where this work is
   being developed.

8  Informative References

   [1]  Abley, J., Black, B. and V. Gill, "Goals for IPv6
        Site-Multihoming Architectures", RFC 3582, August 2003.

Palet, et al.           Expires January 10, 2005               [Page 10]

Internet-Draft         IPv6 Multihoming Scenarios              July 2004

Authors' Addresses

   Jordi Palet Martinez
   San Jose Artesano, 1
   Alcobendas - Madrid
   E-28108 - Spain

   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   EMail: jordi.palet@consulintel.es

   Miguel Angel Diaz Fernandez
   San Jose Artesano, 1
   Alcobendas - Madrid
   E-28108 - Spain

   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   EMail: miguelangel.diaz@consulintel.es

   Cesar Olvera
   San Jose Artesano, 1
   Alcobendas - Madrid
   E-28108 - Spain

   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   EMail: cesar.olvera@consulintel.es

   Alvaro Vives Martinez
   San Jose Artesano, 1
   Alcobendas - Madrid
   E-28108 - Spain

   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   EMail: alvaro.vives@consulintel.es

Palet, et al.           Expires January 10, 2005               [Page 11]

Internet-Draft         IPv6 Multihoming Scenarios              July 2004

   Eric Fleischman

   EMail: eric.fleischman@boeing.com

   Dan Lanciani

   EMail: ddl@danlan.com

Palet, et al.           Expires January 10, 2005               [Page 12]

Internet-Draft         IPv6 Multihoming Scenarios              July 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at

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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Palet, et al.           Expires January 10, 2005               [Page 13]

Html markup produced by rfcmarkup 1.120, available from https://tools.ietf.org/tools/rfcmarkup/