We Need a "Demand Side" World IPv6 Launch
I was chatting recently with Michael Vincent, an IPv6 savvy colleague, about worldwide IPv6 adoption, which despite the considerable press around World IPv6 Launch, is progressing at a snail's pace. We lamented that while World IPv6 Launch provided great publicity around IPv4 exhaustion and the need for IPv6, the focus of IPv6 launch was on IPv6 deployment for the Internet supply side, i.e., websites. It's absolutely wonderful that so many organizations have enabled IPv6 on their websites, but where are the IPv6 users, or the demand side?
As IPv4 addresses dwindle in supply, service providers will ultimately need to begin assigning IPv6 addresses to their mobile and broadband subscribers. Nevertheless despite a growing number of IPv6 Internet users, these users will expect and demand ubiquitous Internet access, which requires connectivity to IPv6 and IPv4 websites. Therefore, each service provider will need to accommodate this customer requirement by either assigning both an IPv6 and an IPv4 address in a dual stack configuration, at least until IPv4 addresses run out, or by deploying address translators within their networks to convert IPv6 packets into IPv4 packets to reach IPv4 destinations.
Various IPv6-IPv4 network address translation schemes have been devised to for service providers to enable IPv6-addresss subscribers to access IPv4 websites, including NAT64, CGN, 6rd, DS-Lite, among others. I'll refer to the class of IPv4-IPv6 translators within these schemes as address family translators (AFTs).
Though AFTs are generally designed for scalability, they do have their limits. All IPv6-IPv4 traffic would need to funnel through these devices enroute from the service provider's subscriber devices to destination Internet sites. As the volume of IPv6 addressable subscribers grows, so will the volume of traffic at the expense of available shared IPv4 addresses and ports, and the capacity of daisy-chained AFTs. At the point of reaching such scaling limitations, subscribers' perceived Internet performance will suffer and customer dissatisfaction will rise.
The dual stack approach is the most flexible but by definition requires availability of IPv4 addresses (NAT444 and similar IPv4-IPv4 NATs are likewise scale-limited). AFTs serve as a temporary IPv4 extension technology, but at some point, this dam will burst and barring any new IPv4 extension technologies, the service provider will be faced with a large number of unhappy customers.
While we are perhaps a couple of years from this situation occurring, it makes sense to plan ahead with a concerted Internet community effort for a demand side World IPv6 Launch. This launch would entail service providers decommissioning AFT devices and enabling native IPv6 addressed customers to access IPv6 enabled websites. As unpleasant as this sounds, this would effectively define the dreaded "Y2K date" for organizations to implement IPv6 websites to enable communications with this sudden spike of Internet IPv6 users. Of course organizations missing the date can still catch up later.
As such this launch date would need to be far enough into the future that organizations can plan for it, but not too far that IPv4-extending technologies surpass their capacities. I would defer to a true Internet guru such as Dr. Geoff Huston, who could perhaps extend his IPv4 exhaustion analysis to derive the upper bound of this date.
Compliance with this date would be completely voluntary, but it seems we need a plan to address this Internet transition issue. Without a concerted plan, individual service providers will "hit the wall" independently and subscribers will suddenly face limited Internet access. They may flock to other service providers who still have IPv4 capacity, only to accelerate their IPv4 run-out. With a launch date a year or so out, organizations can make concrete plans and service providers can offer a more consistent Internet experience to subscribers no matter which protocol they are using.
As IPv4 addresses dwindle in supply, service providers will ultimately need to begin assigning IPv6 addresses to their mobile and broadband subscribers. Nevertheless despite a growing number of IPv6 Internet users, these users will expect and demand ubiquitous Internet access, which requires connectivity to IPv6 and IPv4 websites. Therefore, each service provider will need to accommodate this customer requirement by either assigning both an IPv6 and an IPv4 address in a dual stack configuration, at least until IPv4 addresses run out, or by deploying address translators within their networks to convert IPv6 packets into IPv4 packets to reach IPv4 destinations.
Various IPv6-IPv4 network address translation schemes have been devised to for service providers to enable IPv6-addresss subscribers to access IPv4 websites, including NAT64, CGN, 6rd, DS-Lite, among others. I'll refer to the class of IPv4-IPv6 translators within these schemes as address family translators (AFTs).
Though AFTs are generally designed for scalability, they do have their limits. All IPv6-IPv4 traffic would need to funnel through these devices enroute from the service provider's subscriber devices to destination Internet sites. As the volume of IPv6 addressable subscribers grows, so will the volume of traffic at the expense of available shared IPv4 addresses and ports, and the capacity of daisy-chained AFTs. At the point of reaching such scaling limitations, subscribers' perceived Internet performance will suffer and customer dissatisfaction will rise.
The dual stack approach is the most flexible but by definition requires availability of IPv4 addresses (NAT444 and similar IPv4-IPv4 NATs are likewise scale-limited). AFTs serve as a temporary IPv4 extension technology, but at some point, this dam will burst and barring any new IPv4 extension technologies, the service provider will be faced with a large number of unhappy customers.
While we are perhaps a couple of years from this situation occurring, it makes sense to plan ahead with a concerted Internet community effort for a demand side World IPv6 Launch. This launch would entail service providers decommissioning AFT devices and enabling native IPv6 addressed customers to access IPv6 enabled websites. As unpleasant as this sounds, this would effectively define the dreaded "Y2K date" for organizations to implement IPv6 websites to enable communications with this sudden spike of Internet IPv6 users. Of course organizations missing the date can still catch up later.
As such this launch date would need to be far enough into the future that organizations can plan for it, but not too far that IPv4-extending technologies surpass their capacities. I would defer to a true Internet guru such as Dr. Geoff Huston, who could perhaps extend his IPv4 exhaustion analysis to derive the upper bound of this date.
Compliance with this date would be completely voluntary, but it seems we need a plan to address this Internet transition issue. Without a concerted plan, individual service providers will "hit the wall" independently and subscribers will suddenly face limited Internet access. They may flock to other service providers who still have IPv4 capacity, only to accelerate their IPv4 run-out. With a launch date a year or so out, organizations can make concrete plans and service providers can offer a more consistent Internet experience to subscribers no matter which protocol they are using.
Comments
Post a Comment