Internet Engineering Task Force M. Morelli
Internet-Draft Telecom Italia Lab.
Expires: January 10, 2005 J. Palet
Consulintel
D. Fernandez
Technical Univ. of Madrid (UPM)
A. Gomez
University of Murcia (UMU)
July 12, 2004
Advanced IPv6 Internet Exchange model
draft-morelli-v6ops-ipv6-ix-00.txt
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.
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 January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Internet Exchanges (IX) have played a key role in the development of
Internet, organizing and coordinating the traffic interchange among
Morelli, et al. Expires January 10, 2005 [Page 1]
Internet-Draft Advanced IPv6 IX model July 2004
Internet Service Providers (ISP). Traditionally, IXs have been based
on layer 2 infrastructures, being the layer 3 services managed by the
participant ISPs.
However, IPv6 hierarchical and aggregatable routing and addressing
model comes to enhance the IX functionalities by proposing to
directly assign addresses to IX customer's networks. The customers
can connect with one or several upstream providers and have a
separated addressing space, dependent on the IX instead of the
providers, in order to facilitate multihoming or avoid renumbering
procedures when changing the provider.
In addition, being an IX a central point where traffic is
concentrated, several networks and application services benefit from
the fact of being partial or totally offered from an IX, opening the
IX to the world of new advanced services and functionalities like
security, AAA, QoS, multicast, mobility, PKI, DNSSEC or policy
provision, that could also facilitate the deployment of IPv6 and
their required transition mechanisms.
This document describes an architectural model for an advanced IPv6
Internet Exchange that offers IPv6 address delegation services, as
well as other advanced network and application services. The
document discusses also about how these services can be offered from
an IX and their associated requirements.
Morelli, et al. Expires January 10, 2005 [Page 2]
Internet-Draft Advanced IPv6 IX model July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Reference Scenario . . . . . . . . . . . . . . . . . . . . . . 6
4. Relationship with the traditional IX model . . . . . . . . . . 7
5. Overview of the new advanced IPv6 IX model . . . . . . . . . . 7
5.1 Layer 2 infrastructure . . . . . . . . . . . . . . . . . . 9
5.2 Layer 3 infrastructure . . . . . . . . . . . . . . . . . . 9
5.3 Server Farm . . . . . . . . . . . . . . . . . . . . . . . 10
6. Advanced IPv6 IX Services . . . . . . . . . . . . . . . . . . 10
6.1 Network services . . . . . . . . . . . . . . . . . . . . . 10
6.1.1 Address Delegation . . . . . . . . . . . . . . . . . . 10
6.1.2 Route Server . . . . . . . . . . . . . . . . . . . . . 12
6.1.3 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1.4 AAA Services . . . . . . . . . . . . . . . . . . . . . 15
6.1.5 Multicast . . . . . . . . . . . . . . . . . . . . . . 17
6.1.6 Mobility . . . . . . . . . . . . . . . . . . . . . . . 18
6.1.7 Multihoming . . . . . . . . . . . . . . . . . . . . . 18
6.1.8 DNS . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2 Transition services . . . . . . . . . . . . . . . . . . . 18
6.3 Support and policy-based management services . . . . . . . 19
6.4 Security services . . . . . . . . . . . . . . . . . . . . 20
6.4.1 PKI . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4.2 DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4.3 Distributed security . . . . . . . . . . . . . . . . . 20
6.5 Other services . . . . . . . . . . . . . . . . . . . . . . 21
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. Informative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25
Morelli, et al. Expires January 10, 2005 [Page 3]
Internet-Draft Advanced IPv6 IX model July 2004
1. Introduction
In recent years, Internet Exchanges (IX) and Network Access Points
(NAP) have played a key role in the development of Internet.
An IX is commonly a neutral point where different Internet Service
Providers (ISP) deploy their routers in order to exchange their
traffic according to some kind of commercial and peering agreements
(i.e. public peering agreement).
A NAP is basically an enhancement of the IX concept that, apart from
a place to host bilateral peering arrangements between similar
providers, it takes the role of a transit purchase venue, where
regional ISPs can acquire transit services from long-haul or transit
providers.
Although there are differences between an IX and a NAP, in the
context of this document we will use the term IX to refer to both of
them. As described later, the IX model presented here can be
classified as an enhanced NAP, adding new services like IPv6 address
delegation to a classical NAP.
An IX is usually based on a layer 2 infrastructure, fully redundant
and made of high performance switches, where ISPs layer 3 equipment
(routers) connect to.
Typically, IXs do not provide any layer 3 services to their
customers, apart from route servers or other specific functions that
help to organize and simplify routing in the IX. Other services,
like AAA or multicast, are normally offered by each ISP.
However, being the IX a central point where the traffic is
concentrated, several network and application services being offered
nowadays would benefit from being partially or totally supported in
the IX itself.
On the other hand, IPv6 proposes a strictly hierarchical routing and
addressing model that essentially follows the principles stated in
CIDR [1]: hierarchical assignment of addresses and routing based on
aggregation. The addresses assigned to an organization depend on the
point they connect to the Internet. As a consequence, if the site
changes its provider, its global prefix must be changed according to
its new location in the global topology.
In order to avoid renumbering when changing provider, IPv6 routing
model [2] proposes a new way of assigning addresses based on IXs. It
basically consists on delegating prefixes to IXs that are later
sub-assigned to organizations connecting to the IX. In this way, the
Morelli, et al. Expires January 10, 2005 [Page 4]
Internet-Draft Advanced IPv6 IX model July 2004
address assignment is decoupled from the connectivity provision,
taking the IX the role of address provider.
This new IPv6 IX based addressing model, as well as the advantages of
locating network and application services inside the IXs, bring new
possibilities for the design of new advanced IPv6 Internet Exchanges
architectures, opening the providers market to new opportunities and
actors.
Therefore, this document extensively describes an advanced IPv6 IX
model and their requirements, providing details about the different
ways customers can access IX services, the way routing is organized
between customers and providers, as well as a list of services that
benefit from being offered from the IX and the way they can be
organized and operated.
2. Terminology
o Address Delegation (AD): The process by which an IX assigns
address space to an IXC.
o Customer Exchange Routers (CER): The routers used to connect IX
customers to the IX.
o Internet Exchange (IX): It refers to a generalized exchange point
including basic peering functionalities, as well as transit
purchase services found in NAPs
o IX Address Prefix: An IPv6 address prefix assigned by a Regional
Registry to the IX with the objective to be later sub-delegated to
IX customers.
o IX Administrator: The entity in charge of IX management.
o IX Customer (IXC): A customer network that uses an IPv6 address
prefix sub-delegated from an IX Address Prefix.
o IX Local Customer (IXLC): An IXC which is directly connected to
the IX through a router that can be either managed by the IX
administrator or by the customer.
o IX Remote Customer (IXRC): An IXC which is not directly connected
to the IX, but through a regional provider present on the IX. The
regional provider manages the distribution of the customer IX
sub-prefix through its network.
o IX Value Added Services: Network and application services offered
by the IX to its customers and/or providers peering on the IX.
Morelli, et al. Expires January 10, 2005 [Page 5]
Internet-Draft Advanced IPv6 IX model July 2004
o Layer 3 Mediation Function (L3MF): An entity acting as the
intermediary between IX customers and providers.
o Long Haul Provider (LHP): An Internet Service Provider (ISP)
present on the IX that provides transit services to IX customers
and regional providers.
o Regional Provider (RP): An Internet Service Provider that peers
with other providers at the IX and optionally gets transit
services from LHP.
3. Reference Scenario
The following figure describes the main reference scenario of the
advanced IPv6 Internet Exchange model defined in this document.
Long Haul Providers
+------+ +------+
| LHP1 |...| LHPm |
+------+ +------+
| |
+------------------|--------|----------------+
| +----+ +----+ |
| IX | R1 |...| Rm | |
| +----+ +----+ |
| | | | IX Customers
|+----------+ +-----------------+ +------+ | +-------+
|| | | |--| CER1 |-|-| IXLC1 |
|| Value | | Layer Three | +------+ | +-------+
|| Added |--| Mediation | : | :
|| Services | | Function | +------+ | +-------+
|| | | |--| CERn |-|-| IXLCn |
|+----------+ +-----------------+ +------+ | +-------+
| | | |
| +----+ +----+ |
| | R1 |...| Rk | |
| +----+ +----+ |
+------------------|-------|-----------------+
| |
+--------+ +--------+
| RP1 | | RPk |
| | | |
| +-----+|...| +-----+|
| |IXRC1|| | |IXRCk||
| +-----+| | +-----+|
+--------+ +--------+
Regional Providers
Morelli, et al. Expires January 10, 2005 [Page 6]
Internet-Draft Advanced IPv6 IX model July 2004
The IX is made of:
o A classical L2 infrastructure (i.e, a high speed LAN), not
represented on the figure.
o ISP routers (R), that connect ISP networks to the IX.
o Customer Exchange Routers (CER), that connect local customer
networks to the IX.
o The L3MF that acts as an intermediary between IX customers and
ISPs.
o Value Added Services, that refers to those additional network and
application services that can be partially or totally offered from
inside the IX.
Two types of IX customers are foreseen in the scenario:
1. IX Local Customers (IXLC), which are directly connected to the IX
through a router that can be either managed by the IX
administrator or the customer network administrator.
2. IX Remote Customers (IXRC), which are not directly connected to
the IX but to a regional provider that is present on the IX.
Both type of customers use address prefixes sub-delegated from the IX
addressing range.
The figure above is a functional scheme and it does not imply in
which way the functionalities described here have to be implemented.
4. Relationship with the traditional IX model
From a theoretical point of view, there are no constraints in merging
the traditional model with this new advanced model, that means that
some customers may use the IX to exchange traffic among each others
and simultaneously other customers (IXLC) may use the Internet
Exchange according to this new functionality.
In the following, we refer only to the new advanced model so the term
customer refers only to the IXLC.
5. Overview of the new advanced IPv6 IX model
In a classical model, an IX is not normally opened to the direct
connection of customers (i.e. large corporate networks or small ISPs
or whatever). Instead of that, customers are connected to ISP
Morelli, et al. Expires January 10, 2005 [Page 7]
Internet-Draft Advanced IPv6 IX model July 2004
networks, which are present on the IXs.
In those cases where customers are directly connected to an IX, they
typically subscribe an agreement with one or several Long Haul
Providers present on the IX to route their traffic and announce their
prefix addresses. Customer addresses can be sub-assigned from the
provider ranges, that is, customers can use Provider Aggregatable
(PA) address space. Alternatively, customers can get Provider
Independent (PI) addresses directly from the RIRs.
If the customer changes its Long Haul Provider and is using PA
addresses, it will have to renumber its network. The only way to
avoid renumbering is to use PI addresses. However, to preserve the
scalability of the whole routing system, PI addresses do not longer
exist in IPv6. Therefore, following a classical IX model, changing
provider in IPv6 implies renumbering the customer network.
To solve this problem, the advanced IX model presented in this
document uses a different approach based on the possibility (new for
an IX) to directly assign IPv6 addresses to the customers.
Connectivity provision and IPv6 address assignment are now separated
issues and they are no longer both linked to the LHP.
In this way, if an IX customer wants to change its service provider
(e.g. because it gets a better service or price from another LHP),
it does not need to change its own addresses, as they have been
assigned by the IX and not by the service provider. It only will
have to renumber if it changes the IX it is connected to (or from IX
group, for instance, in case of distributed IX).
Consequently, in this new model the IX plays an important role in the
Internet service provision: assigning addresses to customers and
acting as a mediator between them and the LHPs. That is the reason
why the main new IX functionality has been called Layer Three
Mediation Function (L3MF), as it provides the decoupling among the
customers and the LHPs.
Note that in the traditional IXs, agreements among the parties are
usually taken among the ISPs connected to the IX itself. In fact,
the IX is a neutral entity that does not have a particular role,
since it basically provides the Layer 2 Connectivity infrastructure.
In the advanced model proposed here, three different entities are, in
principle, involved: the IX itself, the IX customers and the LHPs.
This means that different agreements could be taken, for example,
according to the role of the IX.
Hence, it does not mean that IX customers will necessarily have to
Morelli, et al. Expires January 10, 2005 [Page 8]
Internet-Draft Advanced IPv6 IX model July 2004
negotiate with two or more different organizations (IX administrator
and ISPs) in order to get Internet services. Instead, IXs could act
as intermediaries between customers and ISPs, offering a
one-stop-shop service. This will depend on business particularities/
models instead of technical ones and consequently are no further
described in this document.
Another advantage is the possibility to use this model in order to
provide value added services to the customers. The main concept is
in fact that each IX can be considered as a place where services and
ISP can be co-located and can be provided to a large amount of users
taking advantage of the natural aggregation (in terms of Providers)
that may happen inside an IX. These services will be discussed in
the remaining sections.
The proposed model can be considered as the sum of different
infrastructural layers. In fact, whereas the traditional IX model is
mainly based on a layer 2 infrastructure used to exchange traffic in
a quick, scalable and reliable way, on the other hand, the advanced
IPv6 IX is to be considered like an extended one, where it is
possible to find, together with the above mentioned layer 2
functionalities and the layer 3 infrastructure, other services and
functionalities usually not present in the traditional model.
From a theoretical point of view, there are no constraints in merging
the traditional IX model with this new advanced model. This means
that some traditional customers may use the IX to exchange traffic
among them while simultaneously other customers (so-called "next
generation" customer) may use the Internet Exchange according to this
new functionality. In the following, we will refer only to the new
advanced model, so the term customer refers only to the "next
generation" customers.
What is proposed here is essentially an architectural model,
identifying the logical blocks to put inside the IX. This draft does
not make reference to the real implementation model and its
relationship with existing ISP architectural and commercial models.
5.1 Layer 2 infrastructure
It is basically the same as in the traditional IX. It consists on a
switching platform (usually fully redundant and high performing)
where the customers' routers are connected. In the new advanced
model there are no particular changes related to this model.
5.2 Layer 3 infrastructure
This part of the structure depends on the implementation of the
Morelli, et al. Expires January 10, 2005 [Page 9]
Internet-Draft Advanced IPv6 IX model July 2004
so-called intermediation function between the connectivity provider
and the customer. In a traditional IX, the layer 3 framework
consists basically on the routers of the ISPs present in the IX.
Other L3 functionalities can be present, for example, a Route Server
used to centralize and simplify the exchange of the routes between
the peering partners. Additionally, other entities can be included
to give support to services like multicast, mobility, etc.
5.3 Server Farm
The new model here proposed foresees that services are placed inside
an IX. This is a revolutionary concept that permits the development
of a different technical and business scenarios. Putting services
inside an IX can take advantage because somehow it reduces the
"distance" between who provides the service and who (the users) use
that service. This may mean, for example, to reduce the response
time of the service and to reduce the probability to have service
unavailability. Obviously these considerations does not take into
account the impact that this kind of model can have on the
pre-existing ISP networks and a lot of attention should be paid on
this aspect, not covered in this draft. Suitable IX models can be
implemented in order to avoid conflicts with the pre-existing
scenario and to take advantage of this solution.
6. Advanced IPv6 IX Services
This section describes and discusses about the services that can be
offered from an IX based on the model introduced in this document
according to the structure presented in the previous section.
Services are grouped in network services, transition services,
support and management services, security services and other
services.
6.1 Network services
6.1.1 Address Delegation
Address delegation is one of the main functions to be offered by an
advanced IPv6 IX. As mentioned, the new IX model decouples address
assignment from connectivity provision, taking the IX the role of
assigning addresses to its customers and the ISPs connected to the IX
the provision of the connectivity to Internet.
IX administrators will request to their corresponding Regional
Internet Registry (RIR) one or more address prefixes, basically
following the same rules defined for ISPs or, as they are named,
Local Internet Registries (LIRs). Technically, the IX will behave as
Morelli, et al. Expires January 10, 2005 [Page 10]
Internet-Draft Advanced IPv6 IX model July 2004
a LIR, being assigned by the registries the required prefixes.
Later, the prefixes assigned to the IX will be sub-delegated to IX
customers, following the same rules a LIR uses to assign addresses to
its customers [3].
The address delegation service is the basement of two basic services
that can be offered to IX customers:
1. Provider Selection, that allows customers to choose the ISPs they
want to get connectivity service from, as well as easily changing
the selection without having to renumber their network.
2. Multihoming, which allows customers to simultaneously get
connectivity services from two or more ISPs and define their
routing policy. For example, customers can use one of the
providers as the primary connection and using others as a
fallback solution, or do load sharing among them.
L3MF will be the basic functional entity managing address delegation
service in the IX. It will be in charge of:
1. Announcing the IX prefix/es to the ISPs peering on the IX.
2. Organizing the routing among IX customers and ISPs.
3. Implementing address delegation associated services like provider
selection and multihoming.
In order to keep routing scalability, IX prefix/es must be announced
aggregated to the IPv6 Internet through the ISPs peering on the IX.
In principle, unaggregated prefixes assigned to IX customers must not
be redistributed outside the IX (only to routers present on the IX).
This fact imposes the limitation that all incoming traffic (that is,
traffic destined to IX addresses) will follow the same path,
independently of the IX customer it is directed to.
The only way to exert some control over the incoming path is to relax
the rule mentioned above and allow the distribution of IX customer's
unaggregated prefixes. However, that can only be done if they are
distributed to a limited scoped, for example, though an ISP that has
agreed with the IX to allow that or through a link that connects to
another IX being part of an IX group or confederation. In any case,
mechanisms must exist to guaranty that unaggregated prefixes are not
freely redistributed (for example, filters based on community tags
defined by the IX).
Typically, the L3MF will be implemented inside an IX managed router
Morelli, et al. Expires January 10, 2005 [Page 11]
Internet-Draft Advanced IPv6 IX model July 2004
using BGP protocol. L3MF will maintain external BGP peering with the
ISPs and IX customer routers in order to direct each customer's
traffic to its corresponding ISP. L3MF router will intelligently
modify the NEXT_HOP BGP attribute to avoid that traffic passing
through the L3MF router. However, there are other possible ways of
implementing L3MF functionality, for example, using static routing or
with the help of a route sever, as it is mentioned on the next
section. The way the L3MF is implemented is out of the scope of this
document.
As presented in section 3, two types of IX customers are defined:
1. IX Local Customers (IXLC), which have a direct layer 3 connection
to a router in the IX (named CER), either managed by the customer
or by the IX administrator. These customers can be connected to
the IX using different technologies like point to point links,
Frame relay, MPLS VPNs, etc. Customer routers (CER) can be
dedicated to a customer or can be shared between several.
However, in the shared case, all the preferences and routing
policies will be common to all customers sharing the router.
2. IX Remote Customers (IXRC), which have not direct layer 3
connection with any router in the IX. They are customers of one
of the providers present on the IX and so they are connected to
the ISP network at some place different from the IX, but they use
addresses form the IX prefix. In this case, the ISP has to cope
with the distribution of the prefix assigned to the customer
through its routing system, in order to have the customer
accessible from the IX.
Both services defined (provider selection and multihoming) are
available for IXLC. However, none of them are available for IXRC, as
the customer is integrated in ISP network. Even that, the customer
maintains the advantage that it is using IX assigned addresses, so in
case he changes provider to another one present on the IX, it avoids
having to renumber its network.
6.1.2 Route Server
Another service that it is commonly found on IXs is the route server.
Roughly speaking, a Route Server is a modified BGP daemon designed to
act as a central point for peering, changing the classical mesh
topology of an IX into a star topology, where each ISP's border
router maintains just one BGP peering with the route server.
By using a route server the scalability of the IX is greatly
improved, because, being "n" the number of ISPs present in the IX,
the number of BGP peering is O(n) and not O(n2) as it is with a mesh
Morelli, et al. Expires January 10, 2005 [Page 12]
Internet-Draft Advanced IPv6 IX model July 2004
topology. Moreover, the addition of new members to the IX is
simplified, as only a new peering between new ISP router and the
route server has to be configured.
The route server service can play an important role in the IPv6 IX
model described in this document. Apart from the usual benefits that
arise from the use of a route server mentioned above, it can help
implementing the provider selection and multihoming services
associated with IX based address delegation.
In particular, L3MF can be integrated with the route server
functionality, giving rise to an Enhanced Route Server (ERS) that
centralizes the peering among ISPs and IX customers routing related
functions.
The use of a route server on an IX must not change the way routing is
organized among ISPs. In other words, the route server must be
transparent, meaning that the routes learned and installed by each
border router must be the same when the route server is present than
when it is not (mesh topology).
With this premise in mind, two types of route servers arise,
depending on how much "intelligence" we relay on them:
1. Transparent Route Server, which propagates all the routes
received from any router to the rest of routers, without
modifying route attributes. In this way, routers acquire the
same routing information as they would do via direct peering
("full mesh" topology), allowing them to apply their selection
criteria according to their local policies.
2. Smart Route Server, which is an "intelligent" BGP daemon which
performs best path selection on behalf of client routers. For
this purpose, it must maintain a separate RIB for each of the
clients, and it must also know the routing policies of all the
clients. When the Route Server receives some announce it applies
the appropriate policies before inserting them into the Loc-RIB
corresponding to each client.
The main drawback of the first type of Route Server is that it needs
to introduce some modifications to BGP protocol, because in BGP-4 it
is not possible to send more than one announcement corresponding to
the same prefix through a single peering. There are some proposals
for modifying the protocol in order to make that possible, for
example, the mechanism proposed in [4] or the new attribute proposed
in [5].
However, the second type seems the most appropriate for the advanced
Morelli, et al. Expires January 10, 2005 [Page 13]
Internet-Draft Advanced IPv6 IX model July 2004
IX model purposes, due to the following reasons:
o It does not need any modification to route server clients BGP
implementations (any currently available BGP implementation will
suffice for ISP and customer routers).
o The provision of the new services associated to IX based address
delegation suggests keeping the client-side BGP configuration as
simple as possible (at least, for IX customer routers), and this
means moving all the policies and best path selection process into
the Route Server. This is precisely the idea of the smart route
server.
In summary, the use of an ERS based on a smart route server to
implement L3MF greatly simplifies the provision of complex services
like load sharing multihoming. All the complex functions (filtering,
policies, etc) that in other case should be implemented on IX
customer routers are moved into the route server, who performs them
on behalf of the customers and under the management of the IX
administrator. In this way, requirements for IX customer routers are
reduced and their management greatly simplified.
It is important to note that the use of an ERS to give service to IX
customers does not necessarily imply that ISP peering sessions must
be integrated on that. ISPs can peer directly among them over the
layer 2 infrastructure or even the ERS can coexist with another route
server that centralizes peering among ISPs.
6.1.3 QoS
The management of QoS can be efficiently done by means of policy
provision architectures. With this approach, the functionality and
flexibility increases notably. The utility of this kind of solution
can be improved by advanced IX, as they can be a key element of such
architectures.
The QoS provision usually is made by means of Policy Based Networks
(PBNs) architectures based on the one proposed at [6], although it is
strongly oriented to intra-domains enviroments.
The IX can provide solutions more scalable and more powerful in order
to achieve end-to-end QoS allocation among different domains. Being
the IX the common point where different domains are connected to,
they might store information about the network status, user rights
and so on, in order to decide if a given QoS request can be
successfully granted.
Even if domains physically attached to other IX have to participate
Morelli, et al. Expires January 10, 2005 [Page 14]
Internet-Draft Advanced IPv6 IX model July 2004
to provide QoS resources, communication between the IX involved could
be done to share the required information in order to decide whether
or not the QoS resources allocation is possible.
Consequently, the main functionalities that the IXs could provide
regarding QoS provision are:
o Provision of policies among QoS edge routers belonging to
different domains.
o Define QoS policies for classifying data streams traversing the
network.
o Store the policies edited by network administrators.
One of the main keys to succeed with this solution is the
implementation of the policies. In general, PBN enforces the usage
of network resources based on policies derived from criteria defined
by network administrators, particularly, QoS PBNs allocate QoS
reservations based on such policies.
However, policy is a general and abstract concept, which needs to be
specified in particular actions. On the other hand, such policies
should be defined by using high-level languages to let administrators
easily define conditions that influence on the resource reservations
and at the same time, easily understand the policies defined by other
administrators. Thus, the more flexible are the policies, the more
powerful is the PBN.
Given the fact that an IX is a network point where a number of
different technologies can be present, the policies used on this type
of environments should be as more general as possible in order to do
not exclude any type of network.
6.1.4 AAA Services
AAA infrastructure can be deployed in an IX service network to offer
authentication, authorization and accounting services in a wide
variety of ways and to different kind of users and purposes. The
main advantage to use AAA services is that they can provide support
to mobile and roaming end users that roam between different ISPs or
IXs. The recommended protocol defined to transport AAA information
is DIAMETER [7].
Depending of the functionality provided by the IX to the clients
(ISPs or end users), the AAA service has different requirements. For
example, the IX could need to offer secure access control to end
users connected directly to the network IX, also, the AAA services
Morelli, et al. Expires January 10, 2005 [Page 15]
Internet-Draft Advanced IPv6 IX model July 2004
can be used by the security services defined in the clients ISP
service network. Some of the possible alternatives are listed below.
6.1.4.1 IX provides only internal AAA service
An IPv6 IX can provide AAA services to directly connected AAA end
users, that is, users that do not arrive from a local ISP.
When the IX network receives connections from end users through
network access services (NAS), users can be authenticated and
authorized to obtain the network connection using the local AAA
server sited in the IX service network.
If the number of NAS in the IX network becomes unmanageable,
intermediate elements can be used, like Relay or Proxy AAA agents.
If the user's authentication or authorization process requires the
exchange of information between external AAA servers, then a Redirect
AAA service (described below) can be deployed locally.
6.1.4.2 IX provides accounting service to ISPs
The AAA service can be used only to get accounting information about
the connected ISPs. For example, an IX charges to ISP by the
bandwidth consumed in the link between them, the IX can deploy an AAA
service used to obtain accounting information from the link to the
ISP. In this case could not have authentication or authorization
process.
6.1.4.3 IX provides AAA Routing service
Assuming an IX with several local ISPs, when an AAA server (AAA-A)
sited on a local ISP network (ISP-A) needs to exchange information to
another AAA server (AAA-B) sited on another local ISP network
(ISP-B), the IX can provide Relay and Proxy AAA services to allow
AAA-A to reach easily AAA-B and vice-versa.
6.1.4.4 IX provides AAA Redirect service
If AAA servers sited in ISPs local to an IX need to interact with
external to the IX AAA servers. The own IX can provide a common AAA
Redirect service to allow locate and provide information about these
remote servers.
6.1.4.5 IX provides AAA Translation Service
Supposing the common situation, in which the ISPs have a RADIUS [8]
or TACACS+ [9] system used to authenticate users, the IX can offer a
Morelli, et al. Expires January 10, 2005 [Page 16]
Internet-Draft Advanced IPv6 IX model July 2004
common point to translate the RADIUS domains to DIAMETER domains,
adding additional functionalities to the RADIUS technology. This
translation can be done placing an AAA translation service in the IX
network.
To locate an AAA infrastructure inside an IX network implies to
provide authentication and authorization services. In base of the
AAA specification, the AAA server could use ASM modules to interact
with external entities, which offer advanced authentication and
authorization services to help the AAA server. That is, advanced
authentication and authorization entities could be deployed in the
IX. An authentication system can be deployed using a Public Key
Infrastructure (PKI) and an authorization system can be deployed
using an Authorization Authority, based, for example, on SAML or PMI
technologies.
Moreover, to locate an AAA infrastructure inside an IX may imply that
the AAA services need to establish authorization and authentication
data exchanges between external AAA servers. These external servers
sometimes have a trusted relationship with the original IX, but in
other occasions, the AAA servers belong to not previously known
organizations. In any case the exchange between servers must be
protected establishing secure channels, commonly using IPsec or TLS
protocols. The secure channels should be established using public
key cryptography to avoid the problem of distribute secret keys
between organizations.
If the AAA servers belong to a well-known organization, a
cross-certification relationship can be established between the
servers to protect the AAA exchanges. If the AAA servers belong to a
not known organization the exchange only could be possible if a
certification path can be discovered between the peers CAs.
Additionally in large networks, which may include millions of users,
the management of mobility services and as a consequence their Home
Agents, become operationally and administratively a complex scenario.
Then a solution where the AAA infrastructure can help to solve this
situation and then the integration of a AAA services like this within
the IX is needed.
6.1.5 Multicast
Multicast Transmission Services are one of the services that can be
provided in this advanced IX scenario. With reference to the ASM
approach (PIM-SM particularly), the IX could be in fact the right
location where to place the RendezVous Point, since it is the focal
point where the IX customers and the ISP could meet. The
introduction of RP inside the IX could take some advantage as for
Morelli, et al. Expires January 10, 2005 [Page 17]
Internet-Draft Advanced IPv6 IX model July 2004
example the optimisation of latency in transmission with a
better-perceived quality by the users.
6.1.6 Mobility
TBD.
6.1.7 Multihoming
Moreover, this model could facilitate a multihoming solution since a
customer is naturally multihomed (connected to more than one LHP/ISP
at the same time). ??? TBD.
6.1.8 DNS
TBD.
6.2 Transition services
Most of transition mechanisms are tunnel-based and/or require a
relay, server, tunnel-end-point (TEP) or other similar
functionalities.
Some of them, such as 6to4 [10][11], use mechanism such as anycast,
to discover the TEP. But others require a manual configuration
(users have to know where the TEP is located or a method to find it),
while already automatic discovery procedures had been proposed [12].
Furthermore users without technical knowledge don't know in general,
how to choose the best transition mechanism (the one that provides de
"best performance").
The IXs can play an important role to help to overcome such barriers,
so users do not need to know anything about which are the best
mechanisms and/or TEPs or other configuration parameters (i.e.
tunnel brokers/servers). Therefore, the following advantage can be
obtained by using IX with auto-discovery capabilities:
o Simplicity to client's configuration because they only would need
to know one destination to get the best IPv6 connectivity, and
this can be automatically discovered.
o Transparency in the communication in case that a server gets down
because datagrams would be automatically redirected to the nearest
alternative TEP.
o Load balancing in order to have a uniform resource share.
Morelli, et al. Expires January 10, 2005 [Page 18]
Internet-Draft Advanced IPv6 IX model July 2004
o Facility for the scalability of new TEPs.
In general, the IX seems to be a good place to provide transition
mechanisms, and even not just one, but a set of them which can be
used by different hosts, in different scenarios connected to ISPs
collocated in the IX.
In addition to that, the IX can be used as a policy distribution
service for the managed auto-transition [13], as a kind of helper to
increase the performance of the transition at a large. For instance
given the fact that a broker located into the IX has real-time
information about the associated TEPs implemented on different ISP,
this information should be utilized by the auto-transition mechanisms
in order to select the best one.
The combination of services like DNS, AAA, anycast, within the IX,
together with transition, provide a perfect framework and
facilitates:
o The scalability of the transition mechanisms.
o The automation of the discovery and selection of the "best
performing" transition mechanism and its parameters.
o The management of the transition service.
o Avoid deploying transition mechanism in every ISP, but providing
the service to all the users (depending on the defined ISP
policy).
6.3 Support and policy-based management services
The goal of policy-based management is to enable network, service and
application control and management on a high abstraction layer. The
administrator specifies rules that describe domain-wide policies
independent of the implementation of the particular network node,
service or application. It is then the policy management
architecture that provides support to transform and distribute the
policies to each node and thus to enforce a consistent configuration
in all involved elements, which is a prerequisite for achieving end
to end security services, for example.
Use of policies is an intrinsically layered approach allowing several
levels of abstraction. There can be, for example, general policies
expressing an abstract business goal, and on the other end there can
be policies that express a rather specific, device or service
dependent rule. In fact, one of the current research issues in
Morelli, et al. Expires January 10, 2005 [Page 19]
Internet-Draft Advanced IPv6 IX model July 2004
policy management is the refinement of high-level goals into
implementable policies.
Policy rules are independent of a specific device and implementation,
but define in abstract terms a desired behaviour. They are stored
and interpreted by the policy framework, which intent to provide a
consistent behaviour in all affected policy enforcement points.
As IX models become more complex with increased functionalities, will
required the more management and then the support of Policy Based
Management Network will certainly be fundamental.
6.4 Security services
6.4.1 PKI
One central component in the Security Architecture is the provision/
distribution of keys. In order to do that one of main component for
the support of the security services is the PKIs. They are needed in
the IPv6 world to offer cryptographic features to security services
like HTTPS, IPsec, etc. and also can be used for the securization of
the different elements appearing in the infrastructure.
6.4.2 DNSSEC
Services like DNSSEC are being used to secure DNS transactions
between clients and servers and among servers, as well as to store
cryptographic information about the entities stored in it.
Therefore, DNSSEC can be naturally used by a PKI to store the
security information of the PKI clients, offering a worldwide
distributed cryptographic storage mechanism. Using DNSSEC to store
Public Key Certificates (PKC) and Certificate Revocation Lists (CRL),
an IPv6 user can easily find the public certificate associated to
other person/entity by means of a simple DNS request, in order to
exchange information in a secure way.
6.4.3 Distributed security
With the deployment of IPv6 networks a revision of existent security
models and architectures is a must. As new paradigms and
applications enabled by IPv6 end-to-end appears the security
infrastructure must be ready.
The IPv6 Distributed Security model [14][15] goal is to move the
Security Policy Enforcement Point (PEP) to the end device to be
protected. This is accomplished by the distribution of the security
policy to the PEP from a central Policy Decision Point (PDP). Three
main elements are needed:
Morelli, et al. Expires January 10, 2005 [Page 20]
Internet-Draft Advanced IPv6 IX model July 2004
1. Security Policy definition language.
2. Security Policy distribution protocol.
3. Unique and secure identification of entities.
As the Distributed Security involves policy distribution the IX could
be used as a repository for Security Policies. Even different
repositories could be located in an IX, acting as the PDP, and share
some security information and alerts.
The fact that an IX will also have IPv4 connectivity could enhance
the collaboration between IPv6 and IPv4 Security Policies
repositories.
Even some business case could be foreseen if the up-dated last-minute
security policy distribution service is charged to some users.
6.5 Other services
TBD.
7. Conclusions
This advanced IPv6 IX model could be described closer to an advanced
Point of Presence (PoP) instead of just a traditional IX, when
considering that it provides services and addresses to the customers.
A traditional PoP can also provide addresses, being the difference
that in the advanced IPv6 IX model, the addresses are assigned by the
IX itself and consequently do not change even if the customer of the
IX changes its provider.
The model could be further extended to groups of advanced IX and/or
distributed IX.
8. Security Considerations
This memo does not add any new security implication.
TBD.
9. IANA Considerations
This document requests no action for IANA.
[[note to RFC-editor: this section can be removed upon publication.]]
Morelli, et al. Expires January 10, 2005 [Page 21]
Internet-Draft Advanced IPv6 IX model July 2004
10. Acknowledgements
This memo is result of the work done in the Euro6IX project. The
authors would also like to acknowledge the inputs from Ivano
Guardini, Miguel A. Diaz, Alvaro Vives, Gabriel Lopez, Jose A.
Garcia, Jose L. Rubio and the European Commission support in the
co-funding of the Euro6IX project, where this work is being
developed.
11 Informative References
[1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[2] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast
Address Format", RFC 2374, July 1998.
[3] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001.
[4] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh
routing", RFC 1863, October 1995.
[5] Bhatia, M., "Advertising Equal Cost Multi-Path (ECMP) routes in
BGP", draft-bhatia-ecmp-routes-in-bgp-00 (work in progress),
May 2003.
[6] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
Policy-based Admission Control", RFC 2753, January 2000.
[7] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[8] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[9] Finseth, C., "An Access Control Protocol, Sometimes Called
TACACS", RFC 1492, July 1993.
[10] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[11] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
3068, June 2001.
[12] Palet, J. and M. Diaz, "Evaluation of v6ops Auto-discovery for
Morelli, et al. Expires January 10, 2005 [Page 22]
Internet-Draft Advanced IPv6 IX model July 2004
Tunneling Mechanisms", draft-palet-v6ops-tun-auto-disc-01 (work
in progress), June 2004.
[13] Palet, J. and M. Diaz, "Evaluation of IPv6 Auto-Transition
Mechanism", draft-palet-v6ops-auto-trans-00 (work in progress),
April 2004.
[14] Vives, A. and J. Palet, "IPv6 Security Problem Statement",
draft-vives-v6ops-ipv6-security-ps-00 (work in progress), April
2004.
[15] Palet, J., Vives, A., Martinez, G. and A. Gomez, "IPv6
distributed security requirements",
draft-palet-v6ops-ipv6security-00 (work in progress), March
2004.
[16] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A.
Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 2000.
[17] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May
1990.
[18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
Authors' Addresses
Mario Morelli
Telecom Italia Lab.
???
Torino
IT-????? - Italy
Phone: +????
Fax: +???
EMail: mario.morelli@tilab.com
Morelli, et al. Expires January 10, 2005 [Page 23]
Internet-Draft Advanced IPv6 IX model July 2004
Jordi Palet Martinez
Consulintel
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
David Fernandez Cambronero
Technical Univ. of Madrid (UPM)
Ciudad Universitaria s/n
Madrid
E-28040 - Spain
Phone: +34 91 549 57 00
Fax: +34 91 336 73 33
EMail: david@dit.upm.es
Antonio F. Gomez Skarmeta
University of Murcia (UMU)
Campus de Espinardo s/n
Murcia
E-30071 - Spain
Phone: +34 968 364 607
Fax: +34 968 364 151
EMail: skarmeta@um.es
Morelli, et al. Expires January 10, 2005 [Page 24]
Internet-Draft Advanced IPv6 IX model 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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Morelli, et al. Expires January 10, 2005 [Page 25]