Interoperability

University of Strasbourg

The decision to migrate Osiris to IPv6 was taken during 2002. The renewal of the backbone equipment, during 2003, offered the opportunity to invest in IPv6 capable routers. Quality of IPv6 support was then one of the main criteria for the choice of Juniper M20 routers. IPv6 connectivity was offered as well as IPv4 connectivity in early stages of deployment. The routing protocol was changed to IS-IS (OSPFv2 was used before) since the same protocol can be used for both IPv4 and IPv6 routing. Since all routing is done in the dual-stack backbone, IPv6 support in the core routers allows us to bring IPv6 traffic in all sub-networks without effort for the CRC nor for the local network engineers (~100 people) in the sub-networks.

However, the CRC did not open IPv6 connectivity in sub-networks without educating the local network engineers about the new protocol. We designed a one-day course about "IPv6 principles and client configuration". At the time of writing, 53 engineers have taken this course.

During the deployment of new routers, network services have also been converted to IPv6 :

• 
  DNS (all DNS servers migrated to BIND 9 to fully support IPv6)
  
• 
  Local host database and Web application, thanks to PostgreSQL which supports the IPv6 address format natively
  
• 
  SMTP relay
  
• 
  Mailbox server for ~3000 users, supporting POP3/POP3S/IMAP/IMAPS and Webmail
  
• 
  Web servers (Apache)
  
• 
  Anonymous FTP (various mirrors)
  

The new Wifi access network (~100 access points at the time of writing, ~250 by the end of 2005), which requires an authentication by either the 802.1X protocol or a captive portal, now fully supports IPv6.

On the client side IPv6 stateless autconfiguration is used as much as possible. Manually configured addresses are only assigned on "public" servers, whose addresses should not be changed. If you are interested, our addressing scheme is documented at http://www-crc.u-strasbg.fr/osiris/ipv6/plan-adressage.html. One particular sub-network is the one where the CRC workstations for our engineer's day-to-day use are located. All these workstations are dual-stacked, being a mix of FreeBSD, Linux (gentoo, debian) and Windows XP.

Connectivity to the Internet is offered by Renater, the French NREN (National Research and Education Network), via two 2.5 Gb/s links. Renater supports native IPv6 connectivity. Thus, no complex tunnel settings are necessary.

Now, the migration to IPv6 is complete for the core backbone and services. At the time of writing, 29 local sub-networks have been (partially or fully) migrated to IPv6, and around 500 different hosts on Osiris are regularly using IPv6.

The migration to IPv6 was a choice made for various strategic reasons:

• 
  Keep the CRC network engineers knowledge up to date and force them to increase their skills.
  
• 
  Be able to keep up with user's needs, since as a NOC (Network Operation Center), we don't have the right to be late.
  
• 
  Contribute to giving our students (and especially those in computer science) the best knowledge.
  
• 
  Contribute to the evolution of the Internet.
  

There were no identifiable migration cost. The routers had to be upgraded or renewed anyway, so the key element to IPv6 connectivity has been brought without cost. The engineering cost could be the largest one after the routers, but I consider this as a strategic investment towards a high quality operated network, where ROI cannot be computed by formulae.

Quote from the administrator: "There is no real technical challenges for moderately technical people, it is only a matter of ambition." The level of maturity of IPv6 is sufficient for implementation. Regarding the cost of introduction, we see this as an investment just as any upgrade of infrastructure. If I don't do it now, I will have to do it later. Introducing IPv6 is part of my challenge for my group to evolve. There wasn't any extraordinary cost associated with IPv6. We spent more money, but that was for investements in better redundancy, new equipment and air-conditioning systems, they were not related to IPv6 in any way."

ISP Case Study 1 - NTT Communications

NTT Communications decided to roll out IPv6 services to it customers in phases: a pre-commercial phase, a commercial phase, and follow-up releases to fill functionality gaps. This phased approach allowed for NTT Communications’ IP routing infrastructure to be gradually upgraded while taking on a limited, manageable number of customers, while internal tools were enhanced and testing continued. The 6bone was initially used for testing, and eventually internal, private labs were used. The entire process was treated as a product development process – treating IPv6 not just as a technology, but also as a technology that needed to be packaged in a manor that could meet the needs of customers that have a desire to be on the leading edge of IPv6 deployment. No elaborate business case was developed, and NTT Communications realized that IPv6 alone would not open revenue floodgates. But a business decision to commit to providing IPv6 Internet access products was based on the premise that IPv6 could be used as a differentiator to land new customers in an ever-competitive ISP market and to gain access to new market verticals.

The first phase of IPv6 deployment, which was launched in June of 2003 and was called “IPv6 Pre-commercial Services,” was relatively modest for a large ISP. Three Cisco 7206 routers running dual stack IPv4/v6 were deployed in Los Angeles, San Jose, and the Washington D.C. area. The majority of the NTT Communications backbone remained IPv4 based with tunnels over the backbone between these three locations and the various IPv6 peering points. Only a handful of customers were brought on during this phase. Customers in any of these three geographic areas could receive native or dual stack service while customers in other locations in the US could get IPv6 access via tunneling (RFC 2893 manually configured tunnels) to one of the three 7206 routers. The pre-commercial phase allowed engineers to continue testing Cisco’s IOS and Juniper Networks’ JunOS and allowed time for the entire global NTT Communications backbone to be upgraded. It also allowed for provisioning and support procedures to be tested and for NOC (Network Operation Center) personnel and other support staff to be trained.

In addition to making the routing network IPv6 capable, there were a number of other pieces to consider before launching a commercial product. Customer expectations are set high when paying for a commercial service. And from the ISPs standpoint, to make money on a product it must be able to scale and be supportable. Therefore a number of other tools and systems also needed to be in place. Router configuration tools needed to be upgraded to support IPv6 as well as NTT Communications’ route registry and internal address allocation database. DNS resolvers and servers needed to be upgraded to not only serve IPv6 record types (support was added for AAAA records and the ip6.int and ip6.arpa reverse formats), but also serve these records via either IPv4 or IPv6 transport. The customer portal needed to be upgraded to display IPv6 usage data, albeit over an IPv4 transport. NOC operational and troubleshooting tools were upgraded to accommodate a dual stack network. Finally, the SNMP infrastructure and SLA monitoring systems were upgraded to support IPv6. The transmission of data for these systems at times still used IPv4, but they had to at least be capable of monitoring IPv6 network elements. The difficulty and cost of this effort was greatly reduced by years of planning and the decisions made during software and hardware purchases.

By the end of the year 2003 the main support systems were in place and the entire, global NTT Communications backbone (Asia, Australia, Europe, and North America) had been upgraded to run dual stack. The AS2914 core was upgraded first, followed shortly thereafter by the aggregation routing infrastructure. In December of 2003 NTT Communications launched commercial IPv6 Internet access in the US, albeit with some functionality limitations when compared to its IPv4 product suite. Outside of the US commercial IPv6 service had already been launched in most other NTT Communications regions. Three types of IPv6 access were supported:

• 
  Native IPv6 (available at every NTT Communications POP)
  
• 
  Manually configured IPv6 over IPv4 tunnels (RFC 2893)
  
• 
  Dual stack IPv4/IPv6 Internet access
  

Figure 1. NTT Communications IPv6 Network Map Highlighting IPv6 Peering Points

At the time of the commercial launch, a few gaps still remained between NTT Communications’ IPv4 and IPv6 services. This was partly due to internal development time constraints and partly due to vendor feature support. Follow-up releases have allowed NTT Communications to fill these feature gaps. These releases have added IPv6 support for enhanced IP services such as shadow circuit support, managed router services (where NTT Communications manages the customer’s IPv6 or dual stack CPE) and off-net tunneling. The latter allows customers of a third party ISP to connect to the NTT Communications Global IP Network via a tunnel (either RFC 2893 manually configured tunnel or GRE). This has been a popular feature since it allows customers of ISPs that do not support IPv6 to access the IPv6 Internet and it is relatively inexpensive.

NTT Communications was the first global ISP to support commercial IPv6 Internet access services. Due to proper planning and foresight the process was relatively painless and inexpensive. No capital budget was ever specifically allocated for the project of rolling out dual stack IPv6 to its IP network. Changes to support IPv6 were carried out through normal upgrade cycles over the course of a couple years. Some capital was eventually spent for Cisco 6509 sup720 card upgrades and router memory, but this was a relatively small amount. Like any product development process, there were expenses for employee training, code development to enhance internal tools to support IPv6, and for testing. This phased approach allowed NTT Communications to launch IPv6 services while still solidifying internal process and tools as it bought time to continue testing on features that needed to be developed, and allowed vendors to add features. Follow-up releases were then launched which could support a greater number of customers on a more flexible set of IPv6 access options.

NTT Communications' IPv6 services have been very successful. They report more than 500 IPv6 customers globally. The IPv6 product offerings have strengthened the company's position in some market segments, like educational institutions, and have opened the door to new verticals such as high tech manufacturing companies and the wireless industry. The benefits have greatly outweighed the expense of deploying IPv6 services.

ISP Case Study 2 - Sprint

Sprints IPv6 history in short:

• 
  1997 - Obtained 6bone address space (3ffe:2900::/24), router below desk
  
• 
  1998 - Totaling 15 customers using tunnels to 6bone
  
• 
  1999 - Totaling 40 customers using tunnels to 6bone, move router out to the network
  
• 
  2000 - Obtained ARIN space (2001:440::/35? /32), Totaling 110 customer using tunnels to 6bone.
  
• 
  2001-2002: Added 4 more IPv6 capable PoP’s (Brussels, Washington DC, San Jose, New York), Member of the NY6IX exchange, Turning up customers at 2-3 per week.
  
• 
  2005 - 375 IPv6 Tunneled Connections; 2 Native
  

The IPv6 offering is free to any IPv4 customer of Sprint. Sprints goal is to promote the usage of IPv6, within the confines of the current abilities of the protocol.

Sprint’s goal is to remain at the fore-front of IPv6 from a technology/standards standpoint (for it’s transport services). They are committed to following the market (with a little help if necessary) and not willing to put themselves in an irreversible position, based on a deployment today. Thus the deployment they have chosen. Their strategy can be summarized as "Watch, adapt, and learn".

This book has been reviewed over IPv6

Received: from [IPv6:2001:8a8:20:1:202:b3ff:fe8d:c678]

([IPv6:2001:8a8:20:1:202:b3ff:fe8d:c678] helo=dachs.cyberlink.ch)

by salmon.maths.tcd.ie with SMTP id ;

31 May 2005 21:34:32 +0100 (BST)

This way I learned that my ISP Cyberlink (http://www.cyberlink.ch) not only hosts my website on a dual stack webserver, but also my mails can go out over IPv6. So I asked him whether he would share his setup and experience with us. Here's Cyberlink's information:

When we had our first customer requesting an IPv6 web hosting (you may know her, her name is Silvia) in 2001, we (Cyberlink) already had 6bone tunnels to our private playgrounds. So we had already done our first steps and gathered some experience with IPv6. The next step was to get an IPv6 uplink to the 6bone and we created an inventory of the systems and software that needed to be IPv6 ready. They were the following:

• 
  Cisco Router
  
• 
  Web-Hosting Server (Debian Linux 2.4)
  
• 
  Webserver Software (Apache)
  

The Linux Kernel was already IPv6 ready when we needed it. Not so the Apache 1.3 Webserver software we used for our webhostings. Only Apache 2 provided IPv6 functions which made it necessary to upgrade. Unfortunately it was not possible to upgrade to only one version because of module incompatibilities between Apache 1.3 and Apache 2.0. Only newer PHP versions (>=4) were running on Apache2 and we still had customers running applications on PHP version 3.0. Also the frontpage module of Apache2 was not compatible with the way it worked in 1.3, making it impossible to migrate the customers. So we had to setup Apache 2.0 in parallel to version 1.3. On the web hosting side we still run the same software but made progress with other services. With email and DNS over IPv6 cyberlink.ch was one of the first domains to have an IPv6 reachable nameserver registered. One problem that threw us back to the stone age was the Linux Firewall Software. IPtables did not (and still does not) provide stateful IPv6 filtering! So we had to go back to check TCP options on packets to get secure servers.

Two years after our 6bone connection, we were ready to offer more professional services. We registered our own IPv6 space with RIPE. Most of our POP and housing environment was IPv6 ready, the only missing thing was upstream connectivity. There was no native IPv6 on all exchanges we are on, and no upstream providers which offer it. As our first upstream, Switch is a non-commercial entity and they tolerated us on their network. So we decided to switch to one of our upstream providers even though they only provided IPv6-in-IPv4 connectivity to their IPv6 test network.

Now you want to know what our mail setup looks like so Silvia can have her book reviewed over IPv6 in 2005? The mail server is based on qmail (http://www.qmail.org) for SMPT, vpopmail (http://www.inter7.com) for Pop and courier-imap for IMAP (http://www.courier-mta.org/imap). Qmail installations use the tcpserver program to accept connections and forward the streams to the MTA, Pop, or IMAP server. So to enable IPv6 it is sufficient to have an IPv6-capable tcpserver. To send mails over IPv6, the basic qmail installation needs to be patched with qmail-send, just another component of qmail.

Today our internal LAN is fully dual stack and we offer most of our services over IPv6:

• 
  ADSL connectivity
  
• 
  SDSL on most of our POPs
  
• 
  Housing/Rack space with IPv6 upstream
  
• 
  Web-/Mail-Hosting
  

Using IPv6 for quite some time we have some learnings to share: You need to be persistent and keep asking your software, hardware or upstream suppliers again and again to provide support for IPv6. The network layer is ready for IPv6. Many applications are ready to be used over IPv6. Most problems are related to the IPv6 address format. Log parsers and management frontends for various softwares ignore IPv6 completely. Be aware that you need to protect your network for IPv6 separately. With a dual stack network you have two entry points to protect. The customer does usually not ask for IPv6 yet, you have to address the issue and make him aware of the implications and opportunities.

What is missing?

This section outlines some of the missing pieces for broad IPv6 deployment. We hereby refer to a report created as part of the 6net project.

IPv6 Routing

The routing in the Internet will probably not be optimal in the early days. This is due to the fact that in the beginning most of the Internet is IPv4 based and IPv6 tunneled. With the growing number of IPv6 Internet backbones this situation will change. Check with your ISP how he is connected to the IPv6 Internet. When you use tunnels, check the options you have and choose your tunnel endpoints carefully.

Protocol selection on dual-stack nodes

As already mentioned in the DNS section in Chapter 9 a way has to be found to optimize address selection on dual-stack nodes. The behaviour of a dual-stack node largely depends on the implementation. If both protocols are available a choice has to be made, either by the application or by the protocol stack. The presence of A or AAAA records in DNS is no indicator to the dual-stack client which protocol is the better choice and whether the application is reachable over both. There are many possible situations and combinations possible here. The situation has to be analyzed and the best possible configuration chosen individually.

Multihoming with IPv6

Multihoming is when a host or a site is reachable over different IP addresses. A multihomed host is a host with multiple global IP addresses. These addresses can come from one or more different providers and they can be assigned to one or different interfaces on the host. A multihomed site is a site connected to the Internet with multiple global IP addresses from one or different providers.

The main reasons to configure multihoming are the following:

• 
  Redundancy. When a link fails, the connection can be maintained over the alternative link(s).
  
• 
  Load Balancing. To provide more throughput traffic is balanced over two or more links.
  
• 
  Cost. It may be desirable to have multiple providers, for instance because one provider may have a better offering for certain types of services.
  

The autoconfiguration features of IPv6 support an easier maintenance of multihoming scenarios because devices are more flexible in recognizing network prefixes and can configure multiple IPv6 addresses based on Router Advertisements.

Multihoming is an actively discussed topic in the working groups. There are a number of interesting drafts, which can be found at the Multihoming Working group at http://www.ietf.org/html.charters/multi6-charter.html. They not only discuss the operations and known limitations of multihoming with IPv4, they provide lists of things to look at when designing multihoming, discuss architectural approaches and possible threats for multihomed sites.

RFC 3582, "Goals for IPv6 Site-Multihoming Architectures" sets the goals for new multihoming architectures. Find a thorough report on possible multihoming solutions called "Evaluation of Multihoming Solutions" at the 6net Website (http://www.6net.org).

DNS

Resolving DNS names over IPv6 is not implemented in all operating systems. With BSD and most Linux resolvers this is not a problem. Windows XP does not support it yet. This means that a client that does not have a resolver that can resolve over IPv6 always needs to be dual-stacked.

Not all official registration agencies offer the registration of IPv6 DNS domains. This is of importance if you want to register IPv6-only services.

Network Management

The most important standard for network management is SNMP (Simple Network Management Protocol). There aren't many implementations of SNMP over IPv6 yet. You can monitor your IPv6 network with SNMP over IPv4 though. So you only have a problem if you want to monitor an IPv6 only network.

The number of IPv6 MISs (Management Information Base) is still limited and there are no IPv6 Multicast MIBs yet. If you need an updated list of available MIBs, visit your RFC search engine and enter the search term "MIB".

A similar problem exists with the management of wireless access points. There is no problem to run Wireless LANs with IPv6, this is frequently available. But the configuration and administration of wireless access points is usually only possible over IPv4 or the serial interface.

IPv4 Dependencies

In a huge effort all existing RFCs have been analyzed for dependencies on IPv4 addresses. The results of this analysis has been published in a number of RFCs.

• 
  RFC 3789 - Introduction
  
• 
  RFC 3790 - Network protocols
  
• 
  RFC 3791 - Routing protocols
  
• 
  RFC 3792 - Security
  
• 
  RFC 3793 - Sub-IP
  
• 
  RFC 3794 - Transport protocols
  
• 
  RFC 3795 - Applications
  
• 
  RFC 3796 - Network Management
  

Download 70.03 Kb.

Share with your friends: