Transcript - IPv6 Plenary 2

Dean Pemberton: Hello and welcome back to the IPv6 Plenary.

So in this session, we're going to be looking at IPv6 and LTE and to be honest, this plenary is where everything is happening.

We're really lucky in that we've got two evolutions happening simultaneously. We have the adoption of IPv6, plus we're lucky enough to be having a new mobile technology roll-out happening at about the same time.

For a lot of countries, their mobile networks far outstrip the penetration of the traditional wireline networks and it's not going to be long before we have someone like Randy standing up and saying, if we are talking about wireline, we are talking about the crumbs, you know; everything is going to be about the wireless.

Really, this panel discussion is entitled LTE and IPv6, but it really is for a lot of people about the future of the Internet and making sure that we can get IPv6 on this very important access medium.

More and more smartphones and other devices are connecting to the Internet. We heard a statistic on the first day about some crazily high percentage of Facebook accesses coming from smartphones. We need to make sure that when we're deploying these new mobile networks, that we're deploying them with the future in mind.

It would be easy to deploy them just with large-scale NATs, but I think we'd actually be missing a lot of the point and just really only dealing with just enough addressing to get by and ignoring the fact that we do have IPv4 exhaustion upon us.

I'd like to now go on and introduce our first speaker, Haijun Li. He works for the Department of Technology at China Mobile, where's he's responsible for IP address and domain name resource management. He graduated from Beijing University of Post and Telecommunications and he has more than 10 years of internet and telecommunications industry work experience.

Thank you, Mr Li.

Haijun Li: Good afternoon, everybody. My name is Li Haijun and I'm from China Mobile. Thanks, I'm very glad to have the chance to give the presentation and share our IPv6 experience with all of you.

My presentation has three parts, the first is the overview of IPv6 progress in China Mobile, the second part is the challenges of deploying IPv6, and the last part is our IPv6 working plan.

First, this is our summary of IPv6 progress in 2011.

In 2011, we have network trial and test in eight provinces and we also have end-to-end test in the labs before the trial. The test included LTE and service network, B-RAS, et cetera.

In 2011, we also have the first IPv6 TD test terminal successfully access the commercial 3G network in Beijing. We also obtain /20 IPv6 from APNIC.

Thanks, APNIC.

We complete two service development projects in our CNGI project. We have innovative IPv6 migration technology in science standard and our BIHP NAT is adopted as RFC 6535 and the LWIG is becoming a new WG for Internet of Things. TR23.975 is approved in 3GPP.

Now I will give the detail of our IPv6 progress.

We have large-scale IPv6 network trial in eight provinces. Our trial includes IP barrier network trial and wireline access trial, IMS system trial and we also have the DSL/PON trial. In Guangdong, we have IPv6 metropolitan network, including 2G/3G, WLAN, wireline access network trial and test.

This is our GPRS IPv6 trial solution. We test dual-stacks. GGSN distributes IPv4 private address and IPv6 address for the terminals.

We also test our PNAT/BIH solution and BIH module provides IPv4 address for the applications in the terminal and translates it to IPv6 address.

This is wireline access trial solution. We also test dual-stack and in L2CPE, terminals request IPv4 and IPv6 address from B-RAS directly. In L3CPE, CPE request IPv4 and IPv6 address from B-RAS for its WAN and request IPv6 prefix using DHCP to PD for the terminals.

We also have the BIH/DS-Lite/4v6 solution test and CPE should support IPv6.

This is our WLAN IPv6 trial solution. It's based on dual-stacks and our dual-stacked ACs is upgraded to support IPv4 and IPv6 access. Our portal system is also to be rebuilt or upgraded to realise IPv6 authentication.

In 2G and 3G commercial network in Beijing, we upgraded to support IPv6 and we used TD-SCDMA device, ZTE U900 successfully to access the network. This is the first time IPv6 TD-SCDMA terminal access into the commercial network. We also cooperated with Marvell.

The second TD-SCDMA chip prototype is tested and with the chip, more IPv6 TD-SCDMA devices prototype will be tested later.

In China, CNGI means China Next Generation Internet.

Since 2005, an IPv6 backbone network with more than 30 routers has been built up in eight cities, in China Mobile. Our IPv6 network management system is also built up. We provide some IPv6 service in CNGI, such as home network service providing downloading HD-TV service and Olympic Games on demand and new programs based on IPv6 WAP platform.

We provide ultra-HD VoD demo carries more than 50Mbps.

Our PNAT/BIH means bump in host. The BIH model is transparent to conventional IPv4 application, whereby it avoids modification of various applications and facilitates IPv6 deployment.

BIH is one solution trying to migrate and deploy IPv6 and IPv4 co-existence networks without any technical gaps.

The BIH has been contributed to open source community. The source can be downloaded from the below link.

In 3GPP, the TR23.975 is approved by 3GPP as IPv6 migration guideline. The main content including IPv6 migration architecture based line is clarified and IPv6 migration scenarios are identified and candidate solutions are documented, including dual-stack, NAT64, GI-DS-Lite, BIH, et cetera.

The lightweight implementation guidelines, LWIG, is to solve the problems for Internet of Things. The problem is if not specified clearly, smart sensors with reduced IP protocol suites could not interoperate with each other. LWIG WG was formed in March 2011 to document the current implementation practice in the area.

Now I move to the second part, challenge of deploying IPv6.

First, I want to give a brief introduction of LTE and TD-LTE. As we all know, we have 2G and 3G. 3G has three types, WCDMA, TD-SCDMA and CDMA 2000. In China Mobile, we have the 3G network, TD-SCDMA. LTE means long-term evolution and in LTE, we have two modes. One is FDD and one is TDD. TD-LTE means TDD mode of LTE.

In LTE, the peak rate is much faster than 3G network.

Why we said it's challenging, because large amount of IP address is needed in LTE. In LTE, IP address amount is about 20 to 40 times of that in 2G and 3G and we know LTE is always on service, which means whenever the terminal turns on, no matter whether a service will be used or not, IP addresses should be assigned to the terminal.

Multiple APNs is needed for LTE. Multiple IP addresses should be assigned to one LTE device. So we need very much IP address in LTE. So we say IPv6 is essential for LTE.

IPv6 in LTE should be promoted.

We also say IPv6 is also important for TD CDMA or 3G network, because when a terminal is switching between LTE and 2G/3G network, service continuity should be supported. Some IPv6 service should be supported by 3G network. But now TDS CDMA terminals are not ready for IPv6 deployment, so it's another challenge.

Another challenge is how to improve terminal's IPv6 capability. In terminal's application, it should be able to work both on IPv4 and IPv6 stack. The OS of terminal should support IPv6 stack. In TD and TDD-LTE terminal, software should be upgraded to support IPv6 and the chips are also needed to be changed to support IPv6. In WLAN terminal, chips are not needed to change.

Another challenge is the application and the equipment are not ready. As we know, all self-service platforms in China Mobile's network are IPv4 only now.

Most clients are IPv4. We know, most websites are IPv4 according to the statistics by Alex, and 1 per cent of the top 1 million websites support IPv6.

According to our test, some important data equipment in IDC, such as firewalls and load balancers, do not support IPv6. Our test result shows that IPv6 capability is not supported well in some equipment. For example, DHCP v6 server function is not supported in four types of B-RAS from three vendors.

I move to the third part, IPv6 working plan. China Mobile will promote IPv6 in the end-to-end industrial chain and carry out large-scale experiments and trials in the next few years.

Our plan has three periods. The first period is start-up period from 2011 to 2013. Our target is to 2013, we do IPv6 experiments and trials in related provinces, develop about 3 million subscribers and we hope to produce more and more LTE/3G UE support IPv6 with the association of manufacturers.

The second part is promotion period from 2014 to 2015. Our target is to 2015, we complete network IPv6 transition and we start IPv6 commercial deployment and we develop more IPv6 subscribers.

The third period is application period from 2016 to 2020. Our target is to 2020, all the increased subscribers and service use IPv6 address and all the backbone and MAN use IPv6. These are our targets and plan.

About LTE terminal development. Our target is by the end of 2013, 5,000 TDD-LTE terminal prototypes, with at least four TDD-LTE new terminal chips will be used in IPv6 trial and the terminal including TDD-LTE single mode mobile phone and data card and also include 2G/TD/TDD-LTE multi-mode mobile phone and multi-mode data card and also include TDD-LTE CPE.

According to our government IPv6 plan, we will have the large-scale network trial from 2012 to 2013. Our plan is to have TDD-LTE test and trial in, I think it's over ten cities, and we will have WLAN test and trial in six to ten cities and we'll have wireline access test and trial in four to ten cities and we will have about ten China Mobile's self-service platforms, including mobile reading/mobile mailbox, et cetera, will support to upgrade IPv6 provider commercial service.

The target is 3 million commercial trial users by the end of 2013.

Now the conclusion. The demand of IPv6 has become increasingly urgent, but the ecosystem of IPv6 is still incomplete and needs more work to accelerate the process, especially in TD and TDD-LTE. China Mobile is willing to work with industry and standard bodies to promote IPv6 deployment.

That's all. Thank you for hearing me. Any questions?

Dean Pemberton: Thank you very much. Do we have any questions from the floor? Thank you.

APPLAUSE

Dean Pemberton: I have a couple of questions. During the presentation, you gave quite a compelling argument for why IPv6 is essential as part of an LTE roll-out, saying that we have these connections that are always on, so we can't reuse the IP addresses quite so much. But in the other deployments that you have seen globally, are the other carriers who are deploying LTE also doing IPv6 or are some of them still not?

Haijun Li: I'm not sure.

Dean Pemberton: Have you heard of any other deployments that are using IPv6 within their LTE?

Haijun Li: I don't know.

Dean Pemberton: Okay.

Has anyone in the audience had any experience?

Cyrille Jerabek (OPT New Caledonia): Just to give you a hint maybe, is that we will try beginning of 2013, LTE pilot, and we will do it in IPv4. So this is just an element.

Dean Pemberton: Okay. So how are you solving the problems that were explained in the previous?

Cyrille Jerabek (OPT New Caledonia): No, we have not studied in detail. What I can say is probably for pilot and limited deployment, IPv4 is enough, but all the elements given by my colleagues are true, of course, and interesting. Thank you.

Dean Pemberton: Thank you.

Are there any other carriers out there looking to deploy LTE? I'll leave my further questions. I certainly know one of them, hence our next speaker. I will introduce Samir.

Samir is the director of product development at Verizon Wireless in the device evolution and technology group. He has over 14 years of experience in the telecom industry, having worked in both the vendor and the operator space. Over the past eight months, Samir has been leading various IPv6 related efforts at Verizon Wireless and his primary focus is on fixing IPv6 related issues on devices, networks and applications. These efforts culminated in Verizon Wireless's successful deployment in World IPv6 Launch Day.

So this is a really good place to take the panel to, because we have moved from a provider who is in their testing phase and really looking to deploy, to someone who has taken the full step and actually deployed.

Samir Vaidya: Thank you very much, Dean. My name is Samir Vaidya. I work at Verizon Wireless and my presentation is about IPv6 at Verizon Wireless.

I'm going to start off with some background.

Verizon Wireless for those who don't know, is the largest mobile carrier in the US, with over 94 million subscribers and we operate both LTE and CDMA network.

Our legacy network, which is CDMA network, which has 1X and HRPD coverage, only supports IPv4. Back in the day, I guess in the good old days if you want to call it that, we used to support globally routable v4 addresses.

But as the number of smartphones exploded, especially after the launch of the Motorola droid, which was the first Android device we launched, we started seeing very quickly that we're running out of IPv4 addresses.

Unfortunately, we had to start NATing v4.

In the fourth quarter of 2010, at about the same time, we launched our LTE network and recent statistics have shown that we're one of the largest IPv6 networks in existence and possibly from a penetration standpoint on mobile, we have the highest v6 penetration of any carrier in the world.

What were some of the drivers behind the move to IPv6? Early on in the design and development phases of the LTE network, we quickly realised that IPv6 was a necessity and not really something that was optional.

We went ahead and designed and built the LTE network with v6 capability, regardless of commitments from content providers to actually put up content. There's always exceptions to the rule and Google is one of them, but we didn't really have much commitment from other content providers.

Obviously, one of the key drivers was the v4 exhaustion and the issue had been exasperated by the sharp growth in smartphones and we were seeing a lot of people move from feature phones on to smartphones, which were always on, so we had to put in this work around of carrier grade NAT, which was problematic in certain situations. Specifically applications in certain protocols didn't work well with NAT and obviously it prolongs the move to IPv6 just in general, because it's easy to say we'll stick with v4 NAT, you know, NAT to NAT and it's just not something that we were comfortable with, because we didn't think that it provided best end user experience.

Also, specifically at least in Verizon's case and possibly other carriers, we used IP based authentication for certain carrier applications and as soon as we put in NAT, obviously this broke down. In some cases, we had to do a one-to-one NAT, which defeats the purpose of doing NAT in the first place.

So when we were looking at IPv6, obviously we realised that there's enough address space, we can provide a globally routable address again to all our subscriber endpoints and we wouldn't have to do NAT any more, which would result in higher quality connections.

To support the growth of mobile in general, with additional end-to-end devices and, like I said, the move from feature phones to smartphones, IPv6 was absolutely a necessity to support the accelerated growth.

What do we do as far as IPv6 and LTE goes? We early on decided to make a very conscious decision to require IPv6 as part of our device requirements and network requirements. We decided that if there were going to be any LTE devices, they would have to support IPv6. The argument can be made that we were starting out fresh with a brand new network and this was something easy for us to do and you can say that that is true.

But at the same time, there was a lot of risk involved in making such a move, but we thought that long-term benefits would definitely pay off. We used the transition technology called eHRPD, so that we'll get seamless mobility between our 3G and 4G networks and we support IPv6 over there as well.

So what are we actually doing with IPv6? A lot of the core elements in the network are addressed using IPv6 and we support dual-stack on the LTE UEs, so this is for all the APNs, not just IMS, we do it for IMS, Internet and two additional APNs that we support.

What actually ends up happening is when the device tries to bring up PDM connection with the IMSAPN, the UE requests both a v4/v6 PDN type as part of the connection request, but the network only assigns a v6 address, because today we don't see a need to provide a v4 address because all of the services we are running over IMS are v6 only, so we have the flexibility to support v4/v6 in the future, but today we are just doing v6.

Some of the services we have running over v6 are SMS over IMS and in the future we are going to do VoLTE.

SMS has been tremendously successful for us, delivering hundreds of millions of messages using v6 over IMS.

The other APNs, the Internet, Admin, App APNs are also all dual-stacked, devices get assigned a /64 prefix that's globally routable. The v4 side is unfortunately still NATed and I don't think that will ever change, but the devices prefer v6 over v4, so they will attempt v6 connections before v4. We had deployed this pretty big LTE network and it was operational for a couple of months, but the first true test we had of our v6 deployment was World IPv6 Day in June 2011. During this time, Google white listed VZW DNS resolvers and they left them white listed. What this effectively meant is applications that a user is accessing, Google applications that a user is accessing on LTE UE were being done over v6. We started seeing a bunch of latent issues popping up.

Specifically, we saw a bunch of peering issues, where traffic would leave the Verizon network but never make it to the Google endpoint, and then we also discovered a couple of network issues and, lastly, a bunch of device side issues.

Relatively speaking, most of these issues just ended up being an issue between Verizon and Google as far as the user goals, because most of the other content providers that turned on v6 on World IPv6 Day just did it for one day, so after that, Facebook, whoever else, had v6 turned on for a day and then it was turned off after World IPv6 Day, whereas Google essentially white listed the Verizon DNS resolvers and all Google services at that point were v6 capable.

In order to avoid any end user issues because of the issues we found with peering, network and device, we went back to Google and asked them to actually de-white list our DNS resolvers and this was mainly to fix any of the issues that we had found.

At this point, we said the next milestone would be World IPv6 Launch in June of this year, and basically you start eight months of really hard work on everyone's side -- Verizon Wireless, network vendors, device vendors and a lot of help from Google -- and we wanted to fix all these issues before we got to W6L. We did a bunch of updates to our test methodology that we were using for IPv6 related device testing and we updated a bunch of tracers capability we had in the network to pinpoint IPv6 related issues, so we could detect and resolve them very quickly.

The problem, though, we faced was with the de-white listing of Google services, we started masking a bunch of v6 related issues that we probably would have caught had we not de-white listed. What ended up happening is that a couple of devices with broken v6 stacks ended up launching that we had to go and retroactively fix after we discovered the issues.

We were left with a chicken and egg situation and the way we went about solving this is we went to one of our labs and we pointed the lab to the Google DNS resolver, so any time we were doing any testing in the labs, we were sure that we were going to receive Google services over v4 and v6, so that we did end up finding a couple of device side bugs, especially related to handover where we had some issues with stale DNS caches on the device side.

The one thing I do want to point out here is that some of these growing pains that we had being at the forefront of v6 deployment from a network side, is something that new networks that are deploying v6 today shouldn't face. Primarily that's because of what's happened after World IPv6 Launch. A bunch of content providers have turned on v6 permanently, so there's no longer an issue as far as not having enough content to test out network deployment.

I put this slide in here because I wanted to highlight one of the issues that I think is key, when you're deploying a dual-stack network or a v6 network.

The slide basically shows a synthetic test we set up where we set up a bunch of broken dual-stack URLs where the v6 endpoint would have valid DNS entries, but not actually allow connections. We wanted to benchmark how long a fallback would take from v6 to v4 on different devices.

Obviously, the results are all over the place, some device NOS configurations implement happy eyeballs, others don't. The reason for this chart really was more an educational purpose for customer care and to train people to understand, even if your network and devices are completely built rock solid and do IPv6 just as they're supposed to, any issue that happens between a device and an endpoint you are trying to connect to can end up resulting in end user experience behaviours that are not desirable, and we just wanted to show that as an educational tool for our customer care.

So then we get to World IPv6 Launch and when the criteria was announced for World IPv6 Launch, we realised very quickly that we met all the criteria to join, but we decided that we were going to hold off on joining until we had resolved any of the known issues that we had.

Once we did that, we did end up joining, but just like you would have with anything, as soon as we joined, we ended up having an issue where obviously between 2010 and today, we have significantly grown our LTE coverage and literally the day after we joined, there was a new LTE site that went up and someone fat-fingered the wrong IPv6 range and that ended up causing failures.

Unfortunately, I'm testing at my desk and I have no issues, but there are people, real customers, who didn't have issues yesterday, but are now having issues today.

Because of the tools we had put in, we were able to quickly pinpoint and resolve the issues, so the impact to customers was minimal.

One of the other important things is as part of moving towards World IPv6 Launch, we got in touch with some of the big content providers to get continuous statistics and failure rates as were being measured by the content providers for Verizon Wireless. We were periodically asked for failure rates, based on DNS resolvers, so that we could pinpoint which regions we were having higher failure rates in and then attack them region by region. But during the same time, we built a bunch of network based mechanisms to track and pinpoint, so we have bunch of automated tests that go on all the time to pinpoint v6 failures.

We knew of a couple of device side bugs. When we launched LTE, most of our LTE devices today are actually running Android, and Google at that time didn't support LTE on Android, so we had to get our device manufacturers to support LTE themselves on at that time what the latest release of Android was, either gingerbread or FOiL and we ended up finding a couple of bugs in Android.

Again, that's one of these things that's no longer an issue, because LTE is officially supported in Android as of ICS.

We had to push out a bunch of device updates and it's one of the national device cycles, so any time we were pushing out updates, we were also fixing IPv6 related items.

The biggest thing in my mind was really training and education. I think some of the difficulty we had, at least from a technical side, was that a lot of people didn't just get IPv6 in the company and the question I always got was, hey, so what is the end user impact of IPv6? Is the end user going to see anything different? If they are not, why do we really care? I think training and education was a key aspect, at least for me, to make sure that everyone up and down the company chain, really understood why we were doing this and was in support of doing this.

In preparation for World IPv6 Launch, we set up daily calls for months and worked through issues, some reasonably painstaking issues, but it was well worth the effort.

Post World IPv6 Launch, where are we? I would say that we had a very successful launch. We actually didn't find any issues on 6 June, which is World IPv6 Launch. If you look at statistics, we have grown 50 per cent in the last two months, as far as IPv6 traffic is concerned. The stats I pulled from the World IPv6 Launch website was on 8 June, we were doing 7.36 per cent traffic over IPv6 and in August, we are at 10.64 and similar stats from Google, who were at 10.7 and now 16.6.

Akamai released a study recently, I think earlier in the month, of all the traffic that Akamai sees, 38 per cent of all v6 traffic is from Verizon Wireless and we are double the next closest v6 provider.

We continue to see steady growth of v6 as more LTE devices get rolled out, a lot of people are moving from feature phones up to smartphones and they tend to pick LTE devices just for the network and the speed and we're seeing a very steady growth in IPv6.

Again, this is a slide from Google. The line shows where we were at World IPv6 Launch and the 16 per cent is where we are about today.

Then this is from Akamai, same stats: Verizon Wireless is contributing to 38.1 per cent of all Akamai v6 traffic.

In conclusion, hopefully I can impress on people who are here from network operators that you shouldn't really be scared of v6 and I don't think there's any reason to delay v6 on LTE networks. If you do go in and say you're going to support v6, don't be half-hearted.

It's very easy for someone to say, yes, we will support it, and then tomorrow decide to turn off AAAA. And it defeats the purpose. Make a decision and stick with it.

Regardless of what challenges, the challenges are definitely something you can overcome and I think Verizon Wireless has proven that.

I can tell you that you can do it and it can be done very well. We have learned a lot from our deployment and I think so have all the partners who have worked with us, network vendors, device vendors, OS vendors, they have learned a lot from the Verizon Wireless LTE deployment of IPv6.

Again, lack of content from content providers is no longer an excuse, as of again 6 June or 8 June, content providers, all the major ones, Facebook, Google, Yahoo!, Microsoft, they are all dual-stack, so there's really no reason why someone should use that as a crutch to say, you know, there's no need to have v6 on networks.

Ensure proper testing of your device and network.

I think this goes without saying, but we learned a lot that we had -- we thought we had pretty good test cases back when we launched LTE, but I think as time went, we realised that we didn't and we kept beefing them up. So this is really an ongoing process that we're involved with, and any time we find any new issues, we're going back and putting in new test cases to make sure we catch them as part of device certification or network deployment certification.

Last but not least, I think, really, ensure that there's enough awareness and training from the highest to the lowest levels of the organization to understand why IPv6 is important.

That's it. Thank you.

APPLAUSE

Dean Pemberton: Awesome. Another really good presentation showing that not only is it a good idea to do, but it absolutely can be done.

A question from the floor.

Geoff Huston (APNIC): I have an iPhone and it does v6 on WiFi, but not in radio. It just won't. I'm kind of wondering, in your service, which devices, which handsets, are actually capable of connecting in on v6 on radio?

Samir Vaidya: Our requirements specify that all LTE devices need to do v6.

Geoff Huston (APNIC): Which ones, really?

Samir Vaidya: I'm not going to comment on specific manufacturers' devices, but that is our requirement and we make sure that that's the case.

Geoff Huston (APNIC): My observation has been that the Samsung Galaxy S3 does it.

Samir Vaidya: It absolutely does.

Geoff Huston (APNIC): I'm not sure of many others, but one thing I did notice, which is the other part of this.

You put up some failover statistics. Interestingly, my iPhone, when it tries on v6 and it doesn't work and drops back to v4, does a flip back in 720 milliseconds and on a really good day, it does it in 719 milliseconds. The Samsung Galaxy S3 takes 19 seconds to do exactly the same failover. Have you any moves to try to improve that kind of performance, any discussions with the Android folk?

Samir Vaidya: I'll say I have had discussions about that, but what I'll tell you is that as of ICS, or probably even honeycomb, the Android browser does a failover in 300 milliseconds.

Geoff Huston (APNIC): So it's using the Chrome style failover now?

Samir Vaidya: Exactly. But applications, it's up to them to do the failover, so the failover is not there in the stack, but it is possible to do so, we did build an app and at least for internal users, app developers, we released proof of concept code on how to do the failover in 300 milliseconds, so it's absolutely doable.

Geoff Huston (APNIC): But the Android underlying TCP connect timeout is still sitting there at 19 seconds.

Samir Vaidya: I think it varies by device and that's what I was trying to show with the slide, but I have seen it all the way up to 189 seconds.

Geoff Huston (APNIC): 189, standard Linux, don't change things.

Samir Vaidya: Yes.

Richard Barnes (BBN): Geoff, to sort of respond to your question about devices, my wife's phone actually is a Verizon Droid Razr, which she thought was really cool when I showed her the dancing ... on World IPv6 Launch Day, so there is at least one other devise that does things pretty well and we should talk about whether I can do some tests for you.

Samir, you mentioned at one point in your talk that you guys had redone some tooling to help more quickly identify problems related to v6. Can you comment on what sort of changes you made to your tools and how they were able to help?

Samir Vaidya: In the beginning, we were just doing tests as part of device certification, but we essentially built out some tools that are running throughout the nation continuously, measuring IPv6 performance. Again, there's only so many dual-stack or v6 only websites that you can hit in a day, but we took basically the list from Alexa and we're trying to go through at least the top sites that we think most of our traffic is going to and we ensure that we have good connectivity between the device and endpoint.

George Michaelson: I have a comment from the Adobe Connect room. Lorenzo Colitti has said that Apple has committed that IL6 will support IPv6 on LTE.

Miwa Fujii (APNIC): Samir, thanks a lot. It was a very interesting presentation. You mentioned about voice-over LTE as a future project of Verizon. If you have any idea or knowledge about industry trend of voice-over IP on IPv6, in what sort of direction is industry moving and if there are any issues or challenges, what sort of things are we facing?

Samir Vaidya: Unfortunately, it's not something that I can answer, because it's not something I'm working on at all.

I do know that there have been challenges with standards on RNS and RNSC and so on, but I really don't know what's going on over there. Apologies.

Dean Pemberton: Anyone else on the floor? If there are providers out there looking at starting their LTE path, what would be your advice for a first step in integrating v6 into that? What are the first steps that they should be looking at so that they can kind of follow the path that Verizon has with embracing v6 so much?

Samir Vaidya: I think the first step is making the commitment and sticking with it. I think, like I said, when we were deploying it, we just went in it blindly.

We said we're going to do it because we think we need to and if the content follows, great. I think now the issue is not really an issue, but now the content is there, so I think doing a proof of concept is much easier today than it was back in the day.

Dean Pemberton: I mean, certainly we have heard a lot of operators, not just in the mobile space, but in the Googles and Facebooks, saying that things like World IPv6 Launch Day and then the larger launch, really helped them to focus and to get things going, but also without the little tests, they never would have found the bugs that they had to fix along the way.

Samir Vaidya: It's one of those chicken and egg things.

You have to have the content and the network and the devices and you have to be able to test everything and I do think World IPv6 Day was crucial, at least for Verizon Wireless, and then obviously we were able to go forward and aim for World IPv6 Launch as making sure everything was done.

Dean Pemberton: How do you think Verizon has benefited from this and has it made it easier for you to be able to design the network or run the network with only having one stack to worry about?

Samir Vaidya: We still have two stacks, we still have v4.

It's dual-stack. What I will say is the v6 deployment definitely has helped us with the larger scale NAT issue that we have and we're future proof. At this point, frankly speaking, I think we have done all the work and there's not much left.

George Michaelson: I have another question from the chatroom. This is from Saturo Matsushima, it's a question for Samir. Why do you choose a dual-stack PDM context for IMS even if it's assigned only in IPv6 address?

Samir Vaidya: That's really if we need to have v4 for some reason. It's not that right now it's v6 only, but the devices request both v4, v6, then we leave the control in the network to decide if it can do v6 only or both v4, v6 and right now, it's v6 only.

Dean Pemberton: One final question from me. A lot of mobile providers are providing a stateful firewall kind of feature for their users.

Are you looking at doing anything in that within v6?

Samir Vaidya: I do not know. I apologise.

Dean Pemberton: All right. Any more questions from the floor before we move on to our final speaker? All right. Our final speaker is Alastair Johnson, who is a senior product line manager at Alcatel-Lucent.

In his role, he works with customers globally to define requirements and future development for the Alcatel-Lucent 7750SR family of routers and particularly for IPv6.

Alastair Johnson: Thanks, Dean. I'm AJ. As Dean mentioned, my main responsibility with Alcatel-Lucent is on the IPv6 feature sets. I'm not a mobility guy myself, but I do work with our mobile groups and with our customers when operators do bring up the IPv6 question.

So I'm not able to give as much a detailed view into how mobile and mobile core networks actually work, but I have to look at a lot of the impacts on the wider network when v6 and NAT come into the equation.

I think we all pretty much understand from the previous two presentations -- which makes my life really easy, I don't have to do too much work now -- that mobile broadband and mobile environments are really where the substantial device growth is today. As we move towards always on, always mobile connectivity, everyone has a smartphone or N smartphones or devices that are attached to 3G or 4G networks. This has put pressure on how we number those devices. We have heard that from the previous two presenters.

As mentioned, we had two earlier or two deployment models, on the left side of the slide. A typical diagram there showing a network which has public IP addresses allocated to the user equipment devices, early mobile broadband or mobile IP sort of scenarios.

Public addresses on the device. This worked well 10 years ago, the number of devices that were attaching were pretty low, the people that could afford it were pretty wealthy, but as mobility became a more and more ubiquitous access to the Internet and particularly in emerging markets where wireline infrastructure didn't exist, the predominance of mobile broadband has substantially increased, so public IPv4 addressing was not necessarily going to last long term.

That pushed a lot of operators towards NAT, which has become, I guess, a default deployment model for a lot of mobile networks.

As that growth occurred, operators rolled out IPv4 NAT, some were able to use RFC1918 addresses, some felt that 1918 wasn't going to work or they simply needed more space than 1918 could offer. So squatted or martian space was used in some cases, with its potential detrimental effects on the Internet out there.

Typically, networks offer some NAT and no NAT options. A number of the operators I'm familiar with, you can choose a different APN or PDN ID to identify whether you're going to sit behind a NAT or whether you need a public IP address. In some cases, even you can opt out of a state 4 firewall, at least on the IPv4 side.

One of the things that a lot of operators have found and particularly as I have ended up diving into the large scale NAT game, as the subscribers and the traffic on the mobile networks increased, the number of NATs required substantially increased in the network. So this has pushed a lot of capex cost and ongoing a lot of opex cost to manage and scale and traffic engineer those NAT devices.

It's become an interesting challenge and it's much the same challenge, I guess, as any other network has on how do we attach more and more devices, more and more subscribers and continue to give them an IP address.

With the NAT approach, all of the standard drawbacks of NAT that we all know and love, applications that don't work, loss of traceability, IP based authentication no longer works reliably, the amount of traffic that we have to push through the NAT, all continue to exist to be the same sort of problem in mobile broadband environments.

Probably a little less obvious initially, because traffic volumes were low and people weren't necessarily trying to run anything more intensive than a simple web browser or a simple SMTP transaction through mobile broadband, but as mobile broadband in some areas has replaced wireline access, then it becomes more and more obvious that more and more things break.

As we know, that pressure has occurred on our IPv4 numbering resources. One thing I have recently looked into with one customer was scaling the number of NATs in their network that were attached to a single GGSN. That was quite an interesting exercise in how we could scale the traffic coming out of a GGSN, going into a NAT box and load balancing across multiple NATs.

This is a pretty complex operation to manage and something that requires a lot of ongoing attention, fair sort of care and feeding for the ops guys.

So this is where a few of the operators I have looked at, even in pre-LTE environments, 3G and even 2G, are saying we need to look at IPv6 here, because we're just having a lot of challenges with IPv4, particularly here in APAC, this is an ongoing problem, particularly any greenfield operator that's trying to build a network starting after last year, quite a few challenges with trying to put large numbers of subscribers into 1,000 IPv4 addresses.

As those mobile devices start to support IPv6, whether it be on a 3G or a 4G air interface, it becomes attractive to try and offload that traffic into v6 as fast as possible to avoid the complexities of continuing to grow the v4 network, continuing to patch this network together.

We end up with a little diagram that looks like that. We see in the case of a dual-stack environment or a NAT64 environment, that we end up with different outcomes, so that diagram there on the slide is depicting a NAT64 environment.

If you attended the session I gave yesterday looking at some of the transition technology. NAT64 has been one that has come up on a number of occasions for wireless environments where there's a desire to run only a single stack between the user equipment and the mobile core.

However, as we heard from Samir, that's not necessarily the way all operators deploy. Continuing to deploy dual-stack and using NAT44 is obviously a perfectly viable approach.

But one of the more interesting motivators for operators is always money and if we can reduce the number of edge NATs in total, that's actually been a positive business case for once for deploying IPv6.

We end up asking ourselves this question: why does IPv6 in the mobile access reduce the capex and opex? As we heard, there's a large amount of content today and a large amount of content that's frequently accessed from a mobile device that's accessible over IPv6. World IPv6 Day, World v6 Launch, really has triggered a lot of growth in the v6 accessibility and that's been really awesome for actually getting v6 adoption increase, hasn't it? So we end up, with a couple of the operators I have been talking to, with these two approaches. On the left-hand side there we have an IPv4, an IPv6 dual-stack network where we continue to use NAT44 just as we have always done in the IPv4 access, continuing to offer or now enabling IPv6 access, I should say, to the handset or to whatever the mobile device is.

From an IPv4 perspective, nothing much has changed.

We now can access IPv6 and potentially we are going to reduce the amount of traffic traversing our IPv4 NAT boxes which hopefully means we can buy less of them, and we have less traffic having to be forced through NAT.

In the right-hand side of the diagram there, there's the flipside approach. I have realised that I have just labelled one of my lines wrong -- no, I haven't. I'm looking at the wrong picture.

So there we offer native IPv6 services end to end and we also offer IPv6 with NAT64, so again a reflection of the diagram on the previous slide, where IPv4 accesses are preserved through NAT64 access, allowing only a single stack and the network.

I have heard from a couple of equipment manufacturers that this is attractive because it means they no longer need to support two stacks on the device.

That can make the device code a little bit simpler, potentially simplify testing and possibly even assist in battery longevity.

However, we're still in 2012. We still have too many devices that need to attach to the network that can't support IPv6, which means that we still need to support IPv4 and NAT for these legacy devices, which is an interesting challenge, I think. I haven't got into it enough and maybe I'll be able to catch Samir tonight and ask him about it.

But the tethering challenges or 3G/4G dongle challenges where you have CPEs that are still requiring v4 access in a v6 environment or how mobile operators envisage the tethering attachment and getting a larger prefix to support it.

To deploy the IPv6 topology depicted here, operators need to ensure that support is there in their mobile access, their mobile core, all of the support systems, generally speaking, we are talking 3GPP release 8 and onwards type support.

Looking a little bit deeper into the core, release 8 introduced the support of a v6 PDP type, so this is more applicable to 3G networks than it is to LTE, but LTE, I think pretty much from day 1, has always mandated or made a very strong requirement for IPv6.

So we have support, largely speaking, on all of the equipment in the mobile cores being deployed these days.

Most of the vendors, we have had our collective selves kicked, I think, by a lot of operators to make sure that we go back and support it as much as possible on older equipment that's deployed, to allow IPv6 deployment to occur in these networks.

When we get this v6-only PDP, we can attach this for v6-only services, so this could be useful for NAT64 type deployments. Or we can also get these v4/v6 dual-stack PDPs which allow us to run v4 and v6 services simultaneously. It does assume that you continue to offer those services, at least natively with or without NAT bolted on top.

This always requires, as it does with any other deployment and any other network type, to go through, look at all of the equipment in use, look at the support, look at what it does to scaling to use these types of PDPs.

Something that came up in the earlier plenary that I was talking about with numbered accesses for broadband environments is that, depending on how a subscriber connects to the network, to some of the equipment, they might look like two subscribers, which means that to enable a v4/v6 type deployment, you may find that your scaling numbers are exactly halved.

So that's something to look at with your equipment and your vendors and identify whether that's a challenge or not and what that means for you.

Obviously, any other systems that support, particularly for billing and metering and rating, needs to understand if it needs to talk over v6 or look at v6 counters or statistics.

One that I have seen mentioned a couple of times by some operators, both in public and in private, has been v6 in the context of global roaming. In some cases, operators are saying, we simply can't enable v6 when the devices are offnet because our relationships on a commercial level don't allow for v6 to be used. They specify only v4. Even if it works technically, we have this commercial barrier that means going back to legal and getting it renegotiated and re-signed.

That's an interesting one to look into, whether there are even national roaming, not necessarily global roaming, to look at whether that's going to impact your ability to offer v6 in an end-to-end service perspective.

Another area that has been coming up, this is an area that I will admit to having spent more attention on, has been how IPv6 impacts the mobile networks, particularly on a back haul perspective. I typically work more on wireline and core networks, so this becomes more interesting to me.

As the uptake in subscribers has occurred, obviously the uptake in traffic has occurred as well and thus we need to back haul traffic from the cell sites back into the mobile core with much higher bandwidth, particularly as we have seen how LTE substantially increases the access rates. No longer will a 2MG back haul circuit be sufficient.

What's happened here is packetized technologies, ethernet IP have become a very predominant backhaul access mechanism and IP and, indeed, IP MPLS have become very, very popular for this role.

So, say what you will about MPLS, it's pretty common here at this point.

What this has meant is that there has been an explosion in these routers that are being deployed out to every cell site and when you hear some scary numbers from countries like India, which have 200,000, 300,000, 400,000 cell sites in a single operator, before we start going into multiple operators, that's an awful lot of routers that are being deployed out of the network.

When Philip was going through his addressing architecture earlier this afternoon, there was a comment made, you know, using a /64 for loopbacks or a /48 for link nets should be enough. Is it really going to be when you have 100,000 or more routers in your network to backhaul all of this traffic? That's a big problem if you're using IPv4 today. We have had some conversations with a number of operators that have said, actually, we have so many of these routers, RFC 1918 doesn't scale, we're not going to publicly number them because they're effectively just smart transport nodes. What can we do here with IPv6? Can we use IPv6 solely to backhaul our traffic? So that's something that my group has ended up looking at quite a lot.

All of those nodes link and loopback addresses, if they are dual-homed, we now need to have multiple link nets per router and really, everyone has said this is not going to scale in IPv4.

As I mentioned there, IPv6 is an interesting solution to this particular scaling and pain problem that these operators have. We're end-to-end IP and indeed end-to-end IPv6 is available in the mobile core, IPv6 here in the backhaul really makes a lot of sense.

So LTE networks in particular have been a trigger for this, but certainly for backhauling other 3G networks, this has come up as well.

This has pushed a few operators to use MPLS to express a desire and in some cases demand that us vendors get around to figuring out how we can make MPLS work with an IPv6 only network.

For those that aren't familiar today, MPLS today is only signalled via IPv4 in the control plane in an IP MPLS environment. So LDP and RSVP are dependent on IPv4 in the network.

So when we start looking at these much larger MPLS domains, IPv6 for MPLS becomes a real requirement.

This is starting to undergo some pretty active work with a number of vendors and in the MPLS working group in the IETF. It's certainly going to be an interesting challenge.

It presents, for the outright backhaul and routing guys, some interesting questions. Some operators today have very large IGPs, but imagine how large your IGP is when you have 100,000 loopback addresses alone.

Something that we will all be looking at how we scale that in the long term.

Looking at it from just a few other general trends.

Service offerings for IPv6 over mobile networks are out in the wild today. Miwa came to me for this session with a question of: IPv6 and LTE, is it happening or will it happen? I think it is happening. We have definitely heard today with Verizon Wireless, there is some really substantial IPv6 traffic out there today.

We see this from our operator customers that are undergoing trials. We certainly saw it from that presentation.

Definitely a requirement for the handsets to support IPv6 on the air interface. Today it is certainly limited on devices that do 2G and 3G air interfaces.

4G, as we have heard, is coming and that's in part because LTE requires it. We should see more and more device support.

Unfortunately, the shelf life for handsets today is pretty short. I have a tendency to drop mine, which results in me having to buy the new ones pretty often.

So that means that handset retirement and replacements will start to remove some of the legacy equipment that we see.

From the perspective I have been working in this domain, a lot of operators are seeing v6 as an opportunity to reduce cost as well as improve some of the service by removing NAT from the picture or at least minimising the amount of NAT.

As the networks are re-architectured, we move through generations of technology. Services will evolve to support v6. I'm particularly interested just what Samir mentioned before with IMS and v6. That's certainly something that is pretty interesting there.

That's pretty much all I have. I'm willing to take questions or take questions for the whole panel.

Dean Pemberton: All right. Great stuff. Do we have any questions from the floor, either for AJ from a vendor point of view, maybe about what he's said, or for the panel as a whole? The take-aways for me really are this is definitely possible, it's definitely happening and for me, I'd really be questioning why mobile providers, especially those starting down the LTE path, weren't doing this.

There does seem to be some pretty compelling reasons from a scalability point of view, as well as a future proofing point of view, why you would look towards IPv6.

Mobile providers are some of the best people to handle new network deployments and change. You only have to look back at the slide from Mr Li about going through 2G, 3G, 2.5G, you know, 3.9G. These guys change stuff all the time. So integrating the IPv4 to IPv6 adoption, you know, must be a little bit easier within the mobile space. But it's something that the rest of us can learn from as well.

Any more questions from the panelists or anyone from the audience?

Miwa Fujii (APNIC): Maybe this is a question for Haijun and Samir. I noticed the spectrum shortage is much stronger amongst the mobile operators, much stronger than the IP address shortage. That's my finding so far by talking to different mobile operators. What do you think about this kind of trend, their awareness level of the shortage towards spectrum and IP, do you have any observation on this point?

Samir Vaidya: No comment.

Dean Pemberton: Oh, man, that was such a good question, too.

Anyone else? Gutted. All right.

Some housekeeping, then. If everyone can go on to the Facebook page and "like" this session, that would be great.

Directly after this, we actually have some more IPv6 content. We have had quite a bit today, but after this is the Asia Pacific IPv6 Taskforce meeting. It starts at 6 o'clock, so you have a little bit of time left.

It's open to anyone interested in IPv6. You don't need to be a member or anything.

The tuk-tuks will wait for you for the event afterwards, so you won't need to miss that. But tonight we have actually got eight presentations from different people around the region and what they're doing and updating what the different countries are seeing in terms of IPv6 deployment and IPv6 adoption.

If you have an interest in v6 or you would like to ask any of those participants what they're seeing from around the region, make sure to stick around and come back at 6 o'clock and there will be that opportunity.

Sunny Chendi: I have got one housekeeping matter, very important one for tomorrow. We have elections tomorrow in the Policy SIG. The on-site voting will start at 11 o'clock and closes at 2 pm in the afternoon. You can collect your ballot papers from the voting desk just outside this ballroom from 8.30 am onwards.

You must be here to vote in the elections. When I say you must be here, you must be present in this room here, to take part in that elections.

Since there are no other parallel tracks tomorrow, I hope everyone will be attending the APOPS 3 and Policy SIG 2 and 3 sessions in this room, so that should be all right.

We also have the travel desk still open. If anyone is planning to take a trip in Cambodia over the weekend, you can approach the travel desk to make your bookings, if you wish to.

Otherwise, that was a great panel. I was actually following from the APIX room. I was doing that one and following this one here. Very good panelists and thank you so much for being here and, Dean, especially for you for moderating the session. Thank you.

Dean Pemberton: Thank you.

APPLAUSE

Dean Pemberton: I have just got a small gift of thanks for our speakers, so I would like to add my thanks and we can clap for them again.

APPLAUSE

Dean Pemberton: We're a couple of minutes early, but we did have a break scheduled now anyway and as I mentioned, the Asia Pacific IPv6 Taskforce will start in this room at 6 pm. I'll see you then.