[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                      C. de Launois
Internet-Draft                                            O. Bonaventure
Expires: November 13, 2003                                      UCL/INGI
                                                            May 15, 2003


     NAROS : Host-Centric IPv6 Multihoming with Traffic Engineering
                  draft-de-launois-multi6-naros-00.txt

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 Internet-Draft will expire on November 13, 2003.

Copyright Notice

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

Abstract

   More and more ISPs are multihomed and need to engineer their
   interdomain traffic.  Unfortunately, both multihoming and traffic
   engineering contribute to the growth of the BGP routing tables.  For
   IPv6, a better solution for multihoming and traffic engineering is
   required.  This document proposes a host-centric IPv6 multihoming
   solution that relies on the utilization of a "Name, Address and ROute
   System" (NAROS) server.  A key advantage of using this server is that
   it allows a multihomed site to engineer its interdomain traffic
   without transmitting any BGP message.





de Launois & Bonaventure    Expires November 13, 2003           [Page 1]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.    Multihoming Issues . . . . . . . . . . . . . . . . . . . . .  3
   2.1   Fault Tolerance  . . . . . . . . . . . . . . . . . . . . . .  4
   2.2   Route Aggregation  . . . . . . . . . . . . . . . . . . . . .  4
   2.3   Source Address Selection . . . . . . . . . . . . . . . . . .  4
   2.4   Destination Address Selection  . . . . . . . . . . . . . . .  4
   2.5   Traffic Engineering  . . . . . . . . . . . . . . . . . . . .  4
   2.6   ISP Independence . . . . . . . . . . . . . . . . . . . . . .  4

   3.    The NAROS Service  . . . . . . . . . . . . . . . . . . . . .  5
   3.1   Source Address Selection . . . . . . . . . . . . . . . . . .  6
   3.2   Destination Address Selection  . . . . . . . . . . . . . . .  7
   3.3   Fault Tolerance  . . . . . . . . . . . . . . . . . . . . . .  8
   3.4   Interdomain Traffic Engineering  . . . . . . . . . . . . . .  9

   4.    The NAROS protocol . . . . . . . . . . . . . . . . . . . . . 10
   4.1   Specification of Requirements  . . . . . . . . . . . . . . . 10
   4.2   Message Types  . . . . . . . . . . . . . . . . . . . . . . . 10
   4.2.1 NAROS_REQUEST  . . . . . . . . . . . . . . . . . . . . . . . 11
   4.2.2 NAROS_RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 12
   4.2.3 NAROS_ERROR_RESPONSE . . . . . . . . . . . . . . . . . . . . 13

   5.    Security Considerations  . . . . . . . . . . . . . . . . . . 13

   6.    Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14

   7.    Appendix A : NAROS Error Numbers . . . . . . . . . . . . . . 14

         References . . . . . . . . . . . . . . . . . . . . . . . . . 15

         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17

         Intellectual Property and Copyright Statements . . . . . . . 18















de Launois & Bonaventure    Expires November 13, 2003           [Page 2]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


1. Introduction

   The size of BGP routing tables in the Internet has been growing
   dramatically during the last years.  Their size has risen from 70,000
   entries in january 2000 to about 140,000 at the beginning of 2003
   [19].  The current size of those tables creates operational issues
   for some Internet Service Providers and several experts [1] are
   concerned about the increasing risk of instability of BGP.

   Part of the growth of the BGP routing tables is due to the fact that,
   for economical and technical reasons, many ISPs and corporate
   networks wish to be connected via at least two providers to the
   Internet.  Nowadays, at least 60% of those networks domains are
   connected to two or more providers [2].  Other factors include
   address fragmentation or failure to aggregate [3].  Once multihomed,
   a domain will usually want to engineer its interdomain traffic to
   reduce its Internet bill.  Unfortunately, the available interdomain
   traffic engineering techniques [4] are currently based on the
   manipulation of BGP attributes which contributes to the growth and
   the instability of the BGP routing tables.

   Although several solutions to the IPv6 multihoming problem have been
   discussed within the multi6 working group of IETF, few have addressed
   the need for interdomain traffic engineering.

   The NAROS approach presented in this document is a host-centric IPv6
   multihoming solution which allows sites to engineer their incoming
   and outgoing interdomain traffic without any manipulation of BGP
   messages.  It relies on the utilization of several IPv6 addresses per
   host, one from each provider.  The basic principle of NAROS is that
   before transmitting packets, hosts contact the NAROS service to
   determine which IPv6 source address they should use to reach a given
   destination.

   In the second section, we briefly present the technical and
   economical reasons for multihoming in the Internet.  In the third
   section, we describe the NAROS architecture and explain how it
   supports multihoming and traffic engineering.  In the fourth section,
   the NAROS messages formats are detailed.  Finally, security
   considerations are discussed in the fifth section.

2. Multihoming Issues

   IPv6 multihoming solutions are significantly different from IPv4 ones
   because they must allow the routing system to better scale.  Morever,
   the IPv6 address space is much larger, which gives more freedom when
   designing multihoming.  An IPv6 host may have several global
   addresses.  Paradoxically this can help in reducing the BGP table



de Launois & Bonaventure    Expires November 13, 2003           [Page 3]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


   sizes but it requires that hosts correctly handle multiple addresses.
   Requirements for IPv6 multihoming are stronger and multiple [5].  In
   this document, we essentially focus on the following requirements.

2.1 Fault Tolerance

   Sites connect to several providers mainly to get fault tolerance.  A
   multihoming solution should be able to insulate the site from both
   link and ISP failures.

2.2 Route Aggregation

   Every IPv6 multihoming solution is required to allow route
   aggregation at the level of their providers [1], [5].  This is
   essential for the scalability of the interdomain routing system.

2.3 Source Address Selection

   A multihomed IPv6 host may have several addresses, assigned by
   different providers.  When selecting the source address of a packet
   to be sent, a host could in theory pick any of these addresses.
   However, for security reasons, most providers refuse to convey
   packets with source addresses outside their address range [6].  So,
   the source address selected by a host also determines the upstream
   provider used to convey the packet.  This has a direct impact on
   traffic engineering.  Moreover, if a host selects a source address
   belonging to a failed provider, the packet will never reach its
   destination.  Thus, a mechanism must be used to select the most
   appropriate source address.

2.4 Destination Address Selection

   When a host in the Internet contacts a multihomed host, it must
   determine which destination address to use.  The destination address
   also determines the provider used.  If a provider of the multihomed
   site is not available, the corresponding destination address cannot
   be used to reach the host.  So we must make sure that an appropriate
   destination address is always selected.

2.5 Traffic Engineering

   A multihomed site should be able to control the amount of inbound and
   outbound traffic exchanged with its providers.  It should also be
   able to prefer one provider over others for some routes.

2.6 ISP Independence

   It is desirable that a multihoming solution can be set up



de Launois & Bonaventure    Expires November 13, 2003           [Page 4]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


   independently without requiring cooperation of the providers.

3. The NAROS Service

   Figure 1 illustrates a standard multihomed site.  Suppose three
   Internet Service Providers (ISPA, ISPB and ISPC) provide connectivity
   to the multihomed site.  The site exit router connecting with ISPA
   (resp.  ISPB and ISPC) is RA (resp.  RB and RC).  Each ISP assigns a
   site prefix to the multihomed site.  The prefixes are then used to
   derive one IPv6 address per provider for each host interface.

            _____________________________________________
           |                                             |
           |    Host W        Internet                   |
           |_____________________________________________|
                  |              |             |
                __|_           __|_           _|__
               |    |         |    |         |    |
               |ISPA|         |ISPB|         |ISPC|
               |____|         |____|         |____|
                  |              |             |
                __|______________|_____________|_____
               |  |              |             |     |
               | RA             RB             RC    |
               |  |______________|_____________|_    |
               |    |         |         |        |   |
               |  NAROS    Host X     Host Y   NAROS |
               |           PA:SA:X    PA:SA:Y        |
               |           PB:SB:X    PB:SB:Y        |
               |           PC:SC:X    PC:SC:Y        |
               |                                     |
               |            Multihomed site          |
               |_____________________________________|

                                Figure 1

   In the NAROS architecture, the site sends packets with ISPA addresses
   only to ISPA, and ISPA only announces its own IPv6 aggregate to the
   global Internet.

   Since each host has several IPv6 addresses, it must decide which
   address to use when transmitting packets.  The basic principle of our
   solution is to let the NAROS service manage the selection of the
   source addresses.  This address selection will influence how the
   traffic flows through the upstream providers and a good selection
   method will allow the site to engineer its interdomain traffic.

   We now consider in details how the NAROS service addresses four main



de Launois & Bonaventure    Expires November 13, 2003           [Page 5]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


   issues : source and destination address selection, fault-tolerance
   and traffic engineering.

3.1 Source Address Selection

   When a host initiates a connection with a correspondent, it must
   determine the best source address to use among its available
   addresses.  The source address selection algorithm described in [7]
   already provides a way to select an appropriate address.  However,
   this selection is arbitrary when a host has several global-scope IPv6
   addresses as in the host-centric multihoming case.

   The principle that we propose is that the host asks the NAROS service
   which source address to use.  It complements in this way the default
   IPv6 source address selection algorithm [7].

   In its simplest form, the basic NAROS service is independent from any
   other service.  A NAROS server does not maintain state about the
   internal hosts.  It is thus possible to deploy several NAROS servers
   in anycast mode inside a site for redundancy or load-balancing
   reasons.  A NAROS server can also be installed on routers such as the
   site exit routers.  The NAROS protocol can run over UDP, as it is
   described in this document.  It can also run over another protocol
   like ICMPv6 [8].  The NAROS protocol contains only two messages :
   NAROS request and NAROS response.

   The first message is used by a client to request which source address
   to use to reach a given destination.  The parameters included in a
   NAROS request are at least the destination address of the
   correspondent and the source addresses currently allocated to the
   client.  The NAROS server should only be contacted when the default
   source address selection procedure [7] cannot select the source
   address.

   The NAROS response message is sent by a NAROS server and contains the
   source address to be used by the client.  The parameters include at
   least the selected best source address, a prefix and a lifetime.  It
   tells that the client can use the selected source address to contact
   any destination address matching the prefix.  These parameters remain
   valid and can be cached by the client during the announced lifetime.

   Each host knows from its configuration the address of the NAROS
   server.  This address can be an anycast address.








de Launois & Bonaventure    Expires November 13, 2003           [Page 6]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


            Host X              NAROS Server     RA RB RC  Host W
   connect.req |                     |            |  |  |   |
   ----------->| NAROS.req(PW:SW:W,  |            |  |  |   |
               |   src=PA:SA:X, PB:SB:X, PC:SC:X) |  |  |   |
               |-------------------->|            |  |  |   |
   Best        |                     |            |  |  |   |
   src=PA:SA:X |<--------------------|            |  |  |   |
   <-----------| NAROS.resp(Pfx=PW,  |            |  |  |   |
               |   Lifetime=300,     |            |  |  |   |
               |   Best src=PA:SA:X) |            |  |  |   |
               |                     |            |  |  |   |
               |---------------------------------.|  |  |   |
               |                     |            `-------->|connect.ind
               |                     |            |  |  |   |---------->

                                Figure 2

   Figure 2 shows an example of how the NAROS messages and parameters
   are used.  The exact format of the NAROS message is described in
   Section 4.2.  When Host X sends its first packet to remote Host W
   (PW:SW:W), it issues a NAROS request in order to obtain the source
   address to use to reach Host W.  Upon receipt of the request, the
   NAROS server identifies the prefix PW associated with Host W and
   selects for example PA:SA:X as the best source address.  The prefix
   can be determined arbitrarily, e.g.  using the /48 prefix
   corresponding to the destination address.  Another solution is to
   extract from a BGP table the prefix associated with the destination.
   The server then indicates the lifetime (e.g.  300 seconds) of these
   parameters in the NAROS response message.

   After having processed the reply, Host X knows that it can use
   PA:SA:X to reach any destination inside prefix PW, including Host W.
   The selected source address should be used for the whole duration of
   the flow, in order to preserve the connection.  If new TCP
   connections or UDP flows to the same destination are initiated before
   the announced lifetime expires, the client can use the cached
   parameter.  Otherwise the host must issue a new NAROS request and it
   may get a different source address for the same destination.  By
   using appropriate values for the lifetime and the prefix in the NAROS
   response, it is possible to reduce the number of NAROS requests sent
   by hosts.

   A simulation of the influence of various NAROS parameters and the
   number of messages exchanged may be found in [9].

3.2 Destination Address Selection

   A second case is when Host W on the Internet needs to contact Host X



de Launois & Bonaventure    Expires November 13, 2003           [Page 7]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


   in the multihomed site.  It first issues a DNS request.  The DNS
   server of the multihomed site could reply with all the addresses
   associated to Host X.  At worst, Host W will try the proposed
   addresses one by one.  Eventually, a connection will work.  A better
   solution to this problem would be to integrate an extended NAROS
   service with the DNS server to choose the address to be returned.
   This choice could depend on the source of the DNS request, a policy
   defined by the administrator, or the traffic engineering
   requirements.

3.3 Fault Tolerance

   A third problem to consider is what happens when one of the upstream
   providers fails.  As in the solution described in [10], [11], the
   site exit routers use router advertisement messages to communicate to
   hosts the available prefixes [12], [13].  When a provider crashes,
   the site exit router connected to this provider detects the event and
   advertises a null preferred lifetime for that prefix.  A client can
   take this event into account by immediately asking new parameters to
   the NAROS server.  More generally, a host can ask updated parameters
   each time it detects a failure which affects one of its
   communications.  Once the new source address is known, HIP [14], SCTP
   [15], IP mobility [16] or other mechanisms [17] can be used in order
   to preserve the established TCP connections in case of ISP failure.

            Host X              NAROS Server     RA RB RC  Host W
               |                     |            |  |  |   |
               |          RA.use-prefix(PA:SA,    |  |  |   |   ISPA
               |            preferred lifetime=0) |  |  |   |  Failure
               |                     |<-----------|  |  |   |
               |<---------------------------------|  |  |   |
     Failure   |                     |            |  |  |   |
     Detected  |                     |            |  |  |   |
   ----------->| NAROS.req(dst=PW:SW:W,           |  |  |   |
               |   src=PA:SA:X, PB:SB:X, PC:SC:X) |  |  |   |
               |-------------------->|            |  |  |   |
   Best        |                     |            |  |  |   |
   src=PC:SC:X |<--------------------|            |  |  |   |
   <-----------| NAROS.resp(Pfx=PW,  |            |  |  |   |
               |   Lifetime=300,     |            |  |  |   |
               |   Best src=PC:SC:X) |            |  |  |   |
               |                     |            |  |  |   |

                                Figure 3

   In Figure 3, consider for example that ISPA becomes unavailable.  The
   site exit router connected to ISPA detects the failure and advertises
   a null preferred lifetime for prefix PA.  The NAROS server



de Launois & Bonaventure    Expires November 13, 2003           [Page 8]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


   immediately takes this advertisement into account and future NAROS
   replies will not contain this prefix.  Host X will also receive this
   advertisement.  The standard effect is that it should no longer use
   this source address for new TCP or UDP flows.  If Host X is currently
   using a deprecated address, it can issue a new NAROS request to
   choose among its other available source addresses.  The host can then
   use IP mobility mechanisms to switch to the new source address in
   order to maintain its connection alive.

3.4 Interdomain Traffic Engineering

   When a host selects a source address, it also selects the provider
   through which the packets will be sent.  Since the source address to
   use is selected by the NAROS service, this can naturally be used to
   perform traffic engineering.

   For example, in order to equally balance the traffic among the three
   providers in Figure 1, a NAROS server can use a round-robin approach.
   Each time it receives a NAROS request, the server selects another
   provider and replies with the corresponding source address.  Except
   when a provider fails, this source address, and thus the upstream
   provider, remains the same for the whole duration of the flow.  Note
   that this solution allows traffic engineering without injecting any
   information in the internet routing system.  Moreover, the NAROS
   service can easily support unequal load distribution, without any
   additionnal complexity.

              ___________       __________________________
             |           |     |                          |
             |   ISPA    |     |         Internet         |
             |___________|     |__________________________|
               |       |            __|_           _|__
       ________|_      |           |    |         |    |
      |          |     |           |ISPB|         |ISPC|
      | Research |     |           |____|         |____|
      | Network  |     |              |             |
      |__________|     | cheap        | Normal      | Expensive
                     __|______________|_____________|_____
                    |  |              |             |     |
                    | RA             RB             RC    |
                    |  |______________|_____________|_    |
                    |    |         |         |        |   |
                    |  NAROS    Host X     Host Y   NAROS |
                    |                                     |
                    |           Multihomed site           |
                    |_____________________________________|

                                Figure 4



de Launois & Bonaventure    Expires November 13, 2003           [Page 9]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


   Another example is illustrated in Figure 4.  ISPA only provides
   connectivity between the multihomed site and a research network.  The
   link to ISPA is cheap while the link to ISPC is expensive.  In this
   example, a NAROS server can select ISPA for the research traffic, and
   balance the Internet traffic between ISPB and ISPC with a higher
   preference for ISPB.

   Beside the above functionalities, the NAROS approach has several
   advantages.  First, no coordination is needed between the providers
   of the multihomed site.  A provider only delegates a prefix to the
   site.  This makes the solution applicable even for small sites which
   cannot afford provider-independent addresses.  Moreover, the
   multihomed site is able to engineer its traffic without any agreement
   with its providers.  Finally, since routes to addresses delegated by
   one provider are not announced to other providers, full route
   aggregation is possible, at the price of multiple addresses per
   hosts.

4. The NAROS protocol

4.1 Specification of Requirements

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "SHALL", "SHALL NOT", "MAY" and "MAY NOT" that appear in this section
   of this document are to be interpreted as described in [18].

4.2 Message Types

   NAROS messages consist of two mandatory fields, Version and Message
   Type, followed by one or more required parameters.  Message format is
   shown below :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |  Message Type |         Reserved = 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Parameters ...
   +-+-+-+-+-+-+-+-+-+-+

   The version field is a single byte that specifies the NAROS version
   number that is being used.  The current NAROS version number is 1.

   The message type field is a single byte and specifies the message
   contained in the current packet.  A NAROS message MUST NOT be longer
   than 4096 bytes and there may be only one message per packet.

   Defined message types are :



de Launois & Bonaventure    Expires November 13, 2003          [Page 10]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


    Value   Message
   --------------------------------------------------
      1     NAROS_REQUEST           Host   -> Server
      2     NAROS_RESPONSE          Server -> Host
      3     NAROS_ERROR_RESPONSE    Server -> Host


4.2.1 NAROS_REQUEST

   A NAROS_REQUEST is sent by a NAROS client to request its connection
   parameters.  The format of the message is :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Version = 1  | Msg type = 1  |         Reserved = 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Identifier                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                    Destination Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                  Available Source Address                     +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :              Other Available Source Addresses ...             :
   :                                                               :

   The Identifier field uniquely identifies the NAROS request.  The
   Destination Address field is the address of the destination host that
   the client wants to contact.  The Available Source Address fields are
   the source addresses currently allocated to the client.

   When selecting a source address, the client MUST first use the source
   address selection algorithm as defined in [7].  However, the 8th
   rule, i.e.  use longest matching prefix, MUST be superseded by the
   NAROS source address selection procedure.  A NAROS_REQUEST message



de Launois & Bonaventure    Expires November 13, 2003          [Page 11]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


   MUST be sent by the client when it initiates a communication with a
   remote host for the first time.  The client MUST specify in the
   message all the source addresses it is able to use to reach the
   destination, i.e.  its global-scope non-deprecated IPv6 addresses.

4.2.2 NAROS_RESPONSE

   The NAROS_RESPONSE message is sent by a NAROS server and specifies
   which is the best source address to contact the destination.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Version = 1  | Msg type = 2  |         Reserved = 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Identifier                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Lifetime                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |                Unused = 0                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                     Destination Prefix                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                     Best Source Address                       +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Identifier field specifies the request for which the
   NAROS_RESPONSE message is a reply.  It must be the same identifier as
   the identifier contained in the associated request.

   The Lifetime field defines how long the information contained in this
   message can be cached by the client.

   The Prefix Length and Destination Prefix fields defines the
   destination prefix for which the best source address contained in
   this message applies.  The Prefix Length field indicates the length



de Launois & Bonaventure    Expires November 13, 2003          [Page 12]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


   in bits of the destination IP address prefix.  A length of zero
   indicates a prefix that matches all IP addresses.  The Destination
   Prefix field contains the destination IP address prefix followed by
   enough trailing bits to fill the field.  Note that the value of
   trailing bits is irrelevant.

   The Best Source Address field specifies the source IP address that
   the server determined to be the best to reach the destination prefix.

   When receiving a NAROS_RESPONSE message, the client MUST first check
   the validity of the selected best source address, i.e.  it must check
   that the source address is available and not deprecated.  If the
   client determines that the best source address is not a valid choice,
   then it MAY use another available source addresses.  Otherwise it
   SHOULD use the selected source address for all communications towards
   any destination belonging to the destination prefix, until the
   lifetime expires.  The selected source address for the destination
   prefix SHOULD be cached during the specified lifetime.

4.2.3 NAROS_ERROR_RESPONSE

   A NAROS_ERROR_RESPONSE is used to provide error messages from a NAROS
   server to a NAROS client.  Multiple errors MAY NOT be reported in the
   same NAROS_ERROR_RESPONSE.  In situations where more than one error
   has occurred, the NAROS server MUST choose only one error to report.
   The format of the message is :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Version = 1  | Msg type = 3  |         Reserved = 0          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Identifier                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Error             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Identifier field specifies the request for which the
   NAROS_ERROR_RESPONSE message is a reply.  An NAROS_ERROR_RESPONSE
   message MUST only be transmitted by a NAROS server, and only in
   response to a request from a NAROS client.  A NAROS client that
   detects an error in a message received from a NAROS server MUST
   silently discard the message.

   The values for the Error field are defined in Section 7.

5. Security Considerations




de Launois & Bonaventure    Expires November 13, 2003          [Page 13]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


   A NAROS server should take all measures deemed necessary to prevent
   its clients from performing intentional or unintentional denial-of-
   service attacks by issuing a large number of requests.  Moreover,
   NAROS messages received by a client should be authenticated since the
   introduction of malicious NAROS_RESPONSE messages could divert
   traffic from its regular path.

   However, the NAROS service allows all the providers of the multihomed
   site to perform ingress filtering, which benefits to security.

6. Conclusion

   With the solution proposed in this document, several
   provider-aggregatable IPv6 addresses are allocated to each host
   inside a multihomed site.  When a host needs to communicate with a
   destination outside its site, it contacts its NAROS server to
   determine the appropriate source IPv6 address to be used.  The NAROS
   server does not maintain any per-host state and could easily be
   deployed as an anycast service inside each site.  An advantage of the
   utilization of the NAROS server is that by selecting the addresses to
   be used by the hosts, the NAROS server influences the flow of traffic
   with its providers.  This allows the NAROS server to indirectly, but
   efficiently, engineer its interdomain traffic, without manipulating
   any BGP attribute.  Moreover, full route aggregation is maintained
   and the NAROS service can be set up independently from the providers.
   Changes are limited to hosts inside the multihomed site.  Legacy
   hosts are still able to work, even if they cannot benefit from
   site-multihoming.

   Performance evaluations of the NAROS protocol can be found in [9].

7. Appendix A : NAROS Error Numbers

   This section provides descriptions for the error values in the
   NAROS_ERROR_RESPONSE message.  The 2-byte length Error field is
   divided into a 1-byte Error Type and a 1-byte Error Code.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Error Type    |  Error Code   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The currently defined error values are shown below.







de Launois & Bonaventure    Expires November 13, 2003          [Page 14]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


    Type                      Type   Code   Error Name
   ---------------------     -------------------------------------------
     1   General errors        1      1     UNKNOWN_ERROR
     2   Message errors        1      2     INTERNAL_SERVER_ERROR
     3   Routing errors        1      3     UNSUPPORTED_NAROS_VERSION
                               2      1     ILLEGAL_MESSAGE
                               2      2     BAD_MESSAGE
                               3      1     NO_ROUTE
                               3      2     ADMINISTRATIVELY_PROHIBITED


   1 : General errors

      UNKNOWN_ERROR.  An error that cannot be identified has occurred.
      This error should be used when all other error messages are
      inappropriate.

      INTERNAL_SERVER_ERROR.  An NAROS server application has detected
      an unrecoverable error within itself.

      UNSUPPORTED_NAROS_VERSION.  An NAROS client sent a message with a
      version number that is not supported by the NAROS server.

   2 : Message errors.

   The server uses these errors when it detects that a message is
   malformed, as well as when it does not understand a message.

      ILLEGAL_MESSAGE.  The message contains illegal values for one or
      more fields.

      BAD_MESSAGE.  The message is malformed and server parsing failed.

   3 : Routing errors.

   The server uses these errors when it is unable to select the best
   source address needed by the client to reach a destination.

      NO_ROUTE.  The server has no route towards the destination.

      ADMINISTRATIVELY_PROHIBITED.  The server has a route towards the
      destination but it is administratively prohibited.

References

   [1]   Atkinson, R., "IAB Concerns & Recommendations Regarding
         Internet Research  & Evolution", Internet Draft
         draft-iab-research-funding-00, February 2003.



de Launois & Bonaventure    Expires November 13, 2003          [Page 15]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


   [2]   Agarwal, S., Chuah, C. and R. Katz, "OPCA: Robust Interdomain
         Policy Routing and Traffic Control", Proc. OPENARCH, 2003.

   [3]   Bu, T., Gao, L. and D. Towsley, "On Routing Table Growth",
         Proc. IEEE Global Internet Symposium, 2002.

   [4]   Quoitin, B., Uhlig, S., Pelsser, C., Swinnen, L. and O.
         Bonaventure, "Interdomain traffic engineering with BGP", IEEE
         Communications Magazine, May 2003.

   [5]   Abley, J., Black, B. and V. Gill, "Goals for IPv6
         Site-Multihoming Architectures", Internet Draft
         draft-ietf-multi6-multihoming-requirements-04, April 2003.

   [6]   Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks  which employ IP Source
         Address SpoofingNeighbor Discovery for  IP Version 6 (IPv6)",
         RFC 2267, January 1998.

   [7]   Draves, R., "Default Address Selection for IPv6", Internet
         Draft draft-ietf-ipv6-default-addr-select-09, August 2002.

   [8]   Conta, A. and S. Deering, "Network Ingress Filtering: Defeating
         Denial of Service Attacks  which employ IP Source Address
         SpoofingNeighbor Discovery for  IP Version 6 (IPv6)", RFC 2463,
         December 1998.

   [9]   de Launois, C., Bonaventure, O. and M. Lobelle, "The NAROS
         Approach for IPv6 Multi-homing with Traffic Engineering", URL
         http://www.info.ucl.ac.be/people/delaunoi/, Submitted QoFIS,
         April 2003.

   [10]  Dupont, F., "Multihomed routing domain issues for IPv6
         aggregatable scheme", Internet Draft
         draft-ietf-ipngwg-multi-isp-00, September 1999.

   [11]  Huitema, C. and R. Draves, "Host-Centric IPv6 Multihoming",
         Internet Draft draft-huitema-multi6-hosts-01, June 2002.

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

   [13]  Thomson, S. and T. Narten, "IPv6 Stateless Address
         Autoconfiguration", RFC 2462, December 1998.

   [14]  Moskowitz, R., "Host Identity Payload Architecture", Internet
         Draft draft-moskowitz-hip-arch-02, February 2001.




de Launois & Bonaventure    Expires November 13, 2003          [Page 16]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


   [15]  Coene, L., "Multihoming issues in the Stream Control
         Transmission Protocol", Internet Draft
         draft-coene-sctp-multihome-03.txt, February 2002.

   [16]  Bagnulo, M., Garcia-Martinez, A. and I. Soto, "Application of
         the MIPv6 protocol to the multi-homing problem", Internet Draft
         draft-bagnulo-multi6-mnm-00, February 2003.

   [17]  Tattam, P., "Preserving active TCP sessions on Multihomed IPv6
         Networks", Internet Draft , URL http://jazz-1.trumpet.com.au/
         ipv6-draft/preserve-tcp.txt, August 2001.

   [18]  Bradner, S., "Key words for use in RFCs to indicate requirement
         levels", RFC 2119, March 1997.

   [19]  <http://bgp.potaroo.net>


Authors' Addresses

   Cedric de Launois
   UCL/INGI
   Place Ste-Barbe 2
   B-1348 Louvain-la-Neuve
   Belgium

   EMail: delaunois@info.ucl.ac.be
   URI:   http://www.info.ucl.ac.be/people/delaunoi/


   Olivier Bonaventure
   UCL/INGI
   Place Ste-Barbe 2
   1348 Louvain-la-Neuve
   Belgium

   EMail: bonaventure@info.ucl.ac.be
   URI:   http://www.info.ucl.ac.be/people/OBO/













de Launois & Bonaventure    Expires November 13, 2003          [Page 17]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


Intellectual Property Statement

   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 of the 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 implementors 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
   Director.


Full Copyright Statement

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

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

   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
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



de Launois & Bonaventure    Expires November 13, 2003          [Page 18]


Internet-Draft    Multihoming with Traffic Engineering          May 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

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











































de Launois & Bonaventure    Expires November 13, 2003          [Page 19]