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]