Deliverables
The National Information Infrastructure Development (NIIF) Program serves as a framework for the development and operation of the research network in Hungary.
The NIIF Program covers the entire Hungarian academic and research community by providing them with an integrated computer networking infrastructure and, on the basis of that, a wide range of communication, information, and co-operation services, leading-edge environment for networking applications, as well as an advanced framework for content generation and provision.
The NIIF Program is based on funding from the central state budget. The development and operation of the network and the services are executed under the supervision of the Program Committee, and by the control of the Technical Committee. The Program co-operates closely with Hungarnet, the association of the user community.
The NIIF Program, in accordance ith the international practice, at the same time plays a leading edge role in the development and introduction of most advanced networking technologies in Hungary, such as IPv6. In this way, the Program fulfils a deterministic function in the nation-wide development of the information and communication technologies. While providing an up to date and competitive infrastructure for the academic and research community, the Program also serves by piloting new networking technologies and applications for the widest development efforts in the country.
The Program provides most advanced technical and application background for more than half a million users from the fields of science, education, and public offices in Hungary.
The network serves approximately seven hundred institutions throughout the country.
UNINETT offers IPv4 multicast to all member institutions, and also has connectivity to other multicast networks. Experiments with IPv6 multicast are also taking place. UNINETT and some members are connected to the M6Bone.
The gateway can be deployed in a IPv6 PIM-SM domain, and the entire domain will be able to use the gateway without any other modifications. The only requirement is that the gateway is known to be an RP for a /96 multicast prefix. The prefix can be chosen by the administrator deploying the gateway. The RP mapping is configured as usual; static, BSR, embeded-RP or other means throughout the domain. By domain we mean simply a convex part of the internet where every router has this RP mapping.
The IPv4 multicast space is embedded into IPv6 using this /96 prefix. The IPv4 address is simply appended to the /96 to construct the respective IPv6 multicast address. An application on a host in the domain, can send traffic to any IPv4 multicast group (might be limited by scope) a.b.c.d by sending to the respectve IPv6 group PREFIX:a.b.c.d. That is, the /96 prefix with a.b.c.d appended. The application may also join the group PREFIX:a.b.c.d to receive all IPv4 multicast sent to a.b.c.d. Also note that if multiple hosts are sending to or joining PREFIX:a.b.c.d they will be able to send to and receive from eachother as usual.
Since the gateway is the RP for the chosen /96 prefix, it will be able to receive all data sent to PREFIX:a.b.c.d so that it can resend it as IPv4 multicast to a.b.c.d. It will also know whether there are any hosts interested in receiving traffic from PREFIX:a.b.c.d. If that is the case, it will join the IPv4 group a.b.c.d and resend all traffic received from it. Note that IPv6 hosts can send without joining. And also that this allows communications in both directions, and you might have say a video conference with multiple IPv6 participants all using PREFIX:a.b.c.d and multiple IPv4 participants all using a.b.c.d. Everyone should be able to send to and/or receive from all others.
This result is described in a public white paper entitled "IPv6 and e-business" available from the 6Net website. This document studies IPv6 features from the viewpoint of e-Business competencies and the needs of On Demand Business, rather than from that of a network specialist. After listing the interesting features of IPv6, it describes the support of IPv6 in Java, the preferred language of e-Business. It also presents a view of the IPv6 support provided by IBM. Finally, it explains how e-business applications support the IPv6 protocol.
The purpose of this demonstrator was to determine how well Mobile IPv6 and the basic network mobility (NEMO) protocol work when utilised in environments that are highly mobile. ULANC identified the domain of mountain rescue services as ideal for this task. Lancaster University is on the border of the English Lake District, which is extremely popular with hikers, fell runners and mountain climbers. In cooperation with the Cockermouth mountain rescue team, we examined the feasibility of using mobile routers to provide them with an on-mountain data networking solution.
Integrating mobile router technology into the existing mountain rescue operational procedures was very challenging. Not only did we have the problem of providing optimum connectivity in remote mountainous regions, but also of catering for several communicating entities within a command hierarchy. Even a simple search will consist of several volunteers of a single rescue team spread across a wide area. The volunteers need to communicate with each other and their mobile response vehicle, which in turn will need to communicate with its home base and other entities such as ambulance services and the RAF (Royal Air Force). For large searches the situation is more complex as there may be several rescue teams trying to work in coordinated fashion.
The users of the real system that will be developed will be the Cockermouth mountain rescue team.
The user base will most likely be expanded to include other mountain rescue teams within the Cumbria region.
Within the 6NET project, Lancaster University and Cisco have instigated a long term research programme that aims to exploit the concept of IPv6 network mobility using Cisco 3200 series mobile routers.
We are implementing IPv6 network mobility in three distinct user scenarios, each providing different challenges for the mobile network infrastructure. These three scenarios are:
- Remote Network Support.
- A Mobile Library and
- Mountain Rescue
Within the timeframe of the 6NET, we produced several demonstrators applicable to the user scenarios identified.
All the demonstrators were shown at the GARR IPv6 event in Pisa, May 2005 and the Mountain Rescue services demonstrator was also shown at the TERENA Networking Conference in Poznan, June 2005.
IPv4 and IPv6 will need to interoperate for many years. An important part of the 6NET project is therefore to investigate deployment of transition mechanisms. A number of transition mechanisms [RFC2766,RFC3142] operating at the network and transport level make use of IPv6 addresses that embed an IPv4 address. Applications and their users typically (should) use DNS hostnames to denote communication endpoints, instead of dealing with IP addresses directly. Expecting the users and applications to embed an IPv4 address into an IPv6 address is therefore unreasonable as they will expect the DNS system to map hostnames to whatever address(es) usable for communication. Hence, we need support in the DNS for the generation of these special addresses needed for the transition mechanisms in question.
Address mapping support could be added in the DNS resolvers and/or servers, or a special-purpose DNS proxy could be used. The latter approach has been persued as part of the 6NET project in the form of the IPv6/IPv4 translating DNS proxy `totd'.
Documentation, source code and binaries of the proxy software is freely available for a variety of operating systems. This proxy is essential for IPv6-only nodes and networks and has already been downloaded by thousands of users.
The Differentiated Services (DiffServ) framework is widely proposed as an efficient method for providing advanced IP services to large-scale networks, with QoS requirements. However, the provisioning of such services in production networks has proved to be more difficult than initially expected, in defining, setting and verifying appropriate Service Level Agreements (SLAs). GEANT, the Gigabit core pan-European research network, on a pilot basis introduced Premium IP service, offering bounded delay and negligible packet loss to the European National Research & Education Networks (NRENs) that it interconnects. However, large scale provisioning of this new service requires the definition of efficient interaction procedures between administrative domains involved and methods for SLA monitoring.
ULANC examined these issues and documented their experience acquired from the early experiments in GEANT, as an example of a hierarchical Gigabit multi-domain environment, enabled with QoS provisioning to its constituent NRENs. This model scales more efficiently than the common peering Internet Service Provider (ISP) commercial paradigm. Finally, ULANC outline other options that promise QoS, such as Layer 2 VPNs in MPLS backbones, with non-standard (yet) mechanisms.
The SSM architecture is now well understood. PIM-SM for SSM and IPv6 is available on most routers as is MLDv2. On the client side, MLDv2 is still lacking on Windows OS, but should be available with the next (Longhorn) version. In the core of the network, SSM is much simpler to operate than ASM since it needs no RP and no additional protocol such as MSDP. Moreover these ASM mechanisms can be the target of DDoS attacks, whereas SSM seems more robust. By design there is no need for complex address allocations mechanisms since an SSM address must be unique for a given source only. Similarly it is easy to do source control since only one source may send in a channel.
For multiparty applications, there is a need to use either session relay where all sources send to an applicative relay that forwards data in an SSM channel, or to have some intra session source announcement. We have shown that with tools such as ssmsdp, it is possible to keep the same source discovery service at the application level, while using SSM only in the network. Moreover, this can be done with a very minor modification to existing ASM applications. New functionalities
could easily be introduced in the controller (floor control).
One potential problem with this proposition is scalability in terms of sessions or sources. We have seen that this is not a problem, at least for sessions with a few hundred sources. One problem sometimes mentioned is the number of states that have to be maintained in routers if each source has its own tree. However this is not very different from ASM, since a source tree is usually constructed for each active source.
Another potential problem with SSM only is service discovery (or session announcement) using multicast, such as session announcements with sdr/SAP since this makes use of an ASM group that has no clear owner (hence no controller). Propositions such as sas can be used in this case. This should probably be extended to a hierarchical version for scalability reasons. In any case different tools are probably needed for different types of applications (TV channels, network games, videoconferencing).
On the host side, MLDv2 is not yet widely available (Linux or BSD with Kame patch), it is still missing for Windows and MacOS, but should be available in the Longhorn release of Windows. As far as applications are concerned, we have seen that ASM applications can be easily ported to SSM: relatively straightforward for single source applications, quite easy for multiparty applications when using ssmsdp. Reliable multicast can make use of a unidirectional channel when using FEC, as with
Flute.
Concerning flow and congestion control, solutions are available with layering and mechanisms such as FLID. They can be used both for video transmission and for reliable transfer. Some improvements are probably needed to guarantee a faster convergence and an improved fairness between flows. However a good TCP friendliness seems to be achieved, at least for connections with small RTTs. Eventually, all SSM applications (except very low bandwidth ones) should have this type of congestion control.
On the other hand there is still a lack in management tools for multicast in general and particularly for SSM over IPv6 in an inter-domain context. Tools such as ssmping or beacons are a first answer to check connectivity but they are not sufficient to locate connectivity problems precisely. Tools such as mtrace6 (mtrace is available for IPv4) or tracetree would be useful. Also Mibs allowing to remotely monitor an IPv6 multicast network are needed.
In conclusion we can say that SSM over IPv6 seems a very attractive solution for multicast, particularly at the inter-domain level. Almost all building blocks are there, waiting for some popular applications.
As IPv6 grows in maturity in terms of standards and implementations, and as the understanding of its benefits grow, deployments, both pilot and production, will also increase in number. A major focus of the activity in Work Package 2 of 6NET was to validate IPv6 deployment for University (Campus)networks.
As site networks are made dual-stack, and IPv6 services enabled, IPv6-only nodes can be deployed into these environments, with a longer-term view to support and operate
IPv6-only networks.
In addition to supporting dual-stack networking on their own Campus, many universities also offer IPv6 access methods for their users, e.g. using a tunnel broker or a 6to4 relay.
The transition period is likely to be long, but early experience especially in an academic setting where teaching, innovation and research come to the forefront is highly recommended.
The overwhelming experience from 6NET is that you can transition towards dual-stack networking successfully without adversely impacting your existing IPv4 infrastructure.
The purpose of the mobility demonstrator was to determine how well Mobile IPv6 and the basic network mobility (NEMO) protocol perform when utilised in environments that are highly mobile. In cooperation with the Cockermouth mountain rescue team, the University of Lancaster have examined the feasibility of using mobile routers to provide them with an on-mountain data networking solution.
Integrating mobile router technology into the existing mountain rescue operational procedures is very challenging. Not only is there the problem of providing optimum connectivity in remote mountainous regions, but there is also the need to cater for several communicating entities within a command hierarchy. Even a simple search will consist of several volunteers of a single rescue team spread across a wide area. The volunteers need to communicate with each other and their mobile response vehicle, which in turn needs to communicate with its home base and other entities such as ambulance services and the RAF (Royal Air Force). For large searches the situation is more complex as there may be several rescue teams trying to work in a co-ordinated fashion.
The demonstrator replicates both network and mobile node roaming within nested mobile networks. Furthermore, an application was developed to illustrate the constantly changing network topological information to the user. Apart from the mobile protocols, problems were discovered with the currently available wireless interface technologies and battery technologies.
As most of European NRENs, also FCCN has been developing a sustained effort towards the deployment of IPv6 services to all is end user institutions. By joining 6NET, FCCN managed to not only gather essential knowledge about the most modern techniques and approaches regarding the provision of those services, but also it broadened the range of services in its deployment roadmap.
The exchange of ideas and experiences among the project members was also instrumental in providing the knowledge necessary to anticipate the deployment of new IPv6 services in the Portuguese NREN, named RCTS.
6NET was one of Europe's largest Internet research projects, and deployed and tested IPv6 under realistic conditions. The 42 project partners represented a rich combination of research and industrial organizations. The consortium provided a native IPv6 network on an international scale, throughout Europe, and to North America and the Asia-Pacific region, for test and demonstration purposes. The 6NET infrastructure connected more countries at a higher capacity than any other native IPv6 network deployed to date; spanning 13 European countries, with links of up to 2.5Gbit/s. The resulting experience of deployment, operation and management was used to migrate IPv6 into the GÉANT production network for the European research community.
The 6NET Deliverable D4.1.2 'Initial Mobile IPv6 Support Guide' describes the steps necessary to install, configure and operate the Mobile IPv6 implementations of Cisco, MIPL1, KAME2, Microsoft and Lancaster University.
In addition, three case studies of Mobile IPv6 testbed deployment at Sony, FhG and Lancaster University are described.
Several partners, including ULANC, ULP, FhG, OULU, Invenia, INFN-GARR and UCL, established Mobile IPv6 testbeds using a variety of the available implementations. Each testbed has its own focus and provides for a rich set of implementation experiences, which are reflected in this Deliverable. For example, Invenia have configured and tested their Mobile IPv6 testbed with different price/bandwidth policies while ULANC have constructed their testbed to specifically investigate fast handoff performance and QoS provision.
A theoretical analysis of multicast with Mobile IPv6 hosts has been conducted by ULP. Their analysis identified that Multicast Listening Discovery (MLD) must be improved for mobile hosts and a solution has been proposed to handle the handover of a Source Specific Multicast (SSM) source in Mobile IPv6. A large number of NS simulations have also been conducted to compare the efficiency of different methods of group joining.
6NET partners began interoperability testing early in 2004, concentrating on Mobile IPv6 implementations from Cisco, Microsoft, KAME and MIPL.
In July 2004, the Internet Engineering Steering Group (IESG) approved version 24 of the draft Mobile IPv6 specification as a proposed Standard. This decision provided a stable target for Mobile IPv6 implementors and allowed 6NET partners to synchronise their efforts and begin to conduct inter-site testing and trials.
Mobile IPv6 Home Agents were installed at each participating site and the functionality of Home Agent, Mobile Node and Correspondent Node on each implementation was tested for conformance and interoperability.
The first set of tests investigated how it is possible to implement a QoS service that is suitable for real time applications. The QoS service under testing was based on DiffServ EF (expedited forwarding) PHB, which provides strict priority to properly marked packets. The second set of tests investigated the "intra-class fairness" for AF (assured forwarding) traffic, i.e. how does (free) link capacity is efficiently shared among different flows in a (partially) congested network. The third set of tests investigated the combined operation and interaction of different QoS mechanisms, such as traffic policing, traffic shaping and class-based queuing. These mechanisms are usually applied on edge routers at the interface towards the network provider network. Therefore, inappropriate tuning of these mechanisms may severely affect services provided. The last set of tests investigated the performance achieved by data transfer applications that used Less that Best Effort (LBE) services in a production network.
The second phase of QoS tests took into account the defined QoS model and extended the QoS activity across 6NETs backbone network. Initially, the proposed QoS model, which is based on the Differentiated Services (DiffServ) architecture, was studied taking into account several aspects, such as network dimensioning, policing and admission control. In particular, the 6NET QoS model includes the implementation of the IP Premium service, which is based on the EF (expedited forwarding) PHB (Per Hop Behavior) and provides absolute prioritization to this type of traffic. It also includes the BE (Best Effort) and the LBE (Less than Best Effort) services.
Afterwards, the appropriate configuration to allow 6NET to provide QoS services was formed and possible conflicts with other network services were identified. The configuration was applied to all 6NETs backbone network routers providing the aforementioned QoS services to the connected NRENs. Finally, a number of tests were defined in order to evaluate the performance of the QoS services in the 6NET network. The prioritization of IP Premium traffic was examined, by testing the marking, traffic policing and traffic shaping mechanisms. A wide range of scenarios with various patterns of foreground and background traffic were performed in order to thoroughly investigate the applied QoS model and its impact.
The performed QoS tests in 6NET backbone indicated that this IPv6 QoS model can be the basis for production services. The mechanisms under test operated efficiently, as the experimental results prove, without any performance degradation on backbone routers. The above observations remained true even in heavy network congestion and the final performance results that a user or an application experienced correspond to the QoS services specification.
As IPv6 grows in maturity in terms of standards and implementations, and as understanding of its benefits grow, deployments, both pilot and production, will also increase in number.
Within the 6NET project, many of the participants have already made a significant investment in deploying early IPv6 services, mainly dual-stack, but a small number IPv6-only. In this document, we present a cookbook of theory and practice for IPv6 site deployment.
The cookbook includes information on the theory of various transition methods that have been proposed to date, as well as examples using popular IPv6 operating systems such as FreeBSD, Linux, Solaris and Windows and router platforms such as Cisco IOS, Juniper JunOS and Zebra.
This cookbook has been a living document since its first release D2.3.1 in 2002 and has been updated whenever major new material was available. Aside from the very first release two intermediate versions of this document ere released as D2.3.2 in 2002 and D2.3.3 in 2003. Updates to this final version from D2.3.3-bis include more detailed migration scenarios/reports (including case studies that are being undertaken jointly with the Euro6IX project) as well as a more comprehensive list of implementations.
The UCL media tools include the Robust Audio Tool (RAT), the VIdeoConference tool (VIC), and the Network Text Editor (NTE). These tools provide for multi-party conferencing, over IPv6 or IPv4, with audio, video and text. These can be between two participants directly, using unicast, or between a number of participants on a common multicast group. All tools feature encryption so sessions can be kept private. The tools are available for a wide range of operating systems, and have been shipped as part of various packages including AccessGrid.
RAT is based on IETF standards, using Real-time Transport Protocol (RTP) above UDP/IP as its transport protocol, and conforming to the RTP profile for audio and videoconference with minimal control. RAT features a range of different rate and quality codecs (G.711, G.726, GSM, DVI, LPC), receiver based loss concealment to mask packet losses, and sender based channel coding in the form of redundant audio transmission.
VIC also uses RTP, and features a range of video codecs (H.261, H.263, H263+, JPEG, PVH, RAW/YUV, NV, Cellb), which allow for the choice of quality and bandwidth employed.
NTE provides for collaborative editing of text by multiple users, utilising a reliable multicast protocol to ensure integrity of the data across all users in a session. The tool features visual indication of text block editing and locking facilities for particular text blocks.
Activity 4.4 of 6NET was concerned with IPv6 Quality of Service (QoS). QoS tests were carried out by various partners in 6NET.
Initially, each partner conducted IPv6 QoS tests on their local testbed infrastructure. Once these initial phases were completed, further QoS tests between partners across the 6NET infrastructure were performed.
The majority of the tests were concerned with the provision of IPv6 Differentiated Services. In particular, attention was paid to the provision of EF (Expedited Forwarding), AF (Assured
Forwarding), LBE (Less-than Best Effort) and BE (Best Effort) based services; their interactions and appropriate configuration and tuning of router resources.
In addition, the provision of Integrated Services using RSVP in a Mobile IPv6 environment was studied.
Most of the partners analysed the operation and interaction of QoS mechanisms, e.g. shaping or queuing, in local IPv6 testbeds or production networks and validated the performance of QoS implementations for different platforms, such as commercial routers from different vendors. Also, a QoS model that is capable for 6NET s backbone network was proposed and described.
In a second phase, partners took into account the defined QoS model and extended the QoS activity into 6NETs backbone network. Initially, the proposed QoS model, which is based on Differentiated Services (DiffServ) architecture, was studied taking into account several aspects, such as the network dimensioning process, policing and admission mechanisms
deployment. In particular, the 6NET QoS model included the implementation of the IP Premium service, which is based on EF (expedited forwarding) PHB (Per Hop Behavior) and provide absolute prioritisation to this type of traffic. It also includes the BE (Best Effort) and the LBE (Less than Best Effort) services. Afterwards, the appropriate configuration that allowed 6NET to provide QoS services was formed and possible conflicts with other network services were identified.
The configuration was applied to all 6NET s backbone network routers providing the aforementied QoS services to the connected NRENs. Finally, a number of tests were defined and performed in order to evaluate the performance of the QoS services in the 6NET network. The prioritisation method was initially examined, by testing the marking, traffic policing and traffic shaping mechanisms. A wide range of scenarios with various patterns of foreground and background traffic were performed in order to thoroughly investigate the applied QoS model and its impact.
The performed QoS tests in 6NET backbone indicated that this IPv6 QoS model can be the basis for production services. The mechanisms under test operated efficiently, as the experimental results prove, without any performance degradation on backbone routers. The above observations remained true even in heavy network congestion and the final performance results that a user or an application experienced corresponds to the QoS services specification.
It was noted that the IPv6 flow label is not currently used in the IPv6 world but its usage is expected be increased in the near future. The IPv6 flow label has been recently standardized and prior to become widely adopted form the applications many aspects, such as security and admission control, have to be investigated in depth.
UCL has deployed a Virtual Private Networked system with 6net, which provides for edge-based VPNs. The system deployed is based upon Defence Research and Development Canada (DRDC) agencys Dynamic VPN Controller (DVC) system which provides an entirely distributed VPN infrastructure established in the form of coalitions, with each DVC site maintaining its own set of security and access policies to its local "participating network resources".
Each coalition partner site runs a local DVC, which is connected to a common wide area network. Coalition partners make their "participating network resources" available through their respective local DVC. Each DVC maintains a local XML-based policy database, constructed via a Java-based policy editor tool, to dictate access to local resources. A web-based CGI-implemented user interface is provided for initiating and disabling coalition connections. In order to establish a connection when a partner makes a request to join a coalition, the local DVC initiates a connection to a remote DVC via SSL. The initiating DVC provides its security policies, which may be passed up to the DVC Operators at the remote sites.
GRNET developed or ported multiple management tools and some of them are tested in the 6NET testbed and GRENT production network. Unicast and Multicast Weathermap tools shows online link utilisation over graphical maps and OpenEye tool detects anomalies in the traffic patterns.
Despite the existence of stateless autoconfiguration for IPv6 (RFC 2462), there is still a need for DHCP. DHCP can be a complement to the stateless autoconfiguration where it can supply hosts with DNS, NTP and other configuration data. DHCP can also take care of address allocations, and replace stateless autoconfiguration completely. After many years of work, DHCP for IPv6 is becoming stable, and will be released soon as an RFC. However, it is based on the DHCPv4 address allocation system, and it is uncertain if the same scheme can be used for IPv6 where 2^64 addresses are available per link. Thus a stripped-down Ĝlight-weight" version of DHCPv6 was developed within the project.
Performing some of the planned IPv6 security tests had to be skipped due to the unavailability of testing tools operating in IPv6. Also, no large-scale security events were observed during 6NET's operation that would help to access the effectiveness of some of the measures.
However, measures were taken during the phases of design and set up of the 6NET infrastructure to couteract some of the IPv6 threats that could be envisaged. The experience gained from its day-to-day operation and the actual technical problems that had to be addressed helped to build a solid technical base and a deeper understanding of the main security issues.
The document produced can provide some help and guidelines to all parties interested in building a secure and functional IPv6 infrastructure.
The Westfaelische Wilhelms University Muenster has assisted the German National Research and Education Network (DFN - Deutsche Forschungs-Netz) to deploy IPv6. This has been achieved both through training courses and practical support. The benefits are that users connected to the DFN NREN can access the network using either IPv6 or IPv4, and the experience gained can be shared with other Internet Service Providers (also commercial ones) intending to deploy IPv6.
This result aims at developing an open high-performance IPv6 router oriented primarily to research applications. Liberouter is based on the popular PC/Un*x router platform and delivers improvements in three main areas: * performance * consistent configuration and management interface * routing daemons The performance issue has been addressed by the development of a modular set of specialised hardware cards known as the COMBO family consisting currently of COMBO6 motherboard and several alternative interface cards: 4× GE (metallic or SFP) and 2× 10GE (XFP). Performance-critical functions of the IPv6/IPv4 router data plane are being implemented as firmware for COMBO cards. The current version of COMBO6 is designed for the standard PCI bus, PCI-X and Express PCI versions are under development. Netopeer configuration system is designed as a uniform configuration interface for both PC routers and other router platforms (Cisco IOS, JUNOS) with version control. Router configurations can be transformed from native languages into a (mostly platform-independent) XML format and vice versa. XML configurations are stored in a repository based on Subversion software. For secure remote access, we intend to use an implementation of the netconf protocol. Under development is also the metaconfiguration application, which is oriented on computer-aided configuration of entire networks. The project also supports development of an open-source routing daemon, BIRD. This daemon already implements a number of unicast routing protocols (RIP, RIPng, OSPFv2, BGP-4+) and we want to add support for multicast routing (PIM-SM) and more unicast protocols, namely OSPFv3 and IS-IS.
Setting up the end site router and establishing an IPv6 infrastructure (including name service etc.) inside the organisation.
This infrastructure can be later used for other purposes since it provides IPv6 connectivity to outside world.
It is very common to do file mirroring on the Internet. The most common example is the mirroring of contents on FTP and Web sites. One example is the different Linux distributions that are accessed by thousands of users every day. To conserve bandwidth, CPU load, etc. volunteers set up public mirrors. There are also cases where a small company may have their own mirror instead of having all their computers access one single server over a possibly narrowband Internet connection.
The mirroring described above is generally done by unicast transmissions. An alternative for populating both large public mirrors and smaller internal ones could be multicast which further reduces the bandwidth consumed. When using multicast it could also be possible for end-hosts (not mirrors) to subscribe to updates and receive them as soon as they become available. This could in practice reduce the need for public mirrors. When receiving multicast contents like this, one should have some control of who is sending data, which means that it is natural to use SSM (source-specific multicast).
Multicast is not widely deployed on the Internet today. However it is available in academic communities and in NRENs and networks like GÉANT and Abilene. IPv6 multicast has some advantages over IPv4 multicast, and there is hope that it will be more widely deployed. For IPv4 multicast, the deployment of NAT boxes and some issues with layer-2 devices are 2 major problems. For IPv6, layer-2 multicast is a requirement for unicast to work, so this helps IPv6 multicast deployment in general. By adhering to the end-to-end model and avoiding inter-domain solutions like MSDP, IPv6 multicast should be easier to manage. IPv6 multicast is also easier to manage due to the well-defined scoping architecture.
The application MAD-FLUTE (http://www.atm.tut.fi/mad/) based on draft-ietf-rmt-flute-07.txt fulfils many of the needs above. The work in 6NET was to build a surrounding framework that can run the application at appropriate times, handle errors, cope with retransmissions or use IPv6 unicast for initial mirroring or filling in large blocks of missing data. The tool was deployed at some locations in 6NET, and later outside 6NET. It also evolved into a showcase demonstration.
To facilitate the introduction of VoIP services in IPv6 networks, the Fraunhofer Institute Fokus has developed and tested a complete VoIP infrastructure that not only provides services with a comparable quality to the current commercial VoIP services in the IPv4 world but also supports VoIP communication between IPv4- and IPv6 networks. In the context of the 6NET project, FhI Fokus has been working at providing a technical solution that not only enables VoIP services in IPv6 networks but also in heterogeneous environments comprised of IPv4- and IPv6 networks. To provide a VoIP solution for heterogeneous IPv4/IPv6 environments a SIP-based VoIP infrastructure was developed consisting of: (1) VoIP signalling infrastructure: Establishing a VoIP session involves the exchange of signalling messages as well as the authentication and registration of users. A platform widely used in the Internet by various commercial ISPs and ASPs is an open-source project under the name of the SIP Express Router (SER) which is well known for its flexibility and robustness. To support VoIP communication in IPv6 networks, SER was extended to support IPv6 as well. (2) VoIP soft agents: To enable a user to actually start a VoIP call, he can either user a dedicated IP-based phone or a software tool running on a PC. To enable IPv6 communication, in the 6NET project an open-source VoIPv6 tool called BonePhone was developed, and another one, already existing for IPv4 (KPhone developed by the Wirlab Network research center, Finland), was extended to support IPv6. (3) Translation mechanisms: In order to enable communication between IPv4- and IPv6 users, some means of translating SIP messages between the two worlds is needed. For this reason, a translating gateway was developed which translates SIP messages so as to allow IP4- or IPv6 SIP devices to communicate with each other without requiring any additional intelligence, and translates the media traffic (RTP) between IPv4- and IPv6 networks. To achieve a wide public exposure, the popular VoIP site www.iptel.org was made also IPv6 capable. As a public presentation platform, www.iptel.org allows IPv6 users to access a VoIP server, request a VoIP identity and use a number of services such as call logs, voicemail and the such. Using the allocated VoIP addresses, users can utilize the VoIP service from their IPv6 networks.
The support of multicast using IPv6 was recognised early in the project as being of great importance, as there are many applications using multicast technology. These applications require globally unique group addresses, which may be permanent or transient, to exchange data amongst their peers. Whilst systems such as SDR or web based mechanisms provide mechanisms for domain specific allocation they cannot offer a globally reliable Internet wide service. A generic, simple and scalable mechanism was required, which can provide globally unique multicast addresses for user groups within specified time periods. Moreover the notion of Ĝscopeĝ in the IPv6 multicast address introduces an additional requirement: to be able to allocate a globally unique multicast address within a certain scope. Such mechanisms did not even exist for IPv4, let alone for IPv6. The Westfaelische Wilhelms University worked on this topic and documented a complete taxonomy of the IPv6 multicast addresses allocation problem. The main need today for an allocation mechanism is collision avoidance. In the SSM model, as the channel is defined by a group address and a source, a collision could only occur only if a host would like to be a sender for 2 different groups having the same address. Therefore, it is sufficient for a sender to choose different addresses for different channels, this is a purely local decision. In the ASM model, we can consider two kinds of collision. There can be an address collision, and addresses and ports collision. In the former case, the receivers would get both flows but would discard the bad one. The risk is a loss of bandwidth in the receiver sites. Note that with IGMPv3/MLDv2, a host can exclude unwanted sources. In this case the loss of bandwidth will be beyond the first hop router. In the case of address and port collision, there would be a loss of resources in receivers, applications receiving both flows. We can also differentiate collisions due from errors and collisions due to malicious users, wanting to disturb multicast sessions. The session announcement problem is closely related to the address allocation issue. Some implementations today combine IPv6 multicast address allocation and session announcement.
The innovation of 6NET ranged from the many service support development activities, through to the building and operation (including management) of the network, so that it could be used for the application trials. For example: * Auto-configuration, and the relationship between auto-configuration and User/Terminal management, multihoming, multicast, performance, and roaming. * Support for class-of-service (in the form of a 'Traffic Class' field compliant with the IETF DiffServ model). * IPSec * Development and testing of network services such as DNS, multicast routing, etc. * Design, implementation and test of both intra-domain and inter-domain IPv6 multicast. Interoperability with IPv4 multicast too. * Interoperability between IPv6 network services and IPv4 network services. Mobility (wireless-only LANs in an end-site environment, ranging from 802.11b, Bluetooth and 802.11a, through to the convergence of mobile and fixed network technologies. * New applications that will stress the network and be used to evaluate the benefits to end-users that IPv6 can bring, through the expanded IP addresses, integrated auto-configuration, quality-of-service (QoS), mobility and security.
Poland is the fifth country in the world that introduced IPv6 for their country code in the DNS Top Level Domain.
Poland is one of the largest consumer markets in Europe with nearly 40 million residents. With its inclusion into the European Union in 2004, Poland has seen increased trade with the West and represents a great opportunity for investment. The low number of .pl registrations indicate there are many high-quality domain names still available.
The DFN-Verein has followed the IETF IPng development actively since the beginning of the 90s and ran several generations of IPv6 projects to enhance theoretical and operational knowledge and raise the awareness in the research and educational environment in Germany. The current project is called JOIN, and is operated by the Westfälische Wilhelms-Universität (WWU) in Münster. WWU is also a partner in 6NET. While IPv6 address registration is done by DFN, the operation of a dedicated infrastructure (6WiN) is currently provided by JOIN.6WiN is connected natively to the 6NET infrastructure and tunnelled to GÉANTv6.JOIN is the main actor at the DFN operational meeting "Betriebstagung" that twice a year gives IPv6 information and presentations to the DFN users. The web pages www.join.uni-muenster.de are well known in Germany as a rich source of knowledge and contact point for IPv6 interested universities and institutes. About 30 institutions are already connected to the 6WiN. DFN is migrating the network G-WiN to a dual-stack network, making the dedicated 6WiN obsolete. The 6NET experience, especially WP2, WP3 and WP6 results and deliverables, are very important for DFN as a source of practical and theoretical background to achieve a dual stack solution. DFN is a member and one of the founders of the IPv6 Forum and of the German IPv6 Task Force. These and other relationships, conferences and regular published journals (DFN- Mitteilungen) are used as a forum to promote IPv6. In the 6NET project DFN has, additionally to WWU, another German partner: the Fraunhofer Institute (FhG) Fokus. This organisation is mainly working in WP4 and WP5. The special set-up in Berlin allows a native IPv6 access to 6WiN/6NET infrastructure enabling FhG-Fokus to have very good conditions for IPv6 QoS research and for other experiments. FhG-Fokus is contributing to MIPv6, AAA and SIPv6, in close co-operation with the DFN-Verein. There are also commercial ISPs in Germany with IPv6 offerings. DFN is peering with the majority of them at different exchange points, mostly at the DE-CIXv6. However the IPv6 services to DFN users are still experimental.
A short description of the reasoning behind the adoption of IPv6 in the Greek School Network (and probably the most practical goal we intended to achieve by deploying the new protocol version in a working network) was to replace the NAT scheme we were using for each site connected to the GSN. The decision to use NAT was taken at the early design phase of the network in the light of the unavailability of IP addresses. This scheme allowed us to interconnect about 5000 sites all over Greece. However today, and because of the NAT, we have to deal with many problems when trying to provide certain services to the remote sites. Teleconferencing is an example service with such problems. The following paragraphs present the actions CTI undertook in the framework of 6net. The project was divided into four discrete steps/tasks.
Task 1: The Study and Definition of Transition Strategy, IPv6 Addressing and IPv6 Routing Plan The first step was the definition of the Transition Strategy that should be followed in order to transform the GSN IPv4-only network to a dual stack (IPv4/IPv6) network. The design of IPv6 Addressing Plan and Routing Scheme for the new network was also decided at this early stage. The main focus of the address plan was on the Unicast address structure, and more specifically on the global and site aggregatable addresses. The Link local addresses did not need design consideration as the assignment on Cisco routers is done automatically, while the global and site addresses needed manual provisioning.
Task 2: The deployment of IPv6 in Distribution Network (Dual Stack Network) The next step was the deployment of IPv6 in the Distribution Network. For this purpose the following actions were necessary: o The IOS upgrade in the main routers (Cisco 7206VXR) of the Distribution Network to a version that supports IPv6. Special attention was paid at the undisruptable operation of the services provided prior to the IPv6 deployment. o The implementation of the IPv6 Addressing Scheme. o The setup of the designed Routing Scheme. o The verification of the smooth operation of the infrastructure.
Task 3: The Selection of Schools and their Preparation In the third step, the schools that are included in the project were selected. These schools connect to the network using ADSL. Schools with ADSL connections are more suitable to become the first testbed for the deployment of IPv6 since these schools are connected to the PoPs of Athens and Thessalonica. The only two Broadband Remote Access Servers (BBRAS) of the ADSL provider are hosted in these two towns. Since the IPv6 protocol is not supported by all types of equipment that is installed to the schools, we made all the needed hardware changes and upgrades to the equipment of the chosen schools in order to gain full support to the IPv6 protocol.
Moreover, for each school we prepared and setup the new configurations for the routers. The last necessary action for ipv6 support in the remote sites was to enable ÉPv6 in the School PC Labs. In these labs the majority of hosts run on various versions of Windows operating system and in a smaller number of schools there is a Linux host too. Task 4: Enabling IPv6 in Basic and Advanced Services of GSN The last step involved the change of certain services in order to become IPv6 aware. These services are the Directory Service (SUN ONE Directory Server is used), the Radius Server which performs the Authentication Authorization and Accounting - AAA operations (Radius Server is used), the Domain Name Service (Bind Name Server is used), the Web Service (Apache Web Server is used), Electronic Mail Service (Qmail is used) and the Instant Messaging Service (jabber is used).
UCL have developed and deployed a Session Initiation Protocol (SIP) based VoIP infrastructure for integrated IPv6 and IPv4 IP telephony. The system utilises components from a number of sources, including Fraunhofers iptel.org SIP Express Router and Mini SIP proxy, and Asterisk.orgs Open Source IP PBX. The system provides for interconnection to the Public Switched Telephone Network (PSTN). Also a SIP conferencing server allows for multiple participants to join an audio conference. In addition an H.323 Multipoint Control Unit (MCU) provides for hosting of H.323 audio and video based conferences.
The system provides for deployment of any type of SIP user agent including soft and hard-phones, running either IPv6 or IPv4. The management of the system is possible through web based configuration pages, allowing control over users and conferencing facilities.
6NET created a virtual "Help Desk" to assist network administrators and end users, particularly those in European ISPs, universities, colleges and schools, in deploying IPv6. The intention is to make the wealth of experience built up by 6NET partners available to the European community. The people behind the virtual "Help Desk": Created a Website that conveys state of the art in IPv6 deployment, and offers visitors access to appropriate information to assist in their deployment of IPv6. Created a Website which includes the following features: - WIKI of developments by 6NET researchers (and other registered users) - Receive RSS feed of IPv6 news from www.ist-ipv6.org - Receive RSS feed of the latest IPv6 publications - Support a discussion forum for specific technology (hosts/routers/etc) Pass specific technology questions to nominated subject matter experts Attend IPv6 Workshops and Events to assist and to promote the Help Desk Maintain the www.6journal.org Website (adding new presentations and papers) Interface to/assist National IPv6 Task Forces and IPv6 Forum as appropriate Create links to - Interesting IPv6 applications - IPv6 resources - National resources Commercial enquiries are also welcome, which may lead to a further exploitation of 6NET knowledge from research to commercial deployment. The people behind the virtual "Help Desk" have built up a reputation as a virtual centre of knowledge/excellence for IPv6 deployment. The support of the service is continued through the IST-6DISS project. It was modelled on the successful formula originally used by the "JOIN" team at the Westfaelische Wilhelms University Muenster for supporting IPv6 deployment within the DFN and 6WiN networks.
CTI has worked on porting OpenH323 to IPv6. CTI has also worked on making applications that are based on OpenH323, like ohphone, Openphone and OpenMCU compatible with IPv6. These applications have been tested in the internal CTI network and over the 6NET network in cooperation with GRNET and other project partners. OpenH323-based applications have also been used as real-time applications for performing QoS tests over IPv6.
Local tests have shown success in communication between IPv6-enabled Gnomemeeting clients. Different setups have been tested both within a firewall and outside of it. Several QoS tests have been made in correspondence with CTI contacts and both audio and video tests proved a stable client. Gnomemeeting has also been tested with the use of S/W based, IPv6 enabled, MCU, OpenMCU, provided by CTI. Once again the tests completed successfully.
In many ways the issues IPv6 routing, IPv6 DNS, IPv6 multicast and security are very similar to the corresponding tasks in IPv4.
The work in 6NET was to focus on the differences between IPv6 and IPv4 in these areas and therefore builds on the IPv4 knowledge and understanding of the reader.
This Cookbook can be found in the 6NET Deliverable D3.1.2.
At Southampton University, a large departmental network (1,500+ users with around 1,000 hosts) was deployed for the students, alongside the original IPv4 network.
Southampton has been running IPv6 since 1996, but has only in the last two years adopted IPv6 as a production service in its network. The scenario described assumes no IPv6 is deployed beforehand.
This documented result includes a review of the systems components, an overview of the current status, next steps, and also the major remaining obstacles that have been identified.
Our motivation to deploy was in support of teaching, research projects, and communication with IPv6 networks (including those used by overseas students), while also encouraging innovation from staff and students indeed already we have seen new streamed radio (Surge/Virgin1) and multicast video services (ECS-TV2) emerge.
This work has contributed to the IETF v6ops WG enterprise scenario descriptions and analysis. We have documented our campus experience in an Internet Draft [Cho04a] and also documented the IEEE 802.1q VLAN approach to introducing IPv6 [Cho04b] that has also been used at the Westfaelische Wilhelms Univerity Muenster.
This deployment also provided input regarding deployment experience for the 6NET book.
The implemented solution is allows a MPLS VPN service provider to offer IPv6 interconnection services to other MPLS VPN providers (or customers). This solution is based on the intergrading the 6PE and Carrier Supporting Carrier (CsC) technologies. One advantage of the proposed solution is that the core MPLS provider does not have to upgrade the network in order to support IPv6 interconnection services. The needed functionality is enabled to the edge routers, i.e. the customers CPE routers.
Searching for OpenAIRE data...
There was an error trying to search data from OpenAIRE
No results available