IST-2000-25153 Deliverable D1 “Specification and Architecture of the Network Available IPv6 communications, gateways and components”
Contractual Date of Delivery to the European June 2001 Commission: Actual Date of Delivery to the European Commission: July 2001 Editor(s): Dr Raimo Vuopionperä (Ericsson Research Finland) Participant(s): WP3 members Workpackage : 3 Title of Deliverable: Specification and Architecture of the Network, Available IPv6 communications, gateways and components Security: Int Nature: O Version: Final Number of pages: 49
Abstract: The Deliverable specifies the requirements for networks and their services arising out of the different applications that will be pursued in the project. It analyses the status of the IPv6 stack implementations in different operating systems (BSD, Linux, Solaris and Windows) and Routers (Ericsson, 6WIND, Cisco, Juniper and Hitachi). It considers the status of the different wireless technologies (WLAN, Bluetooth, GPRS and UMTS). The status of various IP network services is analysed – Virtual Private Nets, Quality of Service, Network Servers, IPv6/IPv4 Interworking and connecting IPv6 islands. Finally, certain features are identified, which must be provided soon; these are Tunnelling IPv6 over GPRS, Multi-access and securing Mobile IPv6 control messages. To ease readability, a Glossary is appended.
Keywords: IPv6, protocol stacks, wireless network technologies, server technologies Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031 Executive Summary
As indicated in the 6WINIT Technical Annex, the purpose of Deliverable 1 is to "specify the network architecture and services that will be adopted in 6WINIT, taking account of the current status of the services, the availability of equipment, and the relevant support from the communications carriers". The work-package should identify also what components are available, and which are missing but required.
With this document, the question of the Availability of IPv6 Communications, Gateways and Components is addressed. The status of the different IPv6 stacks, IPv6 implementations, characteristics of gateways, and of any other components are expected to be needed by applications - as available at the beginning of the project - is also surveyed.
In other words the main purpose of this document is to analyse the present situation and highlight the areas which need to be studied in more detail in the later stages of the 6WINIT project. The main task of this study is to highlight the urgent development needs which need to be performed in order to make the 6WINIT project successful in its later stages.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 2/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
Table of Contents 1 Introduction ...... 5 2 The Initial Platform Requirements...... 6 2.1 Requirement for The Clinical Site ...... 6 2.1.1 Clinical Network ...... 6 2.1.2 General Application: ...... 6 2.1.3 Computing Environment ...... 7 2.1.4 Detailed Requirements ...... 7 2.2 Weather Station...... 8 2.3 Areal Spatial Information in Mobile Application...... 8 2.4 Mobile E-Commerce for Wireless Terminals ...... 9 2.5 Multi-access ...... 10 2.5.1 Introduction ...... 10 2.5.2 Experimental IPv6 Network...... 10 2.5.3 Detailed Requirements ...... 11 2.6 Multimedia Conferencing Application...... 12 2.6.1 Platforms ...... 12 2.6.2 Gateways ...... 12 2.7 Meeting Room Scenario ...... 13 2.7.1 Terminals...... 13 2.7.2 Routers ...... 13 2.7.3 Software platform...... 13 2.7.4 Gateways ...... 14 2.8 Road Warrior ...... 14 3 The Status of IPv6 Enabled Servers and Terminals ...... 15 3.1 BSD...... 15 3.1.1 FreeBSD ...... 15 3.1.2 NetBSD...... 16 3.2 Linux...... 17 3.2.1 SuSe Distribution ...... 18 3.2.2 Red Hat...... 19 3.2.3 Embedded Linux systems ...... 20 3.3 Solaris ...... 21 3.4 Windows ...... 22 4 The Status of IPv6-Enabled Routers ...... 22 4.1 Gateways and Routers Provided by Partners...... 22 4.1.1 Ericsson Telebit...... 22 4.1.2 6WIND IP Edge Device ...... 26 4.2 Other Gateways and Routers ...... 27 4.2.1 Cisco...... 27 4.2.2 Juniper...... 28 4.2.3 Hitachi...... 28 5 The Status of Networks Needed by the Application ...... 28 5.1 Bluetooth...... 28
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 3/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
5.1.1 Bluetooth basics ...... 28 5.1.2 IPv6 support...... 30 5.1.3 Available implementations ...... 30 5.2 WLAN...... 30 5.2.1 Lucent's Orinoco WLAN...... 30 5.2.2 Cisco’s Aironet WLAN ...... 31 5.3 GPRS ...... 32 5.3.1 System Introduction ...... 32 5.3.2 Current status ...... 33 5.4 UMTS ...... 34 5.5 Mobility ...... 34 6 The Status of Network Supporting Services...... 35 6.1 VPN & certificate management...... 35 6.1.1 IP security architecture ...... 36 6.1.2 Public Key Infrastructures (PKI)...... 37 6.2 QoS ...... 38 6.2.1 Integrated Services ...... 38 6.2.2 Differentiated Services ...... 38 6.3 Network Servers ...... 39 6.3.1 DHCPv6 ...... 39 6.3.2 DNS...... 39 6.4 IPv6 / IPv4 Inter working...... 39 6.4.1 Technologies...... 40 6.5 Connecting IPv6 Islands...... 41 6.5.1 Technologies...... 42 6.5.2 Supported in Partners Components ...... 43 7 Urgent development needs...... 44 7.1 Tunnelling IPv6 over GPRS...... 44 7.2 Multi-access ...... 45 7.2.1 The need for multi-access ...... 45 7.2.2 Existing solutions...... 46 7.2.3 Work needed...... 46 7.3 Securing Mobile IPv6 Control Messages ...... 46 8 Acronyms and Abbreviations...... 48
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 4/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
1 INTRODUCTION
The aim of this document is to analyse the initial requirements of the 6WINIT Network Architecture. These include the mapping of the Initial Platform requirements, the Status analysis of the existing IPv6 Enabled Network Nodes (Servers, Terminals, and Routers) and the Network Supporting Services as well as the analysis of the requirements imposed by the planned Applications.
In the Platform requirements and Network Nodes status analysis, the needs of the whole 6WINIT network Architecture are outlined, especially the needs of the Clinical side which poses stringent requirements for the planned 6WINIT Network. The capability mappings of the IPv6 Enabled Network Nodes as well as the requirement analysis of the Access Technology dependent Applications and Network Supporting Services give us a baseline for future 6WINIT networks. In the course of the analysis performed in this document few areas are identified, which need to be urgently developed in order to make the planned 6WINIT Network Architecture functional. The recognised urgent development areas are the need for IPv6 multi-access solutions, IPv6 tunnelling in GPRS and early UMTS core networks and Securing of the Mobile IPv6 Control messages.
The need for IPv6 multi-access solutions is most notable in the area of Clinical applications, where the Clinical Applications need to have uninterrupted communications in all situations independent of the network. Furthermore, the handoffs from different access networks need to be fully automatic and smooth to ensure no patient-critical data is lost in the case that certain network access is suddenly unavailable. One such situation might happen when an ambulance carrying patient moves outside of a WLAN access network and the connection must be swiftly switched from WLAN to a GPRS/UMTS connection.
The question of IPv6 tunnelling in GPRS and early UMTS networks is critical, since in both cases the networks are designed to be IPv4 based. This situation is not expected to change during the 6WINIT project although the later releases of the UMTS Networks will be IPv6 compatible. The most critical issues concerning IPv6 tunnelling over GPRS/UMTS networks are connected to the problems arising from the "Always On" situation which cause, for example, address allocation and spectrum efficiency problems.
Securing of the Mobile IPv6 Control messages is also of great importance and the 6WINIT project should contribute to the work, which is being carried out in the IETF to solve these problems.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 5/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
2 THE INITIAL PLATFORM REQUIREMENTS
2.1 Requirement for The Clinical Site
2.1.1 Clinical Network
Deploying their "Guardian-Angel-System" - GANS - in 6WINIT UKT-RUS want to show the transmission of potentially high-bandwidth multimedia and vital data from an ambulance car to a hospital. In the hospital is a receiving centre, where experienced doctors will immediately help the colleague outside to manage the problems of the emergency patient.
2.1.2 General Application:
The patient is connected to a vital sign monitor (ECG, blood pressure, oxygen saturation etc.). There will be at least one video camera to give pictures of the patient treatment scenario. The audio signals will be recorded by at least one microphone. Also the picture and voice of the remote doctor may be involved. These data streams are connected to the remote interface unit, which will perform all necessary transformation to the IPv6-protocol. Then comes the transmission process, which is different from version to version (see below). At the other end is the local interface unit, which transforms the received IPv6 into data streams to make them visible to the local doctor in the GANS- Centre. Of course the transmission can be bi-directional.
For the whole project the patient will always be the realistic patient-simulator of UKT.
The final networking scenario for the UKT Guardian Angel System is depicted in the following figure:
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 6/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
UKT – RUS GANS Mobile Scenario
6Winit Partners The Internet G-WiN - GEANT
DTAG UKT Tübingen/RUS Stuttgart GANS Local (Test) Centre
RR RR RR IP subnets IP subnet IP subnet IP subnet DTAG GPRS & 802.11 WLAN GPRS GPRS UKT/RUS 802.11 WLAN
RUS Projects Communication Systems BeWü Development 16. – 18.05.01 . 4
Figure 1: UKT Guardian Angel Mobile Scenario
2.1.3 Computing Environment
Within 6WINIT, the GANS application will be isolated from other application in the hospital. A possible integration with the clinical information system is for further studies. The UKT network will be only used to transport signals from the GANS centre to the outer world and back (clinical network, University of Tübingen network, ..., DTAG GPRS service, ambulance car).
Servers will preferably be based on LINUX or Windows 2000.
End-systems will preferably be Windows 2000 based.
The "Clinical Workstation" will be an Agilent patient monitor system V.24/V.26. Using the so-called MECIF application protocol the vital data are transferred via a serial line to an Bluetooth-equipped notebook
2.1.4 Detailed Requirements
2.1.4.1 Platforms · Windows 2000 · Linux USAGI or SuSe distribution
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 7/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
· Some PDA not specified Compaq iPAQ with Linux DelphiPAD with Linux 2.1.4.2 Gateways · IPv6 in IPv4 Tunnelling · Connecting IPv6 islands by tunnelling · ALG (Application Layer Gateways) · Firewall
2.2 Weather Station
The weather station consists of a number of sensors (e.g. wind, temperature, air pressure, etc.) and an embedded computer installed on a tripod. Its main network requirements are wireless access, reliability of the communication and easy configuration. Reliability in this context means that the information is accessible when it is needed and that the communication is secured (integrity of the data is ensured and communicating parties are authenticated).
By its design, IPv6 should be able to address the requirement of auto-configuration (IP addresses, DNS servers etc.) easily. In the first phase of the development, the focus is on getting the system IPv6 enabled without security features. Later the security issues may be managed on the application or network levels using SSL or IPSec – it depends upon the availability of the components which of these is selected.
The weather station is currently equipped with an IPv4 over WLAN access – GPRS may be tried later as well. Installing both network types on the same weather station would possibly improve the transmission reliability.
The weather information is currently delivered through an HTTP server. In addition to this, Telnet, FTP and/or SSH services are needed for maintenance purposes.
There are several options for hardware on which the weather station can be run:
Processor Memory size Mass storage Distribution(s) Motorola Dragonball/15MHz 8 MB 1 MB (Flash) uClinux 486/66MHz 16 MB 16 MB (Flash) White Dwarf 586/133MHz 64 MB 136 MB (Flash) RedHat
From the client point of view, the weather station can be used with any normal IPv6 capable HTTP client. Web browsers are already available for fixed desktop computers as well as for laptops but it would be valuable to be able to use the weather station application also on a handheld device (on a Compaq iPAQ, for example).
2.3 Areal Spatial Information in Mobile Application
The using of various areal spatial information in mobile applications demonstrates possible ways of implementing location-based services on wireless terminals. One service considered is a map service where the customer is able to get information about hotels and attractions of the area (e.g. downtown of a city) by browsing a map and clicking links appearing on that area map. However, this service will be based on a platform, which is expected to be generic enough so that it is able to support other kinds of services as well.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 8/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
Figure 2: Areal Spatial Information service Network Layout
The basic IPv6 test network will consist of WLAN access points used as base stations for accessing the location services. GPRS connection may be considered later as the technology becomes available. Another technology that will be used as a support to the services in a larger area is the HSCSD that uses multiple GSM channels for communication.
The services will need the information of customer's location to be able to adapt intelligently to user's current context. At the first stage the intention is to use a GPS receiver for acquiring the position information. Later we will also study the possibility of using WLAN based positioning, as it is also suitable for services in indoor environments.
The exact set of terminals and software is to be specified later. Both laptop and PDA environments will be examined; the laptops may be more suitable for the first stage testing. There would be a map browser available for the Palm operating system if only IPv6 support were available on that platform.
2.4 Mobile E-Commerce for Wireless Terminals
Mobile e-commerce in this context means hard security services, e.g. banking services. The current versions of Internet-banking and m-commerce applications are running on IPv4. Security is normally provided by the use of SSL. The definition and requirements of mobile e-commerce are still under consideration. However, the general requirements can already be stated.
One suggestion for the m-commerce application is mobile payment. In this kind of system there are three main parties with different roles. These main roles are the Customer, the Operator and the Merchant. The operator offers service to multiple Merchants. At the end user role in this application are the Customers. Customers are private persons who want to access content services using a particular terminal device or devices. There is a direct connection between the customer and the merchant, which is used for the delivery of the content. Connection with the operator takes care of identification and payment. The roles are shown in the figure below.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 9/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
Customer Merchant
Operator
Authentication Payment
Figure 3: Mobile Payment
At the customer end there will be a terminal, which is a PDA, laptop or mobile phone. On the terminal there has to be IPv6 support and an Internet browser. Connection to the operator is made through a WLAN or GPRS network. Security is a key issue in this application. However, it is still unspecified whether IPSec, SSL or some other relevant technique will be used.
2.5 Multi-access
2.5.1 Introduction
To make Internet access possible, different kinds of access technologies are used. These include both fixed (LAN, ADSL, etc.), and wireless connections (GPRS, UMTS, WLAN, etc.). The increasing amount of different access technologies, together with their different availability/coverage and other characteristics, has created the need for Multi-access – an ability to use several network interfaces simultaneously in a terminal and control the placement of connections in these interfaces (and access networks) depending on the location of the mobile terminal and other characteristics.
NomadicLab (Ericsson Research Finland) is implementing a Multi-access extension to the Mobile IPv6 protocol. This Multi-access Mobile IPv6 will provide the possibility of separating single connections between two nodes and route them through different network interfaces, based on a user- defined connection management policy. At any time, connections can be handed over from one interface to another. Several different interfaces (and access networks) can also be used in parallel.
As the Multi-access Mobile IPv6 is implemented at the IP/Network Layer, it is transparent to upper layers, including user applications.
2.5.2 Experimental IPv6 Network
The figure below presents an overview of the experimental network that has been built for Multi- access research and demonstration purposes. A mobile terminal can roam between the different access networks using Multi-access Mobile IPv6.
In this experimental network, Multi-access Mobile IPv6 is run on a Linux platform over LAN, WLAN, and GPRS interfaces. IPv6 over IPv4 tunnelling is used in the GPRS subnet.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 10/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
IPv6-over-IPv4 tunnel
GPRS Access Network
GPRS GPRS IPv6 tunnel Base Station GGSN terminating server
IPv6 Backbone
WLAN Access Network
BS AR IPv6 Mobile IPv6 (wlan) Router Home Agent
MT BS
AR (fixed)
Fixed LAN Access Network
AR (wlan) Access Router for the Wireless LAN network AR (fixed) Access Router for the fixed LAN network MT Mobile Terminal supporting several access network types
Figure 4: Overview of the experimental network
The hardware used in the above network includes: · GPRS network (incl. BS, BSC, SGSN, GGSN and HLR) · GPRS phone with serial connection (later Bluetooth) · IPv6 capable router · PC-based servers (with FreeBSD and Linux operating systems) · Terminals with multiple interfaces (laptops and PDAs with LAN and WLAN PC- Cards, and serial connection to a GPRS phone)
2.5.3 Detailed Requirements
The Multi-access Mobile IPv6 is implemented on the Linux platform, therefore the Mobile IPv6 Home Agent server and all terminals have to use the Linux operating system.
2.5.3.1 Servers
In addition to GPRS hardware and IPv6 routers, the only server required by the system is the Mobile IPv6 Home Agent. This has to be a reasonable PC-based server running Linux operating system and Multi-access Mobile IPv6.
A PC-based server running FreeBSD operating system is required to terminate the IPv6-over-IPv4 tunnel behind the GGSN.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 11/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
2.5.3.2 Terminals
Multimode terminals are required to use the system. These can be, for example, laptop PCs with multiple network interfaces (i.e. LAN PC-Card, WLAN, PC-Card, and a GPRS phone through a serial connection). All PC-Cards have to support standard IPv6 and the Linux operating system.
Terminals need to run the Linux operating system and Multi-access Mobile IPv6. In addition, a Multi- access Control application is required in terminals to set-up and to control local connection management policies.
2.5.3.3 Networks
To make effective use of Multi-access, several access networks are required. When using a GPRS network, an IPv6-over-IPv4 tunnel has to be configured terminating at the terminal and right behind the GGSN, as shown in Figure 4.
2.6 Multimedia Conferencing Application
The multimedia conferencing application demonstrates the use of conferencing applications and supporting gateways over heterogeneous networking environments.
Conferencing applications include the use of real-time video and audio streams, plus shared media tools for collaborative working on text and graphics. The tools support a number of technologies to combat loss and heterogeneity in networks such as Forward Error Correction (FEC) schemes for audio, and reliable multicast protocols for the collaborative tools. Additionally the tools currently provide application level encryption facilities. All the tools operate over IPv4 and IPv6.
For access to media streams from wireless networks the media gateways will be required to transcode media formats; filter and rate adjust traffic, with the option of header compression.
These gateways, and potentially the tools to a lesser degree, will incorporate support for policy-based control and configuration.
Support for conference announcements may be provided via multicast announcements or via the UCL secure conference store.
For more details on these applications see Deliverable 2.
2.6.1 Platforms · Windows 2000/NT4 ([MSDN, MSR] IPv6) · Linux 2.2.X, 2.4.X · Solaris 8 · FreeBSD 3.X (KAME), 4.X
2.6.2 Gateways · Transcoding active gateway (TAG) · Audiogate , Stargate
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 12/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
2.7 Meeting Room Scenario
In the meeting room scenario, a number of users with wireless LAN (802.11b) devices are able to join an ad hoc network. The network will comprise both the users’ devices (e.g. laptop or PDA equipment) and other “fixed” devices present in the room (e.g. devices capable of displaying media streams). The fixed devices, which may include media sources, may exist on a local Ethernet LAN. The wireless network will consist of one or more 802.11b wireless access points, but we also envisage investigation of direct point-to-point ad hoc communication between wireless devices.
The scenario will encompass streamed media and seamless wandering activities within WP4, in that the scenario aims to demonstrate streamed media (e.g. MP3 audio) being received by the user devices. It also aims to demonstrate a user being able to broker the use of other devices in the room, e.g. the ability to redirect a video stream to an alternative display device.
In the presence of multiple wireless access points each located on separately routed IPv6 subnetworks in the same building, we aim to demonstrate the ability for streamed media to follow the mobile user seamlessly as they roam between those subnets.
In order to make use of the devices in the meeting room, the systems architecture will need to be able to use a service discovery protocol such as SLP, the Service Location Protocol (RFC2609, RFC3111). Location awareness for users and devices within the meeting room is also desirable, with infra-red and short range RF equipment offering possible solutions. An active location infrastructure, as provided by “active badge” technology, is not foreseen within the scope of the project scenario.
The scenario will include consideration of the intrusiveness of communications between devices in the meeting room, e.g. the basis/rules upon which to interrupt a meeting for a given event/message.
The glue for the components will be the Southampton Framework for Agent Research (SoFAR), which provides the basis for ontologies and meta-knowledge of the meeting room to be made available to communicating IPv6 agents. Server-oriented and peer-to-peer methods will be developed and compared.
2.7.1 Terminals · Fixed infrastructure devices, e.g. Ø PC hosting display device, running Linux or FreeBSD Ø Video sources, feeding RTP streams Ø Smart whiteboard devices
· Portable wireless LAN (802.11b) devices Ø 802.11b wireless access point Ø A laptop PC with an 802.11b PCMCIA card Ø Compaq iPAQ PDA running Linux and IPv6
2.7.2 Routers · IPv6 router with required protocol support, e.g. FreeBSD router with Ø KAME and unbundled Mobile IPv6 stack Ø KAME integrated IPv6 Protocol Independent Multicast (PIM-SM).
2.7.3 Software platform · Java-based agent framework
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 13/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
Ø Southampton Framework for Agent Research (SoFAR), including facilities for ontology implementation and agent-based service brokering. Ø SoFAR will use the Sun Java JDK 1.4 with IPv6 support · Media streaming software tools, e.g. Ø MP3 audio streaming software, as previously developed in 6INIT or through packages such as Icecast. Ø IPv6 RTP (e.g. rtptrans) and vic/rat tools.
2.7.4 Gateways · Transcoding gateways Ø for fixed Ethernet to wireless LAN adaptation (see also conferencing tool requirements). · Proxy servers Ø Protocol proxies (e.g. web proxies and e-mail relays) may be adapted for content modification and protocol interworking purposes. 2.7.4.1 Other equipment/requirements · Devices enabling location-awareness Ø Short range infra-red devices Ø Short-range RF devices · Service Location Protocol Ø Device discovery
2.8 Road Warrior
In its generic form, the Road Warrior application is a VPN extended to mobile users. For fixed users, an IPSec VPN is established by connecting two or more IPSec gateways, each protecting the communication from user networks behind the gateway. The gateways use their IP addresses to set up and identify secure communication channels between them. For the integration of mobile users this concept has to be enhanced, as mobile users dynamically change their IP addresses. Therefore a new mechanism has to be defined for setting up secure communication channels to those mobile users, and to deal with the high frequency of secure communication channel generation and deletion.
For our purposes, a "Road Warrior" is any machine that does not have a fixed IP address where it can normally be expected to be on line. This includes: · a traveller who might connect from anywhere; · any machine that has a dynamic IP address, e.g. dialup connections; · Most home machines connecting to the office. The configuration for Road Warrior support looks slightly different from a VPN configuration. We cannot use the Road Warrior's IP address in the configuration file since we don't know it, and we don't want to have our server retrying connections to Road Warriors that are no longer online. Therefore we have to use means other than IP addresses for identifying and authenticating roaming users.
The Road Warrior application doesn't use Mobile IP to support mobility. Actually it's not seamless mobility in the same sense as it is offered by Mobile IP. The Road Warrior's mobility is not transparent for protocol layers above IP. The focus of the Road Warrior application is to provide secure access to IPSec gateways for roaming users.
The Road Warrior application has no major requirements regarding the network. Of course, as for most other applications some reasonably high bandwidth is preferable. As we intend to provide the Road Warrior on a Linux platform, we will support Ethernet interfaces in a first step. Later, strongly
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 14/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
depending on the availability of hardware and drivers for Linux, we will look on the possibility running the Road Warrior over wireless links (e.g. GPRS, WLAN) or ISDN.
3 THE STATUS OF IPV6 ENABLED SERVERS AND TERMINALS
3.1 BSD
OpenBSD 2.7, NetBSD 1.5, BSD/OS 4.0, FreeBSD 4.0 or later have integrated IPv6 stacks. The KAME project has integrated MobileIPv6 code from Ericsson although this is now being demerged in preparation for a merging of MIPv6 code releases from Ericsson, NEC and Keio University, Tokyo. After the MIPv6 code is merged, it will be remerged with the KAME distribution. In the meantime, the Ericsson MIPv6 code will be made available as a patch to the KAME distribution.
The status of the IPv6 implementation is almost the same in the various BSD-based systems. This section describes only FreeBSD and NetBSD, as we haven’t used the other variants.
Both FreeBSD and NetBSD are configured by adding the desired settings into /etc/rc.conf (to override the default configuration defined in /etc/defaults/rc.conf). Both operating systems include the basic tools (ifconfig, netstat, route,...) to configure a host or router as well as the common services (ftp, ssh,...).
To summarise the differences between FreeBSD and NetBSD: · FreeBSD 4.x doesn't support RPC services (e.g. NFS) over IPv6, while the forthcoming FreeBSD 5.x will support it and NetBSD 1.5.1 already supports it; · FreeBSD 4.x and later have an IPv6 firewall (ip6fw) while NetBSD 1.5.1 doesn’t have an IPv6 firewall. NetBSD 1.5W (the development version) has an IPv6 firewall (ipf); · FreeBSD 4.x has a command to configure network interface prefixes in routers manually while in NetBSD 1.5.1 the whole IPv6 has to be configured manually. This is not a real problem as this affects only nodes acting as routers.
3.1.1 FreeBSD
IPv6 enabled services in FreeBSD 4.3: Service Description finger & fingerd Finger client and daemon
ftp & ftpd FTP client and daemon
Ifconfig Interface configuration tool
Inetd Internet super daemon
ip6fw IPv6 firewall
gif Generic tunnel network device for tunnelling
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 15/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
netstat Display network status
ping6 Ping
route Manipulate the routing tables
route6d RIP6 Routing Daemon
rtadvd Router advertisement daemon
rtsol & rtsold Router solicitation client and daemon
sendmail Mail server
ssh & sshd Secure Shell client and daemon
start-up scripts Configuration stored in /etc/rc.conf
telnet & telnetd Telnet client and daemon
IPv6 enabled services in the FreeBSD ports collection (/usr/ports): Service Description Location Apache Apache web server www/apache13+ipv6
Bind Nameserver net/bind9
ethereal Network analyser net/ethereal
mozilla Web browser www/mozilla+ipv6
postfix Mail server mail/postfix
3.1.2 NetBSD
IPv6 enabled services in NetBSD 1.5.1: Service Description finger & fingerd Finger client and daemon
ftp & ftpd FTP client and daemon
ifconfig Interface configuration tool
inetd Internet super daemon
Gif Generic tunnel network device for tunnelling
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 16/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
netstat Display network status
ping6 Ping
route Manipulate the routing tables
route6d RIP6 Routing Daemon
RPC Remote procedure calls (used by NFS, ...)
rtadvd Router advertisement daemon
rtsol & rtsold Router solicitation client and daemon
sendmail Mail server
ssh & sshd Secure Shell client and daemon
start-up scripts Configuration stored in /etc/rc.conf
telnet & telnetd Telnet client and daemon
IPv6 enabled services in the NetBSD 1.5.1 package collection (/usr/pkgsrc): Service Description Location apache Apache web server www/apache6
bind Nameserver net/bind9
ethereal Network analyser net/ethereal
Inn News server news/inn
mozilla Web browser www/mozilla
postfix Mail server mail/postfix
3.2 Linux
Support for IPv6 under Linux depends entirely on the distribution in question. Up-to-date information can be found at the distribution status page:
http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-distributions.html.
SuSe 7.1, RedHat 7.1 and PLD 1.0Ra are the most fully supported distributions at the time of writing. The USAGI project at www.linux-ipv6.org is providing advanced IPv6 code for Linux. A comparison of standards’ conformance is available at
http://www.linux-ipv6.org/tahitest/summary-index.html
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 17/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
IPv6 in Java – The public beta release from Sun was released in spring 2001. For more information about release JavaTM 2 SDK, Standard Edition, v 1.4.0 Beta, see URL http://java.sun.com/j2se/1.4/index.html. Fully integrated Java release is expected in autumn 2001.
3.2.1 SuSe Distribution
IPv6 support in SuSe Linux has been enable for some time. In version 7.1 of SuSe Linux, quite a lot of applications and utilities are IPv6 enabled. The following paragraphs try to give an overview of the status of IPv6 support in SuSe Linux 7.1. In each paragraph all tools/utilities/server which support IPv6 and important tools which still lack IPv6 support are listed.
3.2.1.1 Basics
This paragraph deals with the IPv6 support in the kernel, start-up-scripts and basic interface configuration utilities. A short description is given for each listed package.
Package Name Description Ipv6 Remark arp Tool supporting arp Yes hostname Tool for hostname configuration Yes ifconfig Tool for interface configuration Yes kernel Linux kernel Yes netstat Tool to display various tables Yes ping6 Ping with support for IPv6 Yes rarp Tool supporting rarp route Tool for route manipulation Yes start-up scripts The IPv6 config is stored in inet6cfg. Yes Limited support for IPv6 configuration up to now yast SuSe configuration utility Yes yast2 SuSe configuration utility (graphical No user interface)
3.2.1.2 Server/Daemons
This paragraph deals with the IPv6 support of server and daemons. A short description is given for each listed package.
Package Name Description Ipv6 Remark Apache 2.0 Apache web server Yes bind Nameserver Yes Bind 9 fingerd Finger daemon Yes ftpd FTP daemon Yes inetd Internet super daemon Yes inn News server No ppp PPP daemon Yes radvd Router Advertisement Daemon Yes sendmail Mail server Yes sshd Secure shell daemon Yes tcpd TCP wrapper Yes telnetd Telnet daemon Yes
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 18/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031 thttpd Web server Yes xinetd Internet super daemon Yes zebra Routing daemon Yes Supports RIPng
3.2.1.3 Clients/Applications
This paragraph deals with the IPv6 support in clients, applications and other tools. A short description is given for each listed package.
Package Name Description IPv6 Remark bind-utils DNS-utilities, resolver yes IPv6-DNS-transport supported ethereal Snuffer yes finger Finger client yes ftp FTP client yes ircII IRC client yes lukemftp FTP client yes mozilla Web browser yes mutt E-mail client yes ncftp FTP client no netscape6 Web browser yes ssh Secure shell client yes telnet Telnet client yes tin News client yes w3m Text based web browser yes
3.2.2 Red Hat
IPv6 support in RedHat Linux is rather good as well, especially within the core system and network applications. However, the distribution version of RedHat does not fully support IPv6. Some application programs are still IPv4 only. The following paragraphs give an overview of the status of IPv6 support in RedHat Linux 7.0. In each paragraph all servers/tools/utilities that support IPv6 and important tools still lacking IPv6 support are listed.
3.2.2.1 Basics
This paragraph deals with the IPv6 support in the kernel, start-up-scripts and basic interface configuration utilities. A short description is given for each listed package.
Package Name Description IPv6 Remark Arp Tool supporting arp yes Hostname Tool for hostname configuration yes Ifconfig Tool for interface configuration Kernel Linux kernel yes Netstat Tool to display various tables yes ping6 Ping with support for IPv6 yes Rarp Tool supporting rarp Route Tool for route manipulation start-up scripts The IPv6 config is stored in inet6cfg. yes Limited support for IPv6 configuration up to now xxx Xxx xxx
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 19/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
3.2.2.2 Server/Daemons
This paragraph deals with the IPv6 support of server and daemons. A short description is given for each listed package. Package Name Description IPv6 Remark apache Apache web server no unofficial IPv6 patch available bind Nameserver yes Bind 9 fingerd Finger daemon yes ftpd FTP daemon yes inetd Internet super daemon yes inn News server no ppp PPP daemon yes radvd Router Advertisement Daemon yes sendmail Mail server yes sshd Secure shell daemon yes tcpd TCP wrapper yes telnetd Telnet daemon yes thttpd Web server yes xinetd Internet super daemon yes 3.2.2.3 Clients/Applications
This paragraph deals with the IPv6 support in clients, applications and other tools. A short description is given for each listed package. Package Name Description IPv6 Remark bind-utils DNS-utilities, resolver yes IPv6-DNS-transport supported ethereal Sniffer yes finger Finger client yes ftp FTP client yes ircII IRC client yes lukemftp FTP client yes mozilla Web browser yes mutt E-mail client yes ncftp FTP client no netscape4 Web browser no ssh Secure shell client yes telnet Telnet client yes tin News client yes w3m Text based web browser yes
3.2.3 Embedded Linux systems
Embedded systems are computers that are integrated within other equipment in such a way that the user is often unaware of the computer's presence. Usually the embedded systems are made as small as possible lacking many of the facilities expected on a traditional computer. Software for embedded systems has to be able to run in a small amount of memory, processor speed and power consumption. Small capacity flash disks often replace hard disks. The systems may also have real-time requirements.
The growth of the Internet has made the embedded market explode. The number of products requiring embedded technology and the number of new applications for embedded devices has grown.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 20/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
Embedded Linux has been of widespread interest recently. Its targets include internet/network appliances, network servers, routers, firewalls, gateways, etc. There are a lot of devices already on the market and in varying stages of development. Some of those projects are disclosed publicly, some not. There are Linux-based handhelds and PDAs, Web-phones, TV set-top boxes/devices, Web-pads, Internet radios and audio systems.
There is no single Embedded Linux but a wide range of distributions for different purposes and hardware combinations. As in full-grown Linux distributions, the availability of IPv6 support in embedded Linux systems is dependent of following components: · Kernel, which is the core of the operating system containing the protocol stacks, IPv6 among others. Many embedded Linux systems use stock kernels of version 2.2 or higher where IPv6 is available. However, in some cases there may be problems, as some hardware requires heavily patched kernels, which may not support IPv6. · Run time libraries that provide network API for applications. Glibc and dietlibc do support IPv6. Some distributions are still using older libc 5, which doesn't support IPv6 without patching. A small footprint uClibc has no support for IPv6 · Applications that use the network or are used to configure networks. Some distributions consist of the same software as full-blown distributions. Some use tailored or special-purpose software which is not likely to support IPv6. The table below provides a snapshot of available distributions, which may be of interest to 6WINIT project. None of them has announced IPv6 support but most of them can be updated to support it.
Distribution Kernel Libraries Remarks White Dwarf Linux 2.2 libc 5 Embedded PC Boards, includes a stripped down (www.whitedwarflinux.org/) Apache 1.2 and other network daemons uClinux 2.4 (patched) uClibc Supports microcontrollers that don't have memory (www.uClinux.org/) management units ETLinux 2.0 (2.2 soon) glibc Includes a CGI capable web-server, email server and (www.prosa.it/etlinux/) Corba support RTLinux (miniRTL) 2.2 glibc 2.0 Real-time Linux running on a minimum system, includes (www.rtlinux.org/) a mini_httpd server LRP 2.2 Linux Router Project, a networking-centric micro- (www.linuxrouter.org/) distribution LEM No kernel, put glibc 2.1 Based on Mandrake 6.1 (www.linux-embedded.org/) your own PeeWeeLinux 2.2 (enhanced) Configurable distribution for a variety of applications (www.peeweelinux.com/) (e.g. router or thin client) Midori-Linux-Project 2.4 glibc 2.2 Developed for energy-efficient Linux-based devices, like (midori.transmeta.com) Internet appliances
3.3 Solaris
Sun Microsystems include IPv6 as part of their current Solaris 8 OS release. Basic applications, included as part of Solaris, such as ping, telnet, traceroute, etc. are IPv6 aware. Additionally the Solaris naming services NIS, NIS+ are also IPv6 aware. DNS works in the same manner as the Microsoft implementation in that all messages are sent over IPv4. Work to add other IPv6 features is currently being undertaken: · IPSec security - due for release summer 2001 · Mobile IPv6 - due for release 2002 · DNS Server/Resolver - currently at the planning stage
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 21/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
· PPP support - due for release summer 2001 IPv6 in Java – the public beta release from Sun was released in spring 2001. For more information about release JavaTM 2 SDK, Standard Edition, v 1.4.0 Beta, see URL http://java.sun.com/j2se/1.4/index.html. A fully integrated Java release is expected in autumn 2001.
3.4 Windows
Microsoft has a freely available technology preview of their IPv6 stack, which can be downloaded from:
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp
The Microsoft IPv6 stack is for the Windows 2000 platform. Our experience of the IPv6 stack has been favourable. Testing has been limited by the application support, which currently covers tools such as ping, traceroute, telnet, and ftp, and there is also a patch for Internet Explorer to enable IPv6 usage. Full support for IPv6 DNS does not exist - all DNS messages are via IPv4 transport. The technology preview also provides support for developers who wish to develop or migrate applications to IPv6. The first commercially available Windows release incorporating the IPv6 stack will be the next release, Windows XP, not expected to appear until 2002. This release will include (and not affect the functionality of) the existing IPv4 stack and features. The XP release is aimed at providing an IPv6 stack for application developers to use to port their applications. The release after next (Blackcomb) will have IPv6 support for Microsoft applications, making an IPv6 only configuration possible.
Microsoft, in collaboration with the University of Lancaster, is also developing a Mobile IPv6 implementation for Windows. This is currently available for evaluation on the Windows 2000 platform. The work is presently at research level; there are no published plans to release it, either as part of the technology preview or within a commercial operating system release.
4 THE STATUS OF IPV6-ENABLED ROUTERS
4.1 Gateways and Routers Provided by Partners
4.1.1 Ericsson Telebit
Ericsson Telebit will provide two IP routers for the 6WINIT project; An extended version of the AXI 462 Ericsson Telebit router product together with a prototype IP router in the following denoted by “ The RXI 820 Prototype”, with advanced support for Mobile IPv6 and IPv4 and IPv6 Transition mechanisms. The latter can however only be provided to the project for demonstration purposes. Both routers will be perfectly suited to operate at the boundary between user LANs and WANs, but could also be used in a hierarchical setting as pictured below.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 22/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
IPv6 LAN
IPv6 LAN AXI 462 RXI 820 Prototype AXI 462 IPv6 or IPv4 Backbone RXI 820 Prototype
RXI 820 Prototype IPv6 LAN
IPv6 LAN
4.1.1.1 The Ericsson Telebit Router
The Ericsson Telebit AXI 462 Integrated Multiprotocol Router and ATM Switch is well suited for stand alone routers in high speed backbone IP networks as well as for IP access routers located on the boundary between user LANs and WANs. The router supports a wide range of IP access methods including Ethernet and Token ring LAN, PPP over E1 and ATM
BASIC IP FUNCTIONALITY of the AXI 462
The AXI 462 is a dual stack IP Router and can receive and forward both IPv6 and IPv4 packets simultaneously. Moreover it supports GRE encapsulation as well as automatic and manually configured IPv6 in IPv4 tunnels.
The router supports various IP Standards. In particular, IPv6 Neighbour Discovery and IPv6 Stateless Address Configuration are supported byll media interfaces.
In addition to a proprietary IP routing protocol, the Internal Gateway Protocol (IGP), which can be used when the router is integrated in a multiprotocol network, the router supports the updating of dynamic routing tables by means of the following IP routing protocols: · RIP2 for IPv4 and RIPng for IPv6, · OSPF2 for IPv4 and OSPFv3 for IPv6, · BGP-4 for IPv4 and BGP-4+ for IPv6. Finally, the AXI 462 also have some support for IPv4 and IPv6 multicasting: The Internet Group Multicast Protocol, IGMP, for IPv4, the Multicast Listener Discovery, MLD, for IPv6 and the Protocol Independent Multicast, Sparse and Dense mode, PIM (SM + DM), for IPv6 are supported.
IP SECURITY on the AXI 462
The IP Security implementation on the AXI 462 provides transparent support for IPv6 data integrity, confidentiality and authentication between remote sites by enabling the set up of secure tunnels
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 23/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
between these sites. The security mechanism is available with DES encryption and HMAC-MD5-96 and HMAC-SHA-1-96 authentication within the IP Authentication Header (AH) and the IP Encapsulation Security Payload (ESP) in compliance with RFC 2401-6. The mechanism relies on manually established and configured session keys and Security Associations.
QUALITY OF SERVICE on the AXI 462
For IPv4 and IPv6 the Quality of Service may be controlled using the Resource Reservation Protocol (RSVP). The Implementation is based on a mapping of Controlled-Load and Guaranteed Delay Service onto the ATM 4.0 ABR and CBR service, respectively. For IPv6, the implementation makes use of the IPv6 flow label, thereby gaining a substantial performance optimisation.
On E1 Interfaces also Differentiated Services, Expedited and Assured forwarding PHB, for IPv4 and IPv6 can be used.
IPv4/IPv6 TRANSITION MECHANISMS on the AXI 462
By virtue of support for automatic and manually configured IPv6 in IPv4 tunnels, as mentioned above, the AXI462 enables end-to-end IPv6 communication between IPv6 hosts located in different “IPv6 Islands” to be set up through and via the IPv4 Backbone. The NAT-PT (Network Address Translator – Protocol Translator) algorithm, on the other hand, attempts to provide transparent routing to end-nodes in IPv6 realm trying to communicate with end-nodes in IPv4 realm and vice versa.
The NAT-PT implementation on the AXI 462 provides a bi-directional transition mechanism across the IPv4/IPv6-Boundary following static SIIT - Stateless IP/ICMP Translation Algorithm. That is, address translation is performed by adding/removing specific 96-bit prefixes to/from a 32-bit IPv4 addresses/IPv6 addresses build from IPv4 addresses. The address allocation is static, i.e., the addresses are allocated upon start-up, and the translation mechanism only supports IPv6 addresses composed from legal IPv4 addresses.
MOBILE IPv6 (MIPv6) FUNCTIONALITY on the AXI 462.
The MIPv6 Home Agent mechanisms ensures that mobile nodes are reachable by their home address regardless of their actual point of attachment to the internet and, moreover, the mechanisms enables ongoing communications to continue in spite of the movement by a mobile node from one network to another.
The AXI 462 will be available with an “add on MIPv6 Home Agent Demo version”. The MIPv6 Home Agent software implements the MIPv6 Home Agent functionalities in accordance with the IETF draft [draft-ietf-mobileip-ipv6-13.]. The implementation supports the requirements for Home Agents and corresponding MIPv6 nodes of the above draft, but with a rudimentary interworking with IP Security only. In particular, authentication of Binding Updates is not supported.
4.1.1.2 The RXI 820 Prototype
Ericsson Telebit plans to provide a prototype dual stack IP access router, the RXI 820 Prototype, with full support for mobile IPv6 and NAT-PT transition mechanisms. The router will be provided to 6WINIT for demonstration purposes. The router will be based on the RXI 820 Router product from Ericsson, which is an IP router optimised for handling the special requirements, put by IP wireless systems. The RXI router is currently under development. The RXI 820 Prototype will be based on the RXI 820 Release 2.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 24/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
The RXI 820 Prototype will support IP via Ethernet LAN together with PPP and MLPPP over E1 and will be suited to serve as an access or edge router located at the boundary between user LANs and WANs.
BASIC IP FUNCTIONALITY of the RXI 820 Prototype
The RXI 820 Prototype will be a dual stack IP Router with support for automatic and manually configured IPv6 in IPv4 tunnels, IPv6 Neighbour Discovery, IPv6 Stateless Address Configuration and various other IPv4 and IPv6 standards. The RXI 820 Prototype will support the updating of dynamic routing tables by means of the following IP routing protocols: · RIP, RIP2, CIDR for IPv4 and RIPng for IPv6; · OSPF2 for IPv4 and OSPFv3 for IPv6; · GP4 for IPv4 and BGP4+ for IPv6.
IP SECURITY on the RXI 820 Prototype
The IP Security implementation on the RXI 820 Prototype will provide full support for IPv4 and IPv6 data integrity, confidentiality and authentication. The security mechanism will be available with DES encryption and HMAC-MD5 and HMAC-SHA-1 authentication within the IP Authentication Header (AH) and the IP Encapsulation Security Payload (ESP). Furthermore, the implementation will include a full IKE implementation such that Security Associations can either be negotiated automatically via IKE or set up manually.
IPv4/IPv6 TRANSITION MECHANISMS on the RXI 820 Prototype
By virtue of the support for automatic and manually set up IPv6 in IPv4 tunnels, the RXI 820 Prototype will support communication between IPv6 Islands through the IPv4 backbone. Further, it will support the static NAT-PT functionalities provided by SIIT, which enables IPv6 hosts equipped with “IPv4 like” IPv6 addresses (i.e. addresses composed from legal IPv4 addresses) to communicate with IPv4 hosts across the IPv4/IPv6 boundary. But moreover, the RXI 820 Prototype will also be made to support Dynamic address allocation (DAT) and, in particular, also an application gateway for DNS and FTP will be provided.
Using Dynamic address translation the NAT-PT device can allocate addresses from a shared pool of IPv4 addresses on a per request basis and subsequently release the address back to the pool, when the host session terminates. Hereby a possibly large number of IPv6 addresses can share a possibly small number of IPv4 addresses. But first and foremost the translation mechanism no longer requires the IPv6 addresses to be “IPv4 like” and hence it supports all unicast IPv6 addresses.
MOBILE IPv6 (MIPv6) FUNCTIONALITY on the RXI 820 Prototype
The RXI 820 Prototype will be available with a MIPv6 Home Agent software implementing the corresponding node and home agent functionalities in accordance with the most recent IETF draft. The present draft [draft-ietf-mobileip-ipv6-13] is currently under revision in IETF, primarily because of problems with the interworking with IPSec with respect to the authentication of binding updates. The aim is to follow the work in the IETF closely and make an implementation that supports the interworking with IPSec and the authentication of binding updates in particular.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 25/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
4.1.2 6WIND IP Edge Device
The capabilities of the IP Edge Device provided by 6WIND are detailed in the Deliverable 2 (Work- Package 6).
The 6WIND IP Edge Device is Customer Premises Equipment (CPE) that includes the functions listed in the next paragraphs.
The IP Edge Device integrates advanced traffic regulation capabilities, security mechanisms, IPv4 to v6 transition functions and high level management interfaces that allow to configure easily and quickly IP services to satisfy the user’s needs.
The IP Edge Device takes place at the boundary of the backbone network. The following figure describes a typical architecture based on this equipment:
ISP OR ENTREPRISE MANAGEMENT CENTER
Remote 6WIND service configuration IP Edge Device
IPv4 or IPv6 6WIND backbone IP Edge Device
6WIND IP Edge Device
Figure 5: IP Edge device based Architectures
4.1.2.1 Available functionality
The current commercial version includes the following functions that can be used at the same, as inter-working tests have proved it in the scope of the 6INIT project: · IPSec security mechanisms for both IPv4 and IPv6; · QoS mechanisms (DiffServ model) for both IPv4 and IPv6; · IPv4 to v6 transition functions; · Other functions are included in the prototypes that are available in the 6WIND’s labs; · “Home Agent” functionality for MobileIPv6 (conformance with IETF draft-ietf- mobileip-ipv6-13 with some exceptions); · Wireless interface based on the 802.11b technology; · Header compression compliant with the RFC 2507 for IPv6 networks; · Firewall functions (IP filtering).
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 26/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
4.1.2.2 Planned functionality
Some other functionalities will be studied within the scope of 6WINIT, so that new functions required by the Partners to cope with their needs in the project will be developed. These aspects are described in the following paragraphs:
Wireless functions
The main objective is to integrate in the IP Edge Device new wireless interfaces like GPRS and UMTS for the WAN side, and 802.11 for the LAN side. With these new extensions, the IP Edge Device could act as a wireless gateway. Current interfaces are wired Ethernet cards (for the LAN) and E1/T1 (for the WAN); an ATM WAN interface will soon be available.
6WIND also aims at prototyping the advanced software functions that are defined in WP3 and that are necessary to provide users with seamless fixed-mobile access.
Using GPRS or UMTS links to interconnect IPV6 Local Area Networks over the Internet Infrastructure is an innovative approach to cope with the mobility needs of user.
Security and mobility
The 6WIND IP Edge Device will take into account the security problems between IPSec and Mobile IP.
As mobile users can be regarded as clients communicating with a partner in a home domain behind a security gateway, the IPSec implementation has to support IPSec client-gateway communication. This differs from the more distributed IPSec gateway-gateway communication mostly used in VPNs. Additionally the IPSec implementation used by the client cannot use static IP addresses for setting up security associations, but has to use dynamically assigned addresses at the actual wireless access points. As these addresses are assigned dynamically, theoretically they could be re-used by another mobile user at a later time; the lifetime of the security associations based on such addresses has to be managed carefully. 6WIND will study how to add security over the mobility and will see if the privileged location at the boundary of the network can be exploited by the Edge Device to solve the problem of security and mobility.
IPV4/V6 transition architectures
The Edge Device will also have a key role to play in transition from IPv4 to IPv6. It is clear that Mobile IPv6 has very great advantages over IPv4, and many mobile devices will implement only mobile IPv6 with no mobile IPv4. For transition, it is important that mobile IPv6 devices be able to access also IPv4 hosts. We will study how network architectures should take these functions into account and we will show how this can be achieved using the Edge Device gateway functions.
4.2 Other Gateways and Routers
4.2.1 Cisco
The first release of commercial code (only for early adopters) that includes IPv6 functionality is IOS 12.2(2) T, which was released on 7th June 2001. The details of the release are available from the Cisco web-page (http://www.cisco.com/warp/public/732/Tech/ipv6/ ).
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 27/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
4.2.2 Juniper
Juniper has announced plans in Japan for an IPv6 release in Q4-2001, which will mean IPv6 availability also in Europe, since they run the same code on all their products.
4.2.3 Hitachi
Hitachi currently provides a software upgrade to their GR2000 line of gigabit routers. This upgrade is based upon code developed by the KAME project and uses minimal hardware assistance. Hitachi claim they will shortly announce detailed plans for the release of line-rate routing for IPv6.
5 THE STATUS OF NETWORKS NEEDED BY THE APPLICATION
5.1 Bluetooth
5.1.1 Bluetooth basics
Bluetooth is a wireless communication technology using a frequency-hopping scheme in the unlicensed 2.4 GHz ISM (Industrial-Scientific-Medical) band. Two or more Bluetooth (BT) units sharing the same channel form a piconet. Within a piconet a BT unit can have either of two roles: master or slave. Within each piconet there may be only one master (and there must always be one) and up to seven active slaves. Any BT unit can become a master in a piconet.
The Bluetooth system provides full-duplex transmission built on slotted Time Division Duplex (TDD), where each slot is 0.625 ms long. The time slots are numbered sequentially using a very large number range (cyclic with a cycle of 227). Master-to-slave transmission always starts in an even- numbered time slot while slave-to-master transmission always starts in an odd-numbered time slot. An even-numbered time slot and its subsequent odd-numbered time slot (i.e. a master-to-slave time slot and a slave-to-master time slot, except when multi-slot packets are used) together are called a frame.
The communication within a piconet is organised such that the master polls each slave according to some polling scheme. With one exception a slave is only allowed to transmit after having been polled by the master. The slave will then start its transmission in the slave-to-master time slot immediately following the packet received from the master. The master may or may not include data in the packet used to poll a slave. The only exception to the above principle is that when a slave has an established SCO link (see below for explanation), it is always allowed to transmit in the pre-allocated slave-to- master time slot, even if not explicitly polled by the master in the preceding master-to-slave time slot. Transmission in a piconet is allowed exclusively between the master and a slave (and vice versa). Hence, a slave can only communicate with the master of the piconet, while the master can communicate with all the slaves. There is no way for a slave to directly address another slave.
Each BT unit has a globally unique 48-bit IEEE 802 address. This address, called the Bluetooth Device Address (BD_ADDR) is assigned when the BT unit is manufactured and it is never changed. In addition to this, the master of a piconet assigns a local Active Member Address (AM_ADDR) to each active member of the piconet. The AM_ADDR, which is only three bits long, is dynamically assigned and deassigned and is unique only within a single piconet. The master uses the AM_ADDR when polling a slave in a piconet. However, when the slave, triggered by a packet from the master addressed with the slave's AM_ADDR, transmits a packet to the master, it includes its own AM_ADDR (not the master's) in the packet header.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 28/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
Even though all data is transmitted in packets, the packets can carry both synchronous data, on Synchronous Connection Oriented (SCO) links (mainly intended for voice traffic), and asynchronous data, on Asynchronous Connectionless (ACL) links. Depending on the type of packet that is used, an acknowledgement and retransmission scheme is used (not for SCO packets transferring synchronous data) to ensure reliable transfer of data (as well as forward error correction (FEC) in the form of channel coding).
An important capability in any ad hoc networking technology is the neighbour discovery feature. This is true also for Bluetooth. Without a neighbour discovery capability a BT unit would not be able to find any other BT units to communicate with and consequently no ad hoc network would be formed. The neighbour discovery procedure in Bluetooth consists of the INQUIRY message and the INQUIRY RESPONSE message. A BT unit wanting to discover neighbouring (within radio coverage) BT units will (repeatedly according to well-specified timing and frequency sequences) transmit INQUIRY messages and listen for INQUIRY RESPONSE messages. An INQUIRY message consists of only an Inquiry Access Code. The Inquiry Access Code can be a General Inquiry Access Code (GIAC), which is sent to discover any BT unit in the neighbourhood, or a Dedicated Inquiry Access Code (DIAC), which is sent to discover only a certain type of BT units, for which a particular DIAC is dedicated.
A BT unit receiving an INQUIRY message (including the GIAC or an appropriate DIAC) will respond with an INQUIRY RESPONSE message. The INQUIRY RESPONSE message is really an FHS (Frequency Hop Synchronisation) packet. An FHS packet is also used for other purposes in a Bluetooth system, e.g. for synchronisation of the frequency hop channel sequence (that is where its name comes from). By listening for INQUIRY RESPONSE messages the BT unit that initiated the INQUIRY procedure can collect the BD_ADDR and internal clock values (both of which are included in the FHS packet) of the neighbouring BT units.
Related to the INQUIRY procedure is the PAGE procedure, which is used to establish an actual connection between two BT units. Once the BD_ADDR of a neighbouring BT unit is known (as a result of an INQUIRY procedure) the neighbouring BT unit can be paged with a PAGE message. Also knowing the internal clock value of the BT unit to be paged makes will potentially speed up the PAGE procedure, since this makes it possible for the paging unit to estimate when and on what frequency hop channel the neighbouring BT unit will listen for PAGE messages. A PAGE message consists of the Device Access Code (DAC), derived from the BD_ADDR of the paged BT unit. A BT unit receiving a PAGE message including its own DAC responds with an identical packet (i.e. including only the DAC of the paged BT unit). The paging BT unit then replies with an FHS packet, including the BD_ADDR of the paging BT unit, the current value of the internal clock of the paging BT unit, the AM_ADDR assigned to the paged BT unit and some other parameters. The paged BT unit then responds once again with its DAC and then the connection between the two BT units is established.
If the paging BT unit already was the master of a piconet, the paged BT unit has now joined this piconet as a new slave unit. Otherwise, the two BT units have just formed a new piconet with the paging BT unit as the master unit. Since the INQUIRY message does not include any information about its sender (in particular not its BD_ADDR), the BT unit that initiated the INQUIRY procedure is the only one that can initiate a subsequent PAGE procedure. Thus, the BT unit initiating an INQUIRY procedure will also be the master of any piconet that is formed as a result of a subsequent PAGE procedure. However, if considered necessary, the roles of master and slave can be switched using a master-slave-switch mechanism in Bluetooth. This, however is a complex and extensive procedure resulting in a redefinition of the entire piconet, involving also all other slave units in the piconet.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 29/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
5.1.2 IPv6 support
The Bluetooth specification consists of different profiles for different applications (the lower layers are of course common between all profiles). So far, there exists only one profile, which explicitly supports IP (v4 or v6). This is the LAN access profile, used between a laptop/PDA (etc.) and LAN access point. It uses Bluetooth RFCOMM (=serial port emulation), and on top of that PPP. Note that PPP is only used over the Bluetooth link, and terminated in the LAN access point, which transfers IP packets between the Bluetooth link and the LAN. Any protocol that runover PPP is supported, e.g. IPv6 over PPP.
The dial-up profile can also be used to transport IP. This profile is used between a laptop/PDA etc and, for example, a cellular phone or a modem. It also uses RFCOMM, and AT commands for dialling and control. It doesn't specify what protocols are used on top or RFCOMM, but clearly, PPP can be used as over any serial link/modem connection.
In addition to this, a new profile will be published soon which is designed specifically for IP networking, the Personal Area Networking (PAN) profile. This profile does not use RFCOMM, but instead defines a new protocol, Bluetooth Network Encapsulation Protocol (BNEP), which is an Ethernet emulation layer. This means that any protocol that can run over Ethernet will be supported, such as IPv6. One important function in the PAN profile is that the master in a piconet will forward packets between its slaves, both unicast packets from one slave to another, and broadcast packets from one slave (or itself) to all the others, thus hiding the point-to-point nature of Bluetooth and making one piconet look like an Ethernet link.
5.1.3 Available implementations
There are three available implementations for Linux operating system, as we know of: · Axis: http://developer.axis.com/software/bluetooth/ · IBM: http://www.alphaworks.ibm.com/tech/bluedrekar · BlueZ: http://bluez.sourceforge.net/ IBM and Axis supports RFCOMM, but BlueZ probably does not. BNEP is not available, since the PAN profile isn't published yet.
5.2 WLAN
802.11 WaveLAN technology supports native IPv6 connectivity without any special adaptation.
5.2.1 Lucent's Orinoco WLAN
The Lucent Orinoco Wireless LAN (formerly known as WaveLAN IEEE) series are 802.11b compatible products. It is completely different from the old Lucent WaveLAN and totally incompatible to the Lucent WaveLAN in term of protocol and hardware interface. It operates in the 2.4 GHz ISM band (Direct Sequence) and the new hardware support the IEEE 802.11 and 802.11b protocol.
All WaveLAN IEEE cards do not offer the exact same set of features, because Lucent keeps changing the firmware. From firmware 1.00 to 4.52, Lucent was mostly adding features (encryption, power saving) and keeping it backward compatible, but firmware 6.04 and later created a major incompatibility. Firmware 6.06 and later implement a fully 802.11 compliant IBSS Ad Hoc mode (on top of the Ad Hoc demo mode). Firmware 6.04 dropped Fragmentation Threshold setting in favour of
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 30/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
microwave oven robustness (an automatic fragmentation scheme). Firmware 6.16 did fix a few bugs with the IBSS Ad-Hoc mode (security, ESSID="any").
The Orinoco Wireless Kit supports the following scenarios: · Peer-to-peer workgroup of wireless computing devices (ad hoc mode) · Wireless connection to LAN using one or more access points. The Orinoco Access Points support bridging mode, so the Access Points and the PCMCIA Cards are completely transparent for all protocols above OSI layer two. Therefore it's no problem to use IPv6 with the Lucent Orinoco Wireless Kit.
The configuration of the Orinoco Access Points is only possible using a Windows tool. The configuration is done basically by SNMP, so an IP (currently IPv4 only) connection must be established to the access point. For that reason each access point has to be configured with an IPv4 address. But this is only necessary for the configuration. Once the configuration is done, no IPv4 access is necessary.
5.2.2 Cisco’s Aironet WLAN
An IPv6 platform using the wireless based on the 802.11b technology WLAN 6WIND’s Labs.
The WLAN kit used is the Aironet from Cisco including:
AIR-AP342E2C corresponding to the Access Point
AIR-PCI342 corresponding to the Cards
The Aironet kit has received the Wi-Fi agreement that guarantees interoperability between equipment (see http://www.iol.unh.edu/consortiums/wireless/index.html)
The platform used for the experiment is described in the following picture:
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 31/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
Figure 6: 6WIND 802.11b WLAN platform
The results of this experiment have showed that the WLAN technology like 802.11b can well be used with IPV6 networks.
Tests allowed the validation of the following functionalities: · Auto-configuration in a zeroconf network · DNS dynamic updates (used with BIND 9.1.2) · Inter-working between MobileIPv6 and DHCPv6 · … However, some functions have to be improved, especially concerning the security. The WEP (Wire Equivalent Privacy) protocol is supposed to provide security on the wireless link but disclosures are effectively possible and easy.
5.3 GPRS
5.3.1 System Introduction
GPRS is an optional feature in GSM providing a new set of bearer services for data. A bearer service can be described as a pipe that is used to transfer data from an entry point, through one or more network(s), to an exit point.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 32/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
By connecting the BSS directly to two new mobility aware routers, called GPRS Support Nodes (GSNs), in the core network, the GSM switching system is bypassed.
PSTN/ ISDN VLR MSC Um MAP-D
Gs HLR
Gr Gc Gb Gn Gi BSC SGSN GGSN IP/X.25 MT Gp TE
GGSN DNS Other PLMN
Figure 7: GPRS Network Architecture
The Serving GSN (SGSN) is on the same hierarchical level as a serving MSC/VLR and connects to the BSS. SGSN keeps track of GPRS attached MSs as they move around. The SGSN has access to a DNS for address translation.
The Gateway GSN (GGSN) is an interworking node connecting to IP (and X.25) based networks via the Gi-interface.
GGSN and SGSN are connected via an IP-based backbone interface. The application supporting network protocol packets (IP/X.25) are encapsulated and tunnelled over this backbone by the GPRS tunnelling protocol (GTP). Both GGSN and SGSN have functions for packet routing and packet charging.
The backbone interface is called Gn if the two nodes are in the same PLMN. A GSN in one PLMN connects to a GSN in another PLMN via the Gp-interface.
The SGSN is connected to the GSM HLR via the Gr-interface. The HLR holds the GPRS subscription data. The HLR may be connected to the GGSN via the optional Gc-interface.
5.3.2 Current status
In the current release of GPRS only routing of user data IPv4 packets through the GPRS core network is available. An IPv6 enabled TE must therefore encapsulate all IPv6 packets in IPv4 packets. The tunnel endpoint is located outside the GPRS network in a router with at least one interface being connected to an IPv6 network. To facilitate the tunnel configuration it is recommended that a static IPv4 address is assigned to the TE. Both private and public IPv4 addresses can be used as start and end point for the IPv4 tunnel.
During the duration of the 6WINIT project it is foreseen that IPv6 will be available. However, it is not sure that the 6WINIT project can get access to IPv6 enabled GPRS networks.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 33/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
The available bandwidth depends on the number of time slots that are supported in the terminal and by the GPRS network equipment. At the moment the Ericsson mobile phones and GPRS networks support three timeslots. Four time slots will be supported in near future. Existing terminals will then have a new software upgrade to support it.
The actual available bit rate depends on the channel coding schemes used. Normally they are in an interval of 8 – 21 Kbit/s per time slot before channel coding. It is estimated that bit rates of approximately 12 Kbit/s per time slot can be expected, i.e. 48 Kbit/s when four time slots are being used.
5.4 UMTS
The packet switched domain in WCDMA is handled in the same way as for GSM; i.e. the GPRS approach is reused. However the available bandwidth is considerably higher. For wide area coverage the available bandwidth is 384 Kbit/s and close to the base station and indoors the speed is 2 Mbit/s.
The possibility of getting access to UMTS depends on the local operators operating in the areas where the sites are located. It will depend on the deployment plans for the local operator.
An alternative solution would be to build an extra site in Stockholm (at Ericsson’s facilities) with UMTS access. To make this work we need two separate commitments; one from the 6WINIT project that we can get the required resources (in terms of hours that have to be done in order to get it to work according to our project requirements) from the 6WINIT project and the second one internally from Ericsson that they plan to do the necessary extra work that is required.
5.5 Mobility
GTP (GPRS Tunnelling Protocol) handles Handover inside GPRS and UMTS network and the mobility is hidden for the terminal. However if hand over between different access types or between two different UMTS or GPRS network is needed then MIP (Mobile IP) is needed. For this moment hand over between two different GPRS or UMTS network isn’t specified and if the terminal moves to another network the connection is released.
User IPv6 (PDP type IPv6)
Application UTRAN SGSN GGSN Terminal Server
Radio Bearer GTP-U GTP-U
Figure 8: IP packets to/from the terminal are tunnelled through the UMTS network, they are not routed directly at the IP level
Between WLAN access points and WLAN to fixed access the mobility should be handled by MIP. The IPv6 test network should support HA functionality even if it’s not used directly by GPRS and UMTS terminals. In GPRS the mobile terminal gets a private IPv4 address from the network and NAT is used for connections to Internet. In UMTS (IPv6) the mobile terminal gets the address from
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 34/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
GGSN where GGSN gives the interface identifier combined with a prefix learned through Router Advertisements.
6 THE STATUS OF NETWORK SUPPORTING SERVICES
6.1 VPN & certificate management
VPN is a service that is based on the Security functionalities. The objective of a VPN is to allow users to communicate across a public network infrastructure as if there were in a private network. That means that a VPN virtually provides a secured private network.
To achieve this objective, all the communications between the private LANs transmitted over the public network have to be secured. Common architectures include IPSec gateways that are installed at the edge of the public network. IPSec Tunnels are established between each pair of gateways (or it could be between hosts if they support IPSec but key management is more complicated in that case).
A VPN includes the association of IPSec Gateways that secures the traffics going from one private network to another through tunnels.
The security functions used in VPN are based on IPSec tunnels and key management: · Confidentiality is based on encryption (ESP). · Identification and Authentication are used to authenticate each gateway of the VPN (AH). · Management of keys or certificates has to be performed. Except for small VPN, it is commonly done with PKI (Public Key Infrastructure). The keys can be generated manually and statically but for better security the IKE protocol negotiates the keys automatically and dynamically.
Figure 9: VPN common architecture
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 35/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
6.1.1 IP security architecture
IP security architecture is based on three different parts depicted in the following figure.
Preshared keys Preshared keys
Certification Authority
Certificates (RSA, key pair, PKCS 10)
IKE IPSec master keys IKE IPSec SA negociation
IPSec flows IPSec IPSec IPSec session keys
Figure 10: IP security architecture
The first one is IPSec, IP Security Protocol. This provides security services at the IP layer.
IPSec can be used to protect one or more data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.
The services to be provided between participating peers forming an IPSec tunnel, are data confidentiality, data integrity and data origin authentication. To provide them, IPSec defines a Security Association and relies on symmetric algorithms using encryption and authentication session keys.
The simplest way for managing an IPSec tunnel is manual keying. In that case, the IPSec tunnel is a static one and all the information required to define a Security Association are manually configured. Manual techniques could be practical in very small; static environments but they do not scale well. The security level is very low because the secret key is directly manipulated. If the same secret key is used for a long period of time, the probability that the traffic becomes compromised is very high. A key renewal will be necessary but the service will be stopped during renewal.
The second way is dynamic keying, via the IKE (Internet Key Exchange) protocol. Its role is to manage dynamic IPSec tunnels, which means that IKE provides IPSec peers authentication, IPSec session keys negotiation as well as IPSec Security Associations negotiation. IKE delivers the negotiated session keys and security associations to IPSec. In order to enhance the security level, the IPSec session keys may be renewed through a new IKE negotiation phase.
IKE relies itself on a key management system. This is the third and last part of the IPSec architecture. This part is not IP specific; it is a separate set of mechanisms for putting the cryptographic keys in place.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 36/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
Two main different options can be chosen for key management.
The first one is to define a pre-shared key for each IPSec peer-to-peer connection, and to load it in both peers. These secret keys will be used in the IKE authentication phase. This solution does not scale well because when a new device is installed, a new pre-shared key has to be generated for each remote device communicating with the new one, and this key must be loaded in both the new and remote device.
The second option is to use digital certificates as those defined by the X.509 standard. A certificate is generated for each peer and exchanged between peers to prove their respective identity. The certificate generation relies on: · an RSA public key cryptographic system which uses a key pair, one public and one private, · The PKCS #10 standard for certificate requests. A Certificate Authority is responsible for managing certificate requests and generating certificates for the IKE authentication phase. When a new device is added in the network, the device simply requests and gets a certificate from the Certificate Authority. No modification is necessary in the other devices.
A certificate is valid for only a period of time. If the validity expires, a new certificate can be obtained from the Certification Authority.
6.1.2 Public Key Infrastructures (PKI)
The use of a PKI is not required to create a VPN architecture. For instance, 6WIND’s Management System (NMS) provides a tool to produce and manage certificates. This tool could be sufficient for small or medium configurations. However for a large deployment of VPN, the use of a PKI is very interesting.
Many protocols and applications use public key cryptography on a large scale and must be able to manage large lists of public keys for distributed systems. For that, they resort to Public Key Infrastructures (PKI), which are intended to manage public keys on a large scale.
Most PKIs are based on Certification Authorities (CA), which are entitled to deliver certificates. More precisely, they verify and authenticate public keys. These authorities are generally organised in a hierarchy, which allows a greater flexibility for the management of the public keys by the means of certificates signed by these authorities and of Certificate Revocation Lists (CRL).
A PKI is software that creates, manages and distributes public key certificates within an organisation.
Organisations may choose to: · develop their own PKI software, · Purchase PKI software and operate it. It means that the organisation defines the way to create, manage and distribute certificates under its own authority, · Purchase PKI services to a third party and therefore outsource the responsibility for creating, managing and distributing certificates. X.509 is a standard for PKI. It defines a certificate format that can be exchanged by different off the shelf products. X.509 certificates use the RSA algorithm and PKCS #10 (Public-Key Cryptography Standard) for authentication and security algorithms.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 37/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
In the certificate mode, IKE makes use of a certificate to run its authentication process. IKE makes the assumption that certificates are locally available. That means that the certificate creation and loading has been done prior to the authentication phase.
Certificates are based on a public key cryptography, such as the RSA encryption system. Each IPSec Gateway has a key pair (public / private). Anything encrypted with one of the keys can be decrypted with the other. A signature is formed when data is encrypted with a user’s private key. The receiver verifies the signature by decrypting the message with the sender’s public key. If the message is correctly decrypted, it proves that the transmitter is at the message origin.
The role of the Certification Authority is to deliver certificates in response to a certificate request generated by a device.
6.2 QoS
Every Internet or Intranet user who wastes time every day due to bad response times or who tries to set videoconferences on an IP network, knows that we need to bring efficient solutions to major limitations of the current architectures.
The first limitation is obviously the poor Quality of Service (QoS). The Best Effort service on which present IP Networks are based was sufficient to transfer data but is going to be soon unsatisfactory for the users who are looking for multimedia services for both professional and residential use. In the case of medical applications, this is likely to be critical.
Two different approaches have been proposed to manage QoS over IP Networks.
6.2.1 Integrated Services
The first one, namely “Integrated Services” (IntServ), relies on the use of a signalling protocol (RSVP) which transfers the characteristics of the flows requiring some resource reservation. In this model, each station or router in the data path must handle the reservations requests and then must associate a queue to the flow requiring the reservation. By using this method, the QoS can be guaranteed, but “Integrated Services” are complex to implement and may generate a lot of signalling traffic. This excess signalling traffic induces a poor scalability for the “Integrated Services” model.
6.2.2 Differentiated Services
The “Differentiated Services” (DiffServ) use the same principles as the “Integrated Services” but they suppress the signalling. Each packet is tagged with a “traffic class” that makes the implementation of traffic differentiation possible in the network.
This approach takes into account the results of the first implementations of the “Integrated Services”. It is much simpler and scales better. It is based upon a traffic differentiation of the different data flows in the network.
The DiffServ architecture is described in RFC 2475 "Architecture for Differentiated Services”.
The goal of the DiffServ architecture is to implement a scalable service differentiation in the Internet. A "Service" defines some significant characteristics of packet transmission in one direction across a set of paths within a network. These characteristics may be specified in terms of throughput, delay, jitter, and/or loss, or may otherwise be specified in terms of some relative priority of access to network resources.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 38/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
The DiffServ architecture is composed of a number of elements implemented in network nodes, including: · per-hop forwarding behaviours (PHB), · packet classification functions, · traffic conditioning functions including: Ø metering Ø marking Ø shaping Ø policing. This architecture achieves scalability by implementing complex classification and conditioning functions only at network boundary nodes, and by applying per-hop behaviours to traffic aggregates which have been appropriately marked using the DS field in the IP packet header.
The architecture maintains a distinction between: · the service provided to a traffic aggregate, · the conditioning functions and PHB used to realise services, · the DS field value (DS code-point) used to mark packets to select a PHB, · The particular node implementation mechanisms which realise a PHB. This architecture only provides service differentiation in one direction of traffic flow and is therefore asymmetric.
6.3 Network Servers
6.3.1 DHCPv6
There are not currently any commercially available implementations of DHCPv6. The standard is insufficiently mature within the IETF for commercial vendors to complete development. Activity is now underway, under the auspices of the IPv6 Forum, to gather requirements to issue a Request for Quotes for development of a reference implementation. This work is unlikely to see a first release before mid-2002. As this date falls within the timescale of the 6WINIT project, it may be possible for 6WINIT networks to make use of DHCPv6 technology; however this should not be planned for at this stage and alternative mechanisms should be part of 6WINIT-network design.
6.3.2 DNS
Current releases of BIND9 support IPv6 DNS. There are some concerns about the performance of BIND9 compared with the earlier IPv4-only releases of the code. As with DHCPv6, the IPv6 Forum is sponsoring a requirements capture exercise aimed at a renewed development of a reference implementation of an IPv6 DNS server. Performance comparable to existing IPv4-only implementations of BIND is a stated requirement. Releases of code from this effort should be anticipated earlier than for DHCPv6 discussed above. Performance of the existing BIND9 code is adequate for anticipated 6WINIT network applications and will not pose any problems during the lifetime of the project.
6.4 IPv6 / IPv4 Inter working
When moving to another technology, the transition has to be supported and it’s generally one of the most important questions. The transition is often the most expensive part in a change of technology generation. Many technologies didn’t succeed because of lack of transition scenarios and tools.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 39/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
The 6WINIT network should support a wide range of different transition mechanisms and tools to give the participants the possibility to evaluate different possibilities and find out the most suitable technologies for their needs.
For a provider the simplest way to implement IPv6 support is to build two parallel infrastructures for IPv4 and IPv6 and only have a few connection points between them. The infrastructures can be separated on the same physical network with VLAN (Virtual LAN) or ATM using separate PVCs. This separation simplifies the management of the network.
6.4.1 Technologies
6.4.1.1 Dual Stack
In the dual stack model, all IPv6 nodes, Hosts and routers, have an IP-stack supporting both IPv4 and IPv6 and addressing.
Applicatio n TCP/UDP IPv4 IPv6 DLL Physical
Figure 11: Dual Stack
When the host initiates a communication the DNS resolver returns IPv6, IPv4 addresses to the application. The host will then establish the communication using the appropriate IP-stack. Servers in the network listen on both IPv4 and IPv6 network sockets and prefers IPv6. The bottleneck in the dual stack solution is that every host needs an IPv4 address. Of course it’s possible to allocate a temporary IPv4 address for a host when a IPv4 address are needed but it causes problem with the life time of addresses in DNS caches around the network.
Figure 12: IPv4 host connected to dual stack host
IPv6 applications should be able to communicate with IPv4 and IPv6 nodes.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 40/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
6.4.1.2 Limited Dual Stack Model
In the limited dual stack model only servers have dual stacks. The client node is an IPv6 only node. With this model many less IPv4 addresses are used but communication between client nodes are broken. For communication between client nodes ALGs (Application Layer Gateway) are installed for services.
6.4.1.3 SOKS64
The Socks Gateway accepts enhanced socks connections from IPv4 hosts and relays it to IPv4 or IPv6 hosts. SOCKS64 don’t require and DNS modifications or address mapping.
6.4.1.4 SIIT (Stateless IP/ICMP Translation)
SIIT is a stateless translation of the IP packet header where the IPv4 address are translated to an IPv4 compatible IPv6 address. The SIIT translation doesn’t support any ALG functionality so applications running in a IPv6 network must be adapted to support IPv4 connections. SIIT requires one temporary IPv4 address per host.
6.4.1.5 NAT-PT
NAT-PT is a Stateful address translation where the PT part is the same as in the SIIT translation com- bined with the well-known NAT functionality from the IPv4 world. NAT-PT supports ALG functionality in the network why the communication to an IPv4 network is transparent for the application in the IPv6 network. NAT-PT uses dedicated servers in the IPv6 network and needs at least one IPv4 address per site.
6.4.1.6 BIS (Bump In the Stack)
The main idea is that when an IPv4 application needs to communicate with an IPv6 only host the IPv6 address are mapped into an IPv4 address The IPv4 packet generated for the communication is translated into an IPv6 packet according to SIIT. The BIS model requires changes in the nodes in the IPv4 network. Added to the IPv4 stack are tree modules that intervene between the application and the network.
6.4.1.7 DSTM (Dual Stack Transition Mechanism)
DSTM uses a DHCPv6 server to allocate a temporary IPv4 address to a dual stack host. The IP traffic is tunnelled over the IPv6 network in IPv4 over IPv6 tunnels. Because the IPv4 traffic is tunnelled over the IPv6 network there isn’t any need for dual stack implementation in the IPv6 network.
6.4.1.8 Application Gateways · SMTP gateway IPv4 - IPv6 -IPv4 · Web Proxy · ...
6.5 Connecting IPv6 Islands
The most common method to connect IPv6 islands is to tunnel the IPv6 packets inside an IPv4 packet. Many topologies are possible like Router to Router, Host to Router and Host to Host tunnelling. In all cases the tunnel endpoint takes care of the encapsulation. This process is transparent to the other nodes in the network and for this reason is very fast to implement.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 41/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
6.5.1 Technologies
6.5.1.1 Configured tunnelling
Configured tunnelling is the most elementary technique and all IPv6 implementation support this. Tunnel endpoints are explicitly configured and a fixed tunnel is established between the endpoints; the tunnel endpoints must be dual stack nodes. Every endpoint must have a public IPv4 address and no NAT is allowed between the endpoints. The drawback with this is the manual configuration work needed; because of this, this mechanism is only manageable between a limited number of endpoints.
6.5.1.2 Tunnel Broker
This connects one computer to the IPv6 net over an IPv4 network. The client must have a dual (IPv4/IPv6) stack implemented. The client IPv4 address must be globally routable.
6.5.1.3 The “6to4” transition mechanism
The 6to4 mechanism allows connection between IPv6 Domains via IPv4 Clouds without explicit tunnels
Of great concern to transition strategy planners is how to provide connectivity between IPv6-enabled end-user sites (also known as routing domains) when they do not yet have a reasonable (or any) choice of Internet Service Provider (ISP) that provides native IPv6 transport services. One way to provide IPv6 connectivity between end-user sites (when native IPv6 service does not exist) is to use IPv6-over-IPv4 encapsulation (tunnelling) between them. This requires complexity for both end-user sites, and the networks providing the tunnelling service (for instance, the 6bone backbone ISPs), in creating, managing, and operating manually configured tunnels.
The "6to4" transition mechanism, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels", provides a solution to the complexity problem of using manually configured tunnels by specifying a unique routing prefix for each end-user site that carries an IPv4 tunnel endpoint address.
It should also be noted that each end-user site with as little as a single IPv4 address has a unique, routable, IPv6 site routing prefix thanks to the 6to4 transition mechanism.
The 6to4 mechanism is typically implemented almost entirely in border routers, without specific host modifications except a suggested address selection policy. Only a modest amount of router configuration is required.
A subscriber site is supposed to have at least one valid, globally unique 32-bit IPv4 address. This address must be duly allocated to the site by an address registry (possibly via a service provider) and it must not be a private address. By example in the below scheme, we choose 192.1.2.3.
The 6to4 router builds an IPv6 prefix. The prefix format is the following:
3 13 32 16 64 bits
FP TLA IPV4 addr SLA ID Interface ID
Figure 13: 6to4 prefix format
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 42/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
Prefix length: 48 bits
Format prefix: 001 (3 bits)
TLA (Top Level Aggregator) value: 0x0002 (13 bits)
SLA: Site Level Aggregation
Interface ID: link level host identifier.
One of the big advantages of the 6to4 mechanism is that a customer can use IPv6 without having any global IPv6 prefixes (allocated by ISPs or others). In this case, the customer would only use 6to4 prefixes on the network. The 6to4 function would only be activated in edge routers, but the other IPv6 nodes would use the 6to4 addresses as normal global addresses.
Another advantage of 6to4 is that it requires fewer configurations than configured tunnels.
6.5.1.4 6over4
Interconnection of isolated IPv6 domains in an IPv4 world. 6over4 doesn’t need any explicit tunnels but the need of multicast routing in the IPv4 network restricts the possibilities of using it.
6.5.2 Supported in Partners Components
6.5.2.1 The AXI 462 Ericsson Telebit Router
The AXI 462 supports automatic and manual configured IPv6 in IPv4 tunnels together with a SIIT translation mechanism.
6.5.2.2 The RXI 820 Prototype
The RXI 820 Prototype will support automatic and manual configured IPv6 in IPv4 tunnels together with the NAT-PT mechanisms provided by SIIT- Stateless IP/ICMP Translation Algorithm and DAT - Dynamic address allocation. Further, application gateways for DNS and FTP will be provided.
6.5.2.3 IP Edge Device
The IP Edge Device implements the v4-v6 migration mechanisms over a dual stack entirely developed by 6WIND. This dual stack integrates also IPv6 features such as DiffServ and IPSec.
The IP Edge Device implements the main current tunnelling mechanisms: · configured IPv6 in IPv4 tunnels · automatic tunnels · 6to4 · Configured IPv4 in IPv6 tunnels
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 43/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
7 URGENT DEVELOPMENT NEEDS
7.1 Tunnelling IPv6 over GPRS
The first 3G systems are just about to be delivered to customers worldwide. The current GPRS system is based on the existing Internet Protocol (IPv4). As the number of Internet users grows, not only in the cellular networks but also in the fixed networks, the number of available addresses in IPv4 will not be enough to guarantee each subscriber a globally unique Internet address.
A globally unique Internet address is required for a user to get access to all the new services that will exist on the Internet in the future. Since this new protocol,Ipv6 is perfectly well suited for the requirements requested by the cellular manufactures and operators it is of significant importance to verify that the IPv6 protocol can be used in the existing GPRS system.
IPv6 in IPv4 tunnel
GPRS IPv6 Network Network
Figure 14: Connecting an IPv6 network over GPRS
For tunnelling of IPv6 packets over GPRS there must be two nodes capable of encapsulating and decapsulating IPv6 packets in IPv4 packets. The preferred method for encapsulating is to use configured tunnels.
One of the tunnelling devices is the TE and the other device is a router somewhere outside the GPRS network where access to an IPv6 network is available. This solution requires public IPv4 addresses. If only private IPv4 addresses are available from the operator the router must be located at the private network by the GPRS operator.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 44/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
IPv6 Services IPv6 Backbone
IPv6 Services IPv6 Network WLAN
IPv4 Global Internet IWU IPv6 Network
HLR GGSN
SGSN BS BSC BSC BS
Since configured tunnels are used the user must get the same IPv4 address when negotiating the PDP context with GPRS. If this can not be achieved the tunnel must be changed for each new session.
7.2 Multi-access
7.2.1 The need for multi-access
Applications that need to communicate over different access networks (e.g. UMTS, WLAN, LAN, ...) must have control over their network usage. They have to know what networks they are using, the capabilities of the networks and also they must be able to change between access networks if needed. This kind of system can be called a multi-access system.
In addition to this, applications may require simultaneous usage of different access networks. Applications, such as medical applications described earlier in this document, may want to use faster networks for short times to transfer large amount of data but still letting some of the connections to go via more secure or more reliable network. This means that connection separation must be done at the mobile node.
The basic mobility in the IPv6 network can be handled using Mobile IPv6. The protocol can be used to change the routing of packets even from one interface to another. This, however, is still not separating any single connections that are leaving the node.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 45/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
7.2.2 Existing solutions
The controllable interface change has been implemented already at the NomadicLab, and it will be available in the MIPL (Helsinki University of Technology Mobile IPv6 implementation) code in August. This implementation does not yet have the capability of separating different applications and different connections from each other so that different applications could use different routes when communicating with the same correspondent node.
7.2.3 Work needed
The problem with separating connections leaving a mobile node, letting applications to control the data transfer over different access networks and to allow these to happen in a way that is compatible with standard mobile IPv6 implementations needs to be resolved.
The system must also be able to do fast handovers that does not lose packets. The existing implementation on the multi-access can handle this when all networks are up and running and the application can have the control on itself. However, it is critical to handle handovers fast when one network connection is lost and all connections that were using this interface must be transferred to use another. In this area, the homeless-idea (end-nodes knowing multiple addresses from each other while communicating) may make the handover much faster. The change of the interface on the mobile node doesn’t have to be communicated using the binding update to the peer, but it can immediately start using another interface if the address has been earlier told to the peer. This saves the number of transmitted packets and lets the peer know very fast which address it should use for the mobile node.
The further verification and implementation of these ideas is required to make sure that such a system is capable of handling the requirements of such demanding applications like medical applications. The most important requirements are high security and reliability.
7.3 Securing Mobile IPv6 Control Messages
The basic security problem underlying Mobile IPv6 comes about from establishing ownership of a dynamically allocated IP address before an IP connection has been established. Proposed solutions include public key cryptography verifiable portions of the claimed IPv6 host address, including the possibility of having a host identifiable through multiple IPv6 addresses.
However, the discovery of the inherent security flaws in the MobileIPv6 structure poses a serious threat to a timely deployment of the 3GPP packet service in this (IETF-approved) fashion. This might lead to vendors adopting inferior connection-oriented SIM / IMEI based alternate solutions familiar from the GSM / GPRS networks, using piecewise secured links requiring termination of IP security connections in GGSN-type nodes ill suited for massive cryptographic handling.
As the mobile node changes point of attachment, the prefix part of the IPv6 address will change, with the binding update taking place in a secure manner, not necessarily going back to the Home Agent for verification (chained certificates).
These Control Messages, Binding Updates and Binding Acknowledgements, are sent as IPv6 Destination Options within the IPv6 Header.
A dangerous scenario is an attacker modifying these Control Messages, e.g. replacing the mobile node's Care-of Address with his own address.
The MobileIP WG has agreed to introduce security mechanisms, which efficiently protect against unwanted modification of these Control Messages. Having IPSec as mandatory for IPv6 the WG
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 46/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
agreed to use the IPSec AH for authenticating Binding Updates and Binding Acknowledgements. The way to do this is described in more detail in [MobileIPv6].
The proposal of using IPSec for authentication purposes has not been accepted for the following reasons: · An IPSec security association is usually identified by the IP addresses of its endpoints. Setting up a security association between the mobile node and its Home Agent, or the mobile node and its communication partners for the purpose of authentication of Control Messages would mean, that also the user data exchanged between the mobile node and its Home Agent, or the mobile node and its communication partners are mapped to the same security association. It is reasonable to assume that the user data should have a stronger security (authentication and encryption) than the Control Messages or even no security at all. This issue would need some further investigation. · Much more critical than the reason above is the fact, that MobileIPv6 could be a good candidate to be used in 3G networks, and therefore will have broad deployment. IPSec has not been regarded as adequate to support a huge number of roaming users for the simple reason, that today we have no global PKI in the Internet, which would be necessary for a broad IPSec deployment, and we probably will not see such a PKI in the next time. So MobileIPv6 today faces the problem that without addressing the authentication problem, it increases the security threats in the Internet and therefore will not become standard, but IPSec has not been regarded as adequate. The proposal to address this issue has been to set up a Design Team within the MobileIP WG, which should come up with a proposal to be further discussed in the WG. Having too much delay could badly influence MobileIPv6 becoming part of 3G.
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 47/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
8 ACRONYMS AND ABBREVIATIONS
ACL Asynchronous Connectionless Links ADPCM Adaptive Differential Pulse Code Modulation AH Authentication Header ALAN Application Level Active Networking ALG Application Layer Gateway AM_ADDR Active Member Address AN Active Networking API Application Level Interface ATM Asynchronous Transfer Mode BD_ADDR Bluetooth Device Address CA Certification Authority CHTML Compact HTML CLI Calling Line Identification CPE Customer Premises Equipment CRL Certificate Revocation Lists DES Data Encryption Standard DIAC Dedicated Inquiry Access Code DNS Domain Name Server DSTM Dual Stack Transition Mechanism DiffServ Differentiated Services ESP Encapsulation Security Payload GANS Guardian ANgel System (UKT-RUS) GGSN Gateway GSN GIAC General Inquiry Access Code GPRS General Packet Radio Service GSN GPRS Support Node GTP GPRS Tunnelling Protocol HTML HyperText Mark-up Language HTTP HyperText Transfer Protocol ICP Internet Content Provider IGMP Internet Group Multicast Protocol IGP Internet Gateway Protocol IKE Internet Key Exchange IPSec IP Security Protocol IPv4 Internet Protocol Version 4 IPv6 Internet Protocol Version 6 ISDN Integrated Services Digital Network IntServ Integrated Services JPEG Joint Photographic Experts' Group KLIPS Kernel IPSec Support LDAP Lightweight Directory Access Protocol MDML Market Data Mark-up Language NAPT-PT Network Address Port Translation - Protocol Translation NAT-PT Network Address Translator - Protocol Translator PCM Pulse Code Modulation PDA Personal Digital Assistant
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 48/49 Deliverable 1 Available IPv6 communications, gateways and components. Issue 1 6WINIT/0031
PKCS Public-Key Cryptography Standard PKI Public Key Infrastructure QoS Quality of Service RFC (Internet) Request for Comments RSA Rivest-Shamir-Adleman (encryption algorithm) RSVP Resource ReSerVation Protocol RTCP RTP control protocol RTP Real Time Transport Protocol Rohc Robust Header compression SA Security Associations SADB Security Association Database SCO Synchronous Connection Oriented SGSN Serving GSN SIIT Stateless IP/ICMP Translation Algorithm SPD Security Policy Database SRTP Secure Real Time Transport Protocol SSL Secure Socket Layer TDD Time Division Duplex VPN Virtual Private Network W3C World-Wide Web Consortium WAE Wireless Application Environment WAP Wireless Application Protocol WDP Wireless Datagram Protocol WEP Wire Equivalent Privacy WML Wireless Mark-up Language WTA Wireless Telephony Application WTLS Wireless Transport Layer Security XHTML Extensible Hypertext Mark-up Language
8-Feb-02 6WINIT – IPv6 Wireless Internet IniTiative Page 49/49