Internet Draft V. Ksinant (ed.)
<draft-ksinant-v6ops-isp-analysis-00.txt> 6WIND
Expires: April 2004 P. Savola
CSC/FUNET
A. Baudot
France Telecom
M. Blanchet
Hexago
M. Lind
Telia Sonera
Soohong Daniel Park
SAMSUNG Electronics
October 2003
Analysis of Transition Mechanisms
for Introducing IPv6 into ISP Networks
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.
Abstract
In a companion document, different scenarios for the introduction of
IPv6 in an IPv4 ISP network are described.
This document analyses these ISP scenarios and evaluates the
suitability of the already defined transition mechanisms in this
context. Known challenges are also identified.
Ksinant et al. Expires - April 2004 [Page 1]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
Table of Contents
1. Introduction.............................................. 2
1.1 Goal and scope of the document........................ 2
1.2 Terminology used...................................... 3
2. Analysis of the ISP transition scenarios.................. 4
2.1 Stages and transitions between stages................. 4
2.2 Identification of the actions required................ 5
3. Core Transition actions................................... 5
3.1 Steps in transitioning core networks.................. 5
3.2 Configuration of core equipment....................... 6
3.3 Routing............................................... 6
3.4 Multicast............................................. 8
4. Access transition actions................................. 8
4.1 Steps in transitioning access networks................ 8
4.2 Access control requirements........................... 10
4.3 Configuration of customer equipment................... 10
4.4 Traceability.......................................... 11
4.5 Multi-homing.......................................... 11
4.6 Filtering in the access network....................... 11
5. Exchange points actions...................................
6. Back-Office actions....................................... 12
7. Security Considerations................................... 12
1. Introduction
1.1 Goal and scope of the document
When an ISP deploys IPv6, its goal is to provide IPv6 connectivity
to its customers. The new IPv6 service must be added to an already
existing IPv4 service and the introduction of the IPv6 must not
interrupt this IPv4 service. The case of an IPv6-only service
provider is not addressed in this document.
The ngtrans working group of the IETF has designed some transition
mechanisms which aim at introducing IPv6 in generic IPv4 networks.
Taking an ISP specific point of view, [ISP_SCENARIOS] discusses a
small set of scenarios for the introduction of IPv6 in an ISP IPv4
network. The goal of the present document is to evaluate the
suitability of the existing transition mechanisms in the context of
these deployment scenarios.
Ksinant et al. Expires - April 2004 [Page 2]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
Like [ISP_SCENARIOS], the present document is focused on services
that include both IPv6 and IPv4 and does not cover issues surrounding
an IPv6-only service. It is also outside the scope of this document
to describe different types of access or network technologies.
Last, this document does not cover deeply issues which are important
when deploying IPv6, but which do not have a strong impact on the
evaluation of existing transition mechanisms. This is for instance
the case of:
- issues arising when applying for IPv6 addresses from RIR,
- the definition of addressing plans,
- the set up of support and technical processes.
1.2 Terminology used
The terminology used in this document corresponds to the one defined
in the [ISP_SCENARIOS] document. For clarity, a few terms are defined
below:
"CPE" : Customer Premise Equipment
"PE" : Provider Edge equipment
"Access" : This is the part of the network which is used by a
customer when connecting to an ISP network. It
includes the CPEs, the last hop links and the parts
of the PE interfacing to the last hop links.
"Core" : This is the rest of the ISP network infrastructure.
It includes the parts of the PE interfacing to the
core backbone, the core routers of the ISP and the
border routers used in order to exchange routing
information with other ISPs (or other administrative
entities).
"Back Office" : This is the part of the ISP network which hosts the
services required for the correct operation of the
ISP network. It usually includes DNS servers, Radius
servers, monitoring and configuration applications...
"Dual network": A network which supports natively both IPv4 and IPv6.
Ksinant et al. Expires - April 2004 [Page 3]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
2. Analysis of the ISP transition scenarios
2.1 Stages and transitions between stages
[ISP_SCENARIOS] defines four transition stages:
- Launch: This stage corresponds to an IPv4 only ISP with IPv4
customers. This is the most common case today and has
to be the starting point for the introduction of IPv6.
- IPv6 Core: This stage corresponds to an ISP with an IPv4 and IPv6
core, but the access network is only IPv4 capable. The
customers using IPv6 services have IPv4 and IPv6
capabilities.
- IPv6 Access: This stage corresponds to an ISP with an IPv4 only
core, but with access networks which support IPv4 and
IPv6. The customers using IPv6 services have IPv4 and
IPv6 capabilities.
- Complete: This is the final step in introducing IPv6, at least
in the scope of this document. The ISP has then native
support for IPv6 and IPv4 in both core and access
networks.
[ISP_SCENARIOS] also describes the possible transitions between
stages. The next figure sums up these transitions:
+-------------> IPv6 Core ----------->+
| |
Launch ----------------------------> Complete
| |
+-------------> IPv6 Access --------->+
When looking at these transitions, it appears that it is possible to
split the work required by each transition in a small set of actions.
Each action is mostly independent from the others and some actions
may be common to several transitions.
Below, these actions are first identified and in a second step, they
are described more in details.
Ksinant et al. Expires - April 2004 [Page 4]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
2.2 Identification of the actions required
The analysis of the possible transitions leads to a small list
of actions:
* Core transition actions:
- Connect dual access networks to other IPv6 networks through
an IPv4 core,
- Transform an IPv4 core in a dual one. This action can be
performed directly or through intermediate steps,
* Access transition actions:
- Connect IPv6 customers to an IPv6 core through an IPv4
network,
- Transform an IPv4 access network in a dual one,
* Exchange points actions,
* Bring support of IPv6 in the back-office.
More detailed descriptions of each action follow.
3. Core Transition actions
3.1 Steps in transitioning core networks
In terms of physical equipment, backbone networks consist mainly in
core and edge high-speed routers. Border routers provide peering
with other providers. Filtering, routing policy and policing type
functions are generally managed on border routers.
The initial step is an IPv4-only core, and the final step is a whole
dual-stack core. In between, intermediate steps may be identified:
Tunnels Tunnels
IPv4-only ----> or ---> or + DS -----> Full DS
IPv6 dedicated IPv6 dedicated routers
links links
The first step involves tunnels or dedicated links but existing
routers are left unchanged. Only a small set of routers then have
IPv6 capabilities. Configured tunnels are adequate for use during
this step. They can be can be setup through the use of tunnel broker
or through another mean of router configuration.
Ksinant et al. Expires - April 2004 [Page 5]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
When MPLS is already deployed in the backbone, it may be desirable
to provide IPv6-over-MPLS connectivity. However, the problem is that
setting up an IPv6 Label Switched Path (LSP) requires some signaling
through the MPLS network. Currently, there is no direct mechanism to
do this for IPv6. A workaround is to use BGP for signaling and/or
perform IPv6-over-IPv4-over-MPLS encapsulation, as described in
[BGPTUNNEL]. More analysis is needed on what is the right approach
in this case.
In the second step, some dual stack routers are added in this
network in a progressive manner.
The final stage is reached when all or most routers are dual-stack.
According to many reasons (technical, financial, etc), an ISP may
move forward from step to step or reach directly the final one. One
of the important criteria in this evolution is the number of IPv6
customers the ISP gets on its initial deployments. If few customers
connect to the first IPv6 infrastructure, then the ISP is likely to
remain on the initial steps for a long time.
In short, each step remains possible, but no one is mandatory.
3.2 Configuration of core equipment
In the core, the number of devices is small and IPv6 configuration
mainly deals with routing protocols parameters, interface addresses,
loop-back addresses, ACLs...
These IPv6 parameters are not supposed to be automatically
configured.
3.3 Routing
ISPs need routing protocols to advertise the reachability and to
find the shortest working paths both internally and externally.
OSPFv2 and IS-IS are typically used as an IPv4 IGP.
RIPv2 is typically not in use in operator networks.
BGP is the only IPv4 EGP. Static routes are used in both.
Note that it is possible to configure a given network so that it
results in having an IPv6 topology different from the IPv4 topology.
For example, some links or interfaces may be dedicated to IPv4-only
or IPv6-only traffic, or some routers may be dual-stack while some
others maybe single stacked (IPv4 or IPv6). In this case, the routing
must be able to manage multiple topologies.
Ksinant et al. Expires - April 2004 [Page 6]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
3.3.1 IGP
Once the IPv6 topology has been determined the choice of IPv6 IGP
must be made: either OSPFv3 or IS-IS for IPv6. RIPng is less
appropriate in many contexts and is not discussed here. The IGP
typically includes the routers' point-to-point and loop-back
addresses.
The most important decision to make is whether one wishes to have
separate routing protocol processes for IPv4 and IPv6. Having them
separate requires more memory and CPU for route calculations e.g.
when the links flap. On the other hand, the separation provides a
better reassurance that if problems come up with IPv6 routing, they
will not affect IPv4 routing protocol at all. In the first phases
if it is uncertain whether joint IPv4/IPv6 networks work as intended,
having separate processes may be desirable and easier to manage.
Thus the combinations are:
- Separate processes:
o OSPFv2 for IPv4, IS-IS for IPv6 (-only)
o OSPFv2 for IPv4, OSPFv3 for IPv6, or
o IS-IS for IPv4, OSPFv3 for IPv6
- The same process:
o IS-IS for both IPv4 and IPv6
Note that if IS-IS is used for both IPv4 and IPv6, the IPv4/IPv6
topologies must be "convex", unless the Multiple-topology IS-IS
extensions [MTISIS] have been implemented. In simpler networks or
with careful planning of IS-IS link costs, it is possible to keep
even non-congruent IPv4/IPv6 topologies "convex".
Therefore, the use of same process is recommended especially for
large ISPs which intend to deploy, in the short-term, a fully
dual-stack backbone infrastructure. If the topologies are not
similar in the short term, two processes (or Multi-topology
IS-IS extensions) are recommended.
The IGP is not typically used to carry customer prefixes or external
routes. Internal BGP (iBGP), as described in the next section, is
most often deployed in all routers to spread the other routing
information.
As some of the simplest devices, e.g. CPE routers, may not implement
other routing protocols than RIPng, in some cases it may be
necessary to also run RIPng in a limited fashion in addition to
another IGP, and somehow redistribute the routing information to the
other routing protocol(s).
Ksinant et al. Expires - April 2004 [Page 7]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
3.3.2 EGP
BGP is used for both internal BGP and external BGP sessions.
BGP can be used for IPv6 with Multi-protocol extensions
[RFC 2858], [RFC 2545]. These enable exchanging both IPv6 routing
information as establishing BGP sessions using TCP over IPv6.
It is possible to use a single BGP session to advertise both IPv4
and IPv6 prefixes between two peers. However, typically, separate
BGP sessions are used.
3.3.3 Routing protocols transport
IPv4 routing information should be carried by IPv4 transport and
IPv6 one by IPv6 for several reasons:
* The IPv6 connectivity may work when the IPv4 one is down (or vice-
versa).
* The best route for IPv4 is not always the best one for IPv6.
* The IPv4 logical topology and the IPv6 one may be different
because, the administrator may want to use different metric
values for one physical link for load balancing or tunnels may be
used.
3.4 Multicast
Currently, IPv6 multicast is not a strong concern for most ISPs.
However, some of them consider deploying it.
Multicast is achieved using PIM-SM and PIM-SSM protocols. These also
work with IPv6.
Information about multicast sources is exchanged using MSDP in IPv4,
but it is not defined, on purpose, for IPv6. An alternative
mechanism is to use only PIM-SSM or an alternative mechanism for
conveying the information [EMBEDRP].
To be completed.
4. Access transition actions
4.1 Steps in transitioning access networks
Access networks are generally composed of a large number of CPEs
connected to a small set of PEs. Transitioning this infrastructure
to IPv6 can be made in several steps, but some ISPs may avoid some
of the steps depending on their perception of risks.
Ksinant et al. Expires - April 2004 [Page 8]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
Connecting IPv6 customers to an IPv6 core through an IPv4 network
can be considered as a first careful step taken by an ISP in order
to provide IPv6 services to its IPv4 customers. More, some ISPs
also provide IPv6 services to customers who get their IPv4 services
from another ISP.
This IPv6 service can be provided by using tunneling techniques.
The tunnel may terminate at the CPE corresponding to the IPv4
service or in some other part of the customer's infrastructure
(for instance, on a IPv6 specific CPE or even on a host).
Several tunneling techniques have already been defined: configured
tunnels with tunnel broker, 6to4, Teredo...
The selection of one candidate depends largely on the presence or
not of NATs between the two tunnel end-points, and whether the
user's IPv4 tunnel end-point address is static or dynamic.
In most cases, 6to4 and ISATAP are incompatible with NATs and
an UDP encapsulation for configured tunnels has not been specified.
Firewalls in the way can also break these types of tunnels. The
administrator of the firewall will have to create a hole for the
tunnel. It is not a big deal as long as the IPv6 ISP controls the
firewall. This is more painful, although not impossible in other
cases.
An ISP has practically two kinds of customers in the access networks:
small end users (mostly "unmanaged networks"; home and SOHO users),
and others. The former category typically has a dynamic IPv4 address
which is often NATted; a reasonably static address is also possible.
The latter category typically has static IPv4 addresses, and at least
some of them are public; however, NAT traversal or configuring the
NAT may be required to reach an internal IPv6 access router, though.
The first category, the unmanaged tunneling scenarios will be
discussed in a companion document [UNMANCON]; the discussion is not
duplicated here until some form of consensus is found.
For the second category, usually:
* Configured tunnels as-is are a good solution when an NAT is not
in the way and the IPv4 end-point addresses are static. A
mechanism to punch through NATs or to forward packets through
it may be desirable in some scenarios. If fine-grained access
control is needed, an authentication protocol needs to be used.
* A tunnel brokering solution, to help facilitate the set-up of
a bi-directional tunnel, has been proposed: the Tunnel Set-up
Protocol. Whether this is the right way needs to be determined.
* Automatic tunneling mechanisms such as 6to4 or Teredo are not
applicable in this scenario.
Ksinant et al. Expires - April 2004 [Page 9]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
Some other ISPs may take a more direct approach and avoid the use of
tunnels as much as possible.
Note that when the customers use dynamic IPv4 addresses, the
tunneling techniques may be more difficult at the ISP's end,
especially if a protocol not including authentication (like PPP for
IPv6) is not used. This may need to be considered in more detail
with tunneling mechanisms.
4.2 Access control requirements
Access control is usually required in ISP networks because the ISPs
need to control to who they are giving access. For instance, it is
important to check if the user who tries to connect is really a
valid customer. In some cases, it is also important for billing
purposes.
However, an IPv6 specific access control is not always required. This
is for instance the case when a customer of the IPv4 service has
automatically access to the IPv6 service. Then, the IPv4 access
control also gives access to the IPv6 services.
When the provider does not wish to give to its IPv4 customers
automatically access to IPv6 services, a specific access control for
IPv6 must be performed in parallel to the IPv4 one. It does not mean
that a different user authentication must be performed for IPv6, but
the authentication process may lead to different results for IPv4
and IPv6 access.
Access control traffic may use IPv4 or IPv6 transport. For instance,
Radius traffic related to an IPv6 service can be transported over
IPv4.
4.3 Configuration of customer equipment
The access networks are composed of CPEs and PEs. Usually, each PE
connects a large number of CPEs to the core network infrastructure.
This number may reach tens of thousands or more. The configuration
of CPEs is an heavy task for the ISP and this is even made harder as
the configuration must be done remotely. In this context, the use of
auto-configuration mechanisms is very beneficial, even if manual
configuration is still an option.
The parameters that usually need to be automatically provided to the
customers are:
- The network prefix delegated by the ISP,
- The address of the Domain Name System server (DNS),
- Some other parameters such as the address of an NTP server may
also be needed sometimes.
Ksinant et al. Expires - April 2004 [Page 10]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
When access control is required on the ISP network, DHCPv6 can
provide the configuration parameters. This is discussed more in
details in [DUAL ACCESS].
When access control is not required (unusual case), a stateless
mechanism could be used, but no standard definition exists at the
moment.
4.4 Requirements for Traceability
Most ISPs have some kind of mechanism to trace the origin of traffic
in their networks. This has also to be available for IPv6 traffic.
This means that specific IPv6 address or prefix has to be tied to a
certain customer, or that records of which customer had which
address/prefix must be maintained. This also applies to the
customers with tunneled connectivity.
This can be done for example by mapping a DHCP response to a
physical connection and storing this in a database. It can also be
done by assigning a static address or prefix to the customer.
For any traceability to be useful, ingress filtering must be
deployed towards all the customers.
4.5 Multi-homing
Customers may desire multihoming or multi-connecting for a number of
reasons [RFC3582].
Multihoming to more than one ISP is a subject still under debate.
Deploying multiple addresses from each ISP and using the addresses
of the ISP when sending traffic to that ISP is at least one working
model; in addition, tunnels may be used for robustness [RFC3178].
Currently, there are no provider-independent addresses for end-sites.
Multi-connecting more than once to just one ISP is a simple
practice, and this can be done e.g. with BGP with public or private
AS numbers and a prefix assigned to the customer.
To be further defined as the multihoming situation gets clearer.
4.6 Filtering in the access network
Ingress filtering must be deployed everywhere towards the customers,
to ensure traceability, prevent DoS attacks using spoofed addresses,
prevent illegitimate access to the management infrastructure, etc.
The ingress filtering can be done for example using access lists or
Unicast Reverse Path Forwarding (uRPF). Mechanisms for these are
described in [BCP38UPD].
Ksinant et al. Expires - April 2004 [Page 11]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
5. Exchange points actions
To reach an exchange point, an ISP uses IPv6 native or configured
tunnels. Private peering can be achieved the same way.
A layer-2 exchange point is agnostic to IP versions. The peering
can be done IPv6 native. A layer-3 exchange point is IP version
specific, where configured tunnels can be used over non-dual stack
routers.
To be completed.
6. Back-Office actions
ISPs maintain hosts for supporting and managing the network. The
standard set of hosts include DNS servers, authentication servers
(RADIUS, AAA or TACACS) and network management servers.
One of the most important tasks is to provide monitoring of IPv6
connectivity. It is imperative to ensure that the IPv6 core and
access networks are working without problems. Typically one runs a
routing protocol everywhere in the core network: one possibility is
monitoring whether the routing protocol adjacencies remain up or
not; another way may be using "ping" to test the reachability in
the networks. There are many other ways to achieve the effect.
Servers are usually distributed to strategic locations for diversity
purposes. These servers must be protected from unwanted external
access.
In a first step, the services can be provided over an IPv4 transport.
For instance, the DNS traffic corresponding to IPv6 entries can be
transported over IPv4 without any problems.
In a second step, IPv6 transport can be provided.
7. Security Considerations
This document analyses scenarios and identifies some transition
mechanisms that could be used for the scenarios. It does not
introduce any new security issues. Security considerations of each
mechanism is described in the respective documents.
References
[ISP_SCENARIOS] Lind, M., "Scenarios for Introducing IPv6 into ISP
Networks" - draft-lind-v6ops-isp-scenarios-01.txt
[EMBEDRP] Savola, P., Haberman, B., "Embedding the Address of
RP in IPv6 Multicast Address" -
draft-ietf-mboned-embeddedrp-00.txt
Ksinant et al. Expires - April 2004 [Page 12]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
[MTISIS] Przygienda, T., Naiming Shen, Nischal Sheth, "M-ISIS:
Multi Topology (MT) Routing in IS-IS"
draft-ietf-isis-wg-multi-topology-06.txt
[RFC 2858] T. Bates, Y. Rekhter, R. Chandra, D. Katz,
"Multiprotocol Extensions for BGP-4"
RFC 2858
[RFC 2545] P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing"
RFC 2545
[BCP38UPD] F. Baker, P. Savola "Ingress Filtering for Multihomed
Networks"
draft-savola-bcp38-multihoming-update-01.txt
[RFC3582] J. Abley, B. Black, V. Gill, "Goals for IPv6 Site-
Multihoming Architectures"
RFC 3582
[RFC3178] J. Hagino, H. Snyder, "IPv6 Multihoming Support at Site
Exit Routers"
RFC 3178
[BGPTUNNEL] J. De Clercq, G. Gastaud, D. Ooms, S. Prevost,
F. Le Faucheur "Connecting IPv6 Islands across IPv4
Clouds with BGP"
draft-ooms-v6ops-bgp-tunnel-00.txt
[DUAL ACCESS] Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi
"A Model of IPv6/IPv4 Dual Stack Internet Access
Service"
draft-shirasaki-dualstack-service-02.txt
[UNMANCON] T.Chown, R. van der Pol, P. Savola, "Considerations for
IPv6 Tunneling Solutions in Small End Sites"
draft-chown-v6ops-unmanaged-connectivity-00
Ksinant et al. Expires - April 2004 [Page 13]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Ksinant et al. Expires - April 2004 [Page 14]
INTERNET DRAFT Analysis of IPv6 Transition for ISP October 2004
Acknowledgements
This draft has benefited from inputs by Jordi Palet.
Authors' Addresses
Vladimir Ksinant
6WIND S.A.
Immeuble Central Gare - Bat.C
1, place Charles de Gaulle
78180, Montigny-Le-Bretonneux - France
Phone: +33 1 39 30 92 36
Email: vladimir.ksinant@6wind.com
Pekka Savola
CSC/FUNET
Espoo, Finland
EMail: psavola@funet.fi
Alain Baudot
France Telecom R&D
42, rue des coutures
14066 Caen - FRANCE
Email: alain.baudot@rd.francetelecom.com
Marc Blanchet
Hexago
2875 boul. Laurier, suite 300
Ste-Foy, Quebec, G1V 2M2
Canada
Phone: +1-418-266-5533
Email: Marc.Blanchet@hexago.com
Mikael Lind
TeliaSonera
Vitsandsgatan 9B
SE-12386 Farsta, Sweden
Email: mikael.lind@teliasonera.com
Soohong Daniel Park
Mobile Platform Laboratory, SAMSUNG Electronics.
416, Maetan3-Dong, Paldal-Gu, Suwon, Gyeonggi-Do, Korea
EMail: soohong.park@samsung.com
Ksinant et al. [Page 15]