| Several interesting conclusions and observations were drawn from the process of designing and deploying IPv6 in RTPCom's network: RTPCom justifies the significant undertaking to migrate its network to dual stack by the pressing need to enable it for new, scalable services. In particular, the support of multicast services is fundamental to its strategic plans of offering multimedia content to customers. RTPCom's long-term commitment to IPv6 made the idea of a one-step migration more palatable, it has to be done so might as well do it right from the start. Although IPv6 has all the features necessary to implement service models similar to the one used for IPv4, RTPCom decided to take advantage of this migration and use a new design. This design encompasses all the improvements it wanted it could do on its IPv4 infrastructure and all the elements necessary to support new services such as multicast. RTPCom planned the IPv6 adoption well in advance and in that context it purchased and upgraded equipment with IPv6 support in mind. The few scheduled upgrades it went through up to the point of deploying IPv6 refreshed enough its network for RTPCom to require minimal investments in upgrades specific for the deployment. User provisioning remains a concern for RTPCom. Although stateless autoconfiguration and DHCP-PD are practical mechanisms, they require a lot of provisioning done on the router. The problems could have been eliminated with the use of PPP; however, RTPCom decided to avoid the additional encapsulation. It also thinks that it can manage this issue in these initial phases of the deployment but will continue to investigate alternative options. One immediate limitation experienced with this design is the fact that it is difficult to offer more than one ISP for the Internet access services. In the case of IPv4 the customer traffic is tunneled to the resources (LNS) dedicated to the ISP it selected with its subscription. In the case of IPv6, this is difficult because all subscribers are using RTPCom's address space. One possible way to solve this issue is to reserve a few bits in the addressing scheme that would identify the ISP selected by the customer. Policy routing would be used to route the traffic to the ISP based on the source address. Nevertheless, the ISPs will have to use prefixes from the address space allocated to RTPCom. RTPCom deployed the multicast service MLD access control for time-to-market reasons. This mechanism can also be provisioning intensive, but it is considered a manageable problem compared with the benefits provided by running the service. As the customer base for the content delivery service increases, RTPCom will migrate to MLD AAA to gain granularity in the way it offers service. This will reduce the service provisioning requirements, too. From a design and maintenance perspective, it is beneficial to apply QoS policies to various services independent of the IP version used for transport. In the case of RTPCom this approach was not a good fit. The existent infrastructure did not have QoS enabled so the IPv6 deployment could not benefit from a preexistent QoS service. On the other hand, the suite of IPv6 services is a superset of the IPv4 ones, so it is natural to have some IPv6 traffic types (for instance, multicast) treated in a specific manner. Security became a more prominent concern for RTPCom with the deployment of IPv6. With the new service model used, RTPCom's network elements are more exposed to attacks. The new services and the specifics of IPv6 itself create new kinds of vulnerabilities. For these reasons RTPCom makes security policies reviews and updates a priority for its operations team.
With the IPv6 services successfully deployed in a dual-stack environment, RTPCom's planners are already looking at the next phase in network development. They are planning the migration to an IPv6-only network. In fact, its IPv4 service design positions RTPCom for a rather simple and straightforward migration. The PPPoE sessions of its IPv4 customers currently encapsulated in L2TP tunnels over IPv4, could be encapsulated in L2TP tunnels over IPv6 instead. As soon as its network management systems can operate in IPv6-only mode and the LNS routers are upgraded to dual stack, RTPCom is ready to completely remove IPv4 from most of its network. However, RTPCom's operations team understands well the importance of taking time to let changes settle and of getting familiar with the new protocol. For now, there is plenty of room to grow in a dual-stack environment. |
