Academic Paper Writing Service http://StudyHub.vip/An-IPv6-Internet-Exchange-Model--Lesson 👈

1. An IPv6 Internet Exchange Model.
Lessons from Euro6IX project.
Mario Morelli David Fernandez Antonio Skarmeta Jordi Palet
Telecom Italia University of Madrid University of Murcia Consulintel
mario.morelli@tilab.com david@dit.upm.es skarmeta@dif.um.es jordi.palet@consulintel.es
Abstract
This paper aims to describe the main outputs of the
work carried out inside the IST Euro6IX project with
particular reference to a new possible architectural
Internet Exchange model. This model is based on the
IPv6 hierarchical and aggregatable routing and
addressing model permitting to enhance the IX
functionalities by proposing to directly assign
addresses to IX customer’s networks. In addition,
being an Internet Exchange a focal point where traffic
is concentrated, several networks and application
services benefit from the fact of being partial or totally
offered from an IX (e.g., security, AAA, QoS, multicast,
mobility, PKI, DNSSEC or policy provision) that could
also facilitate the deployment of IPv6 and their
required transition mechanisms.
1. Introduction
Since beginning, Internet Exchanges (IX in the
following) played a key role in the development of
Internet and, all over the Europe, a lot of them have
been deployed with the main goal to increase
interconnection level between ISPs. An IX is usually
based on a layer 2 infrastructure, fully redundant and
made of high performance switches, where ISPs’
routers connect to. Moreover, IXs do not usually
provide any layer 3 services to their customers (apart
from route servers or AAA or multicast, normally
offered by each ISP).
Additionally, IX’s customers are large ISPs and,
normally, small customers (like enterprises or small
ISPs) getting access trough an ISP receiving an
address block from them.
In the advanced IPv6 IX model studied inside the
Euro6IX project, a different approach is being
reporting, based on the possibility to directly assign
IPv6 addresses to the customers. Connectivity
provision and IPv6 address assignment are now
separated concepts 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. due to 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).
New IX functionality enabling this capability has been
called Layer Three Mediation Function (L3MF), as it
provides the decoupling (or mediation) among the
customers and the LHPs.
LHP1 LHPm
…
Value
Added
Services
L3MF
IX R R
Long Haul Providers
RC1
RCn
…
…
R R
…
RP1
IXLC1
IXLCn
…
Regional Providers
IXRC1
IX Customers
RPk
IXRCk
…
Figure 1
Moreover with this model 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
2. Address Delegation
Address delegation is one of the main functions to be
offered by an advanced IPv6 IX. IX administrators
will request their corresponding Regional Internet
Registry (RIR) one or more address prefixes, basically
Proceedings of the The 2005 Symposium on Applications and the Internet Workshops (SAINT-W’05)
0-7695-2263-7/05 $20.00 © 2005 IEEE

2. following the same rules defined for ISPs or, as they
are named, Local Internet Registries (LIR).
Technically, the IX will behave as it was a LIR, being
assigned by the registries one or more /32 or even
shorter prefixes, further reassigning the addresses to
the customers of the IX. L3MF will be the basic
functional entity managing address delegation service
in the IX being in charge of announcing the IX
prefix(es) to the ISPs peering on the IX, organizing the
routing among IX customers and ISPs, implementing
address delegation associated services, like provider
selection and multihoming. It is important to keep in
mind that, in order to keep routing scalability, IX
prefix(es) must be announced aggregated to the IPv6
Internet through the ISPs peering on the IX, since
unaggregated prefixes assigned to IX customers must
not be redistributed outside the IX. The only way to
exert some control over the incoming path is to allow
the distribution of IX customer’s unaggregated
prefixes. However, that can only be done if they are
distributed to a limited scope, for example, through 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. Typically, L3MF will be
implemented using BGP protocol (e.g. properly
modifying the NEXT_HOP BGP attribute to avoid
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 nextly mentioned.
3. Route Server
Another service that it is commonly found on IXs is
the route server to manage in a centralized and
optimised way the routes advertised among the peers.
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. Two types of route servers
may be deployed:
x Transparent Route Server, which propagates
all the routes received from any router to the
rest of routers, without modifying route
attributes.
x Smart Route Server, which is an “intelligent”
BGP daemon performing best path selection
on behalf of client routers using 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 an
announce, it applies the appropriate policies
before inserting them into the Loc-RIB
corresponding to each client.
Second type seems the most appropriate for the
advanced IX model purposes, due to the following
reasons:
x It does not need any modification to route
server clients BGP implementations (any
currently available BGP implementation will
suffice for ISP and customer routers).
x 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.
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.
4. AAA service
AAA infrastructure can be deployed in an IX
service network to offer authentication, authorization
and accounting services using DIAMETER according
to different approaches:
x 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
Proceedings of the The 2005 Symposium on Applications and the Internet Workshops (SAINT-W’05)
0-7695-2263-7/05 $20.00 © 2005 IEEE

3. network connection using the local AAA server
sited in the IX service network.
x 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.
x 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.
x 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.
x IX provides AAA Translation Service
Supposing the common situation, in which the ISPs
have a RADIUS or TACACS+ system used to
authenticate users, the IX can offer a 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.
5. Security Services
One central component in the Security Architecture
is the provision/distribution of keys thanks to 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. Additionally, 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.
Moreover, since with the deployment of IPv6
networks a revision of existent security models and
architectures is a must, a new paradigms and
applications enabled by IPv6 end-to-end must be
ready. This approach called IPv6 Distributed Security
model moves 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:
x Security Policy definition language.
x Security Policy distribution protocol.
x 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. Other services
New Internet Exchanges models here described can
be used also to place all those services that take benefit
from the user aggregation taking place in the Internet
Exchange. Inside the Euro6IX project a lot of services
have been studied to be adapted in such a scenario. For
example, some example could be a Rendez Vous Point
router for the Multicast among the ISPs or a
Management station to monitor the traffic between the
peers or again all the servers required in video-
conference tools or SIP Proxy for SIP-based
communication between partners. Inside the Euro6IX
project DNSSec servers have been taken into account
to be placed inside IX location.
7. Conclusions
Proceedings of the The 2005 Symposium on Applications and the Internet Workshops (SAINT-W’05)
0-7695-2263-7/05 $20.00 © 2005 IEEE

4. Aim of this paper was to summarize the main
operational results obtained inside the Euoro6IX IST
project. Two main results can be here reported:
Internet Exchange are able to assign addresses and to
provide services to their users. Indeed it should be
recognized that 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. In fact 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 or
distributed IX.
8. References
[1] Morelli et al., draft-v6ops-ix-ipv6-00.txt
[2] Hinden, R. and S. Deering, "An IPv6 Aggregatable
Global Unicast Address Format", RFC 2374, July 1998.
[3] RFC 2753 “A Framework for Policy-based Admission
Control” R. Yavatkar, D. Pendarakis, R. Guerin. January
2000
[4] “A BGP/IDRP Route Server alternative to a full
mesh routing”, RFC 1863.
Proceedings of the The 2005 Symposium on Applications and the Internet Workshops (SAINT-W’05)
0-7695-2263-7/05 $20.00 © 2005 IEEE