Transcript - APNIC IPv6 Plenary

Dean Pemberton: Good morning, everybody. Welcome.

First up for the morning, welcome to the "IPv6 in Mobile Networks -- A Look Further Beyond the Horizon" panel.

I have a couple of housekeeping rules. My name is Dean Pemberton, I'll be your moderator today.

First, can everyone make sure their mobile phones are set to silent. If they go off during the show, I have to get down off the stage and answer them, and that's a bit annoying. So let's not do that.

The call for the lightning talks is open. If you have a lightning talk, a small talk that's interesting, then go to the APRICOT website and submit that. That would be awesome.

The wireless SSIDs and passwords are the same as they have been all week.

It is really important for the participants that aren't in the room, who are watching remotely, if you come to the mic and ask questions, that you start off saying what your name is and whereabouts you're from, so we can get it right on the scrolling transcript, and everyone can know where you're from.

The other important housekeeping tip I've got is the

APNIC social event tonight. Tickets are available for this. They will be available in the booth outside, from 10.30. Directly after this session, don't wait, don't go in and check your email and go back to your room, go straight out to the booth and grab your ticket. That's what you're looking for.

A lot of people thought that the marketing in their Conference bag was the actual ticket. It's not. That won't get you in past the front door. That ticket is what you're after. The little booth out there at 10.30. Cool.

What I thought we'd do, so we're going to be looking forward, and during the presentation, all the speakers here are going to be showing us a little glimpse of what's happening now, but into the future. I thought the way we might start was by looking backwards a little bit.

I want to take you back six months to Cambodia, when we had a very similar panel. It was the first panel we had on v6 in mobile, and we were just starting to see some case studies from providers that this was actually going to be happening. Before that, everyone was claiming that it was too hard, too expensive, not worth doing, kind of thing. So back in Cambodia, we had China Mobile and Verizon come along and tell us that they were

absolutely committed to this, this it wasn't something that was a pipe dream, and it was something that people should be definitely putting some effort into.

That kind of gave us a taste that this was possible. We are going to continue this theme on today.

Without further ado, what I want to do first is introduce our first speaker, Cameron Byrne from T-Mobile. Cameron is the technical staff architect at T-Mobile, where he leads IP network strategy. He has over 10 years experience in network design, deployment and supported various optical and packet based technologies. He started his career doing design and development on Sprint's Internet backbone. We are very lucky to have him here today to tell us what T-Mobile is doing with IPv6.

Cameron Byrne: Thank you. My name is Cameron Byrne, with T-Mobile USA and I'm here to talk to you about IPv6 today.

The way the deck is arranged is I'm going to present some data and draw conclusions based on the data. The data we have is pretty solid and makes the case clear that IPv4 is not strategically aligned with your business growth goals. IPv6 is required to continue growing the Internet. It is required to continue bringing more people in the Asia Pacific region on to

the Internet and it's critical for evolving the services that are available on the Internet.

With IPv4, it's a simple math that there are 4 billion or so IPv4 addresses and there are many more billions of devices that need to connect to the Internet, and that number is growing up over time.

IPv6 is achievable and it's not very expensive to do. At T-Mobile we have IPv6 in our energy and it has cost us zero dollars in capex. It's largely been an exercise in validating features and aligning road maps with our vendors, but it has not required expenditure.

We are all stakeholders in IPv6 adoption, especially in mobile networks, because pretty much everybody here is a customer of a mobile network, and some of you may be operators of mobile networks. So IPv6 on a mobile network is something we all participate in because we are all customers of it or we are all operators of it.

As I have done IPv6 at T-Mobile, one of the things we have tried to do is solve a business problem. The business problem is that we do not have enough IPv4 addresses to number our subscribers, so the only solution for this business problem is IPv6. The solution is not dual stack, as we have found. This was controversial when we first started doing deployment because everybody, since the dawn of time, including my

colleagues here on the stage, have said dual stack is the way to deploy IPv6 for a very long time. But what we found is that dual stack is just adding IPv6 to a network, but it doesn't take IPv4 away.

If the problem is that you do not have enough IPv4 addresses then dual stack does not solve your problem. You still have to give every subscriber an IPv4 address.

So we went about looking at how to do an IPv6-only network and we had some lessons learned in things that did not work in an IPv6-only environment. We will cover that in some of the slides here.

On the process of understanding what works and what does not work, we worked with some collaborators in Japan, at Japan Internet Exchange and NEC, for developing a new technology called 464XLAT. It's actually not a new technology, it's just an arrangement of an existing technology that solves our problem and enables us to deploy more fast growing edge networks with IPv6 and not IPv4.

This is a simple graph showing the number of connected devices in the world. The number of IPv4 addresses remains constant and the number of Internet users also grows. As you can see, we have already hit this point where IPv4 is not sufficient to meet the needs of the Internet and Internet users. And the

problem get worse.

Here is a chart that shows in the Asia Pacific region how mobile is growing. Obviously, so many of these countries are growing mobile subscribers so very quickly, because in many cases mobile is the best way to bring Internet to the folks in these regions. It is the new Internet. This is what many people will know the Internet to be. Our kids will know the Internet to be on tablets and phones and mobile device, they will not know it as PCs or mainframes or whatever you may have been introduced on the Internet with.

Also surprisingly, I didn't circle the ones on the right side, but Taiwan is showing 80 per cent year over year smartphone growth, which is really amazing; a very brisk pace of growth in the Asia Pacific region. These are smartphone numbers, and the numbers mean that they are IP addresses.

Since we are in Singapore, I chose to pick on SingTel. They have, according to their website, 416 million mobile subscribers. Wow! When I registered my phone with a SingTel SIM in Singapore I got a 10 dot address, so I know that they are not giving all their subscribers 10 dot addresses because there are only 16 million of those, and they are claiming to have almost half a billion subscribers. So it's very clear

to see that the number of subscribers exceeds the number of addresses available.

It's not just the pure number of addresses, it's that the handsets are using the addresses for a longer period of time. They are always staying connected, they are always updating Facebook, downloading Gmail, talking to iCloud, Twitter. Many sessions are constantly updating and refreshing and staying connected to the network. So the handsets are getting the IP addresses and holding them for a very long time and they are running many simultaneous connections.

One of the other evolutions of mobile that is happening, which causes a lot of concern in the IP address arena, is voice over LTE, which requires its own separate IP address, because it's its own APN. You can look at anything that is voice over LTE as requiring twice as many IP addresses. If you do not have enough IPv4 addresses today, you will have twice as much not enough IPv4 addresses in the future.

With that data we can come to a conclusion that IPv4 does not fit the business needs today. You cannot grow with IPv4, so that leaves you with the question: can I replace IPv4 with IPv6?

That's one of the things that we set out to discover about three years ago when T-Mobile started its IPv6

project.

Today, where is IPv6? Well, earlier, last year we had the World IPv6 Launch, where Google, Facebook, Yahoo! and several other large content providers turned on IPv6 for their websites.

In my network, those providers make up 50 per cent of the bandwidth or more. So for a subscriber that has IPv6, 50 per cent of their traffic is delivered end-to-end to IPv6. 100 per cent of my content today is NATed. So if 50 per cent goes IPv6 end-to-end, that means I have a 50 per cent decrease on my NAT. It's not a huge savings in money but it's meaningful.

This is another look at the data. This is a qualitative graph of what it looks like, so this is a general idea. Here are some quantitative numbers that are available on the World IPv6 Launch website. You can see that they are publishing numbers of IPv6 content networks on IPv6 enabled networks. They are seeing 60 per cent or more of the traffic is IPv6.

This number is a little hard to get around, there are some caveats on how it's delivered, but I like this graph, which we got from Virginia Tech, a university in the United States. They gave us this graph and it shows in yellow the IPv4 traffic on their network and the IPv6 traffic on their campus network. You can see that a

good solid 20 per cent of the ISP bandwidth is IPv6 end-to-end. This is from maybe six months ago. So you can see real numbers from real routers on a real dual stack university network, the dorms -- and this is regular users, this is not special research, this is essentially an enterprise environment or a broadband variability -- 20 per cent of the traffic is end-to-end IPv6, which is really meaningful and really great.

It shows that for the people that go and say, "There's no content on IPv6" or "If I do IPv6 I'm the only one," it's not true at all. We have real quantitative data that when you turn on IPv6 you will have IPv6 traffic and that IPv6 traffic will be sourcing the most important content for your users, including Facebook, Google, Yahoo! and so on.

Conclusion number 2 -- we presented the data, and conclusion number 2 is that IPv6 does work today. It's deployed on a large mobile network, Verizon Wireless. Their LTE network in the United States has billions of active default on IPv6 subscribers. T-Mobile USA, where I work, has been doing IPv6 for about three years, as open beta. Within the last year, we have had it so that all subscribers can turn it on, and within the next few months we will have devices that launch as default on IPv6.

It has been a successful strategy for us so far in the ability to get users engaged with IPv6 by creating a beta, so people who know what IPv6 is will turn it on and use it and give you feedback. That feedback will help you make the product better, learn some lessons, so that when you turn it on for somebody who does not know what IPv4 is, they won't know the difference that it is IPv6, which is the goal.

This is not something that customers are going to ask for, it's not a feature. This is infrastructure stuff. This is stuff that we need to do as the plumbers of the Internet, we need to build the strong Internet based on a scalable technology, which is IPv6.

We have come to the conclusion that IPv6 is great, what do we do now? It comes down to the strategy. You have to have a business strategy and you have to have a technology strategy.

One of my favourite ways to categorize strategy is if you watch little kids playing soccer, they're all chasing the ball, they do not have a strategy. They are just all chasing the ball. This is how sometimes I think we all feel in our jobs, that we are just putting out fires, just chasing the soccer ball, everybody else around us is chasing the soccer ball, and it's just not effective.

But professional soccer players don't go where the ball currently is, they go where the ball is going, so they have a strategy and they work together.

The way we do our strategy at T-Mobile is we define the end state that we want and then we work back from there. We find that if we try to make iterative movements from where we are currently, we don't actually get to the end state. We take one step in front of us and it turns out we went left a little bit, and we take another step and went left a little bit more, and we didn't really get to our goal because we are just building on the existing situation.

For us, it is more effective to define the end state, then take a step back from the end state. For us, the end state is end-to-end IPv6. Then when we imagine a world where there is end-to-end IPv6, we take one step back. That means most traffic is IPv6 but there is some left over, which is still IPv4, so that is solved with NAT64/DNS64 technology; and then we take one step back, and that is where we are today, with NAT44 predominantly in our network.

But we discovered there were some problems with NAT64 alone. Most things with IPv6-only and NAT64 work fine. I have used IPv6-only and NAT64 for three years, entirely exclusively -- my business account, my email

account, personal account, everything I do is IPv6-only. It's what they call dog food: you have to eat your own dog food or sleep in your own bed or eat your own cake or whatever you want to say. So I understand what the limitations are because I do it every day.

We discovered that some things don't work. IPv4 literals don't work, meaning that if you have an iPv6-only Internet connection, you cannot connect to an IPv4 address. If somebody has a web page that links to a IPv4 address, it will not work.

We also discovered that Skype's entire infrastructure and protocol and code base is based around IPv4 addresses. So when you load a buddy list in Skype it essentially loads a series of IPv4 addresses, and when it does that on an IPv6-only system it will not work at all. Skype have not officially said that they will never support IPv6 but they have been not very cooperative with trying to support it.

We found that it's easier to change the host than it is to change the application. As a network operator, we have some feedback into the host model and how the hosts are delivered to our network, but the applications are out of our control.

Once again, I will pick on SingTel because we are in Singapore. And they are a platinum sponsor of this

event, so they are big guys, they can take it. I bought a SingTel SIM, so I'm a SingTel customer while I'm in Singapore. I put the SIM in my phone and it populated some configurations, and one of the configurations was an IPv4 address. When you configure an IPv4 address in an application or a device, there is no chance IPv6 will ever be used, because you have hard coded and IPv4 address. This is a bad practice and it is documented in RFC1958 that you should not hard code IPv4 addresses, you should use FQDNs.

This is an example on a daily basis where you will find problems with the ability to deploy IPv6.

For that problem we have cooperated with NEC and Japan Internet Exchange to create a solution in the IETF, called 464XLAT, and this solution allows the problematic configurations, like we saw with SingTel or the situation with Skype, to be solved by presenting a fake IPv4 stack to the host, translating IPv4 to IPv6 on the IPv6 network, and then using NAT64 to translate back. It's not going to win any beauty contest, it's not a beautiful technology, but the fact is that it works and that it is easy and it's deployed.

Conclusion number 3: 464XLAT allows full functionality on IPv6-only networks. What this means is we can now deploy IPv6 to our customers by default

without any compromise to their service. This is very important because it allows us to not be tied to IPv4; we can now grow our network based on IPv6. As you know, IPv6 is a very vast space and we will no longer be hindered in our ability to grow the network and engineer the network based on IP addresses, so this is a good thing.

Finally, deploying IPv6 is easy. People will tell you it's hard and there are a lot of complicated things in it, but, as a network operator, a very few set of people were able to make a big change. If you talk to Google, Facebook, Comcast or any other big players in IPv6, they will tell you it's really a small group of people are usually committed to IPv6 and they make a big change.

When you go back to your organizations and think about how to deploy IPv6, you should take that into consideration; that other success stories of IPv6 are based on a small group of people working hard to get this done. It should not take an enterprise-wide mandate. You may need project managers to get things done, make changes in the network and things like this, but at the end of the day you, the people in this room, need to take ownership of driving the change.

The big picture here is the Internet's largest

growth engine right now is mobile and we can't tie mobile to IPv4. That hurts the Internet. Mobile is the new face of the Internet. Mobile is the Internet, is the easiest way to say it. To keep growing the network we need to have IPv6.

Dean Pemberton: Thank you. Any questions for Cameron? That was awesome.

None from the floor. I have a couple of questions.

You are saying that one of the really important things here is applications like Skype are a bit problematic, and people aren't going to stop using them, so you have to do something here. You guys have chosen to use 464XLAT, which a lot of people have historically thought of as just a transition technology. Are you guys seeing this as more of an end state?

Cameron Byrne: We are seeing it as an end state. Today, the vast majority -- as I said, over 50 per cent of the traffic today will go IPv6 end-to-end. For a customer of ours that has IPv6, 50 per cent will be end-to-end, so 50 per cent requires no special handling.

Going up to 90 per cent, there's just NAT64/DNS64, so it's just a matter of NAT64/DNS64 doing its thing of creating the AAAA records dynamically and doing the NAT64 translation of v6 to v4.

But there's that last 10 per cent. The last

10 per cent is where 464XLAT adds value. It adds value for the case of Skype. Really, I see 464XLAT as not an end state of the Internet, but I anticipate it will be around for at least 10 years, because it adds very little overhead, because it's only triggered when it's needed. So it only does the translation when there are IPv4 packets originated on the system, because the application requires it to be that way, for example, an IPv4 literal.

So there's always going to be some application. There is probably somebody right now writing a web page with an IPv4 address in it. So I believe these bad practices will continue for some time and, while people are doing that, this will be a catch-all solution.

Dean Pemberton: Anyone from the audience want to ask a question?

Gihan Dias (University of Moratuwa): What exactly is the role you currently have for 464XLAT? Because what I understood was that you are giving everybody a v6 and a v4 address, and this is for guys who really cannot manage without a v4 address. Is that what you are trying to do; for example, a legacy piece of equipment which cannot support v6 at all?

Cameron Byrne: Our deployment model is that we deploy IPv6 for new handsets. As we offer a new handset we

will deploy it with IPv6 and we will enable legacy applications through 464XLAT. We are not going to bring IPv6 to legacy systems.

IPv6 is part of how we grow, so as we grow our business, as we grow our subscribers, as we offer new handsets, the handsets will be on IPv6, and those new handsets with IPv6 will facilitate legacy IPv4 applications with 464XLAT.

Gihan Dias (University of Moratuwa): Particularly you will continue NAT46 for legacy devices?

Cameron Byrne: Yes. I usually think about the case of just a mobile handset. But here we have the 464XLAT SSID, where NEC has a working CPE where you can put a Windows 95 system that is only IPv4 and it will go across the network. If you have a CPE that acts as the CLAT in our scenario, it will do the 46 for you, so you can put a legacy system behind it.

Gihan Dias (University of Moratuwa): (Question inaudible.)

Cameron Byrne: T-Mobile, our focus, we will have routers that will do this for legacy systems, but our focus is that we will bring it to new systems.

Izumi Okutani (JPNIC): I am wondering if you have had any technical difficulties in terms of your infrastructure or providing the handsets in order to provide the same

level of service as in IPv4? You have mentioned about Skype; and was there anything else that you found it difficult?

Cameron Byrne: No. We did a study with NAT64/DNS64 only and found that about 15 per cent of applications did not work with just NAT64. But we found that when we added the 464XLAT component we were able to get 100 per cent. We selected the top 400 applications in the Android market and tested them. There are millions of applications; does it work, doesn't it work? Okay.

Izumi Okutani (JPNIC): That's great to hear. Thanks.

Dean Pemberton: One final question that I want to pick up from a comment you made earlier is that this didn't actually cost you anything, that it cost zero dollars. Was that because you had done a lot of preplanning and this was a direction that you were going down anyway, or it really is just zero dollars, and people should be doing it?

Cameron Byrne: When we decided we needed to do IPv6, the first thing we did was a gap analysis. We decided where we needed to go, where we were today, and understand what the gap is between where we want to be and where we are. Based on that, we were able to identify the components in the network that were not sufficient, and found that the vast majority of infrastructure

components had IPv6 features available. As Jouni will explain in his talk, IPv6 has been around in the 3GPP gear since 2005, so it is very mature.

There were some gaps, and the way we filled the gaps is by creating a road map, with the vendors and having some alignment. We tell them where we need to go. It's not going to happen overnight but if you create a road map and revisit that road map every couple of months -- where are you on delivering this feature; we're going to do this upgrade and we need this feature as part of this upgrade -- you eventually get there.

When you look at it, you may see that you have 80 per cent working today, 10 per cent will work in six months and another 5 per cent will work six months after that, and you eventually get 100 per cent coverage.

Dean Pemberton: Thank you. Miwa.

Miwa Fujii (APNIC): A question from a remote participant, Sunny Yeung from Telstra, in Australia, a question to Cameron: how many devices have 464XLAT now? Have you been able to get device manufacturers to install the daemon into phones directly?

Dean Pemberton: I might add to the end of that: can you answer that question but also tell us a little bit more about the handsets support that you are finding?

Cameron Byrne: NEC today, they have the demonstration

here today, so they have a product for CPE, for fixed broadband network that works with 464XLAT today and they are demonstrating it here.

For mobile handsets, we have worked with Google and Android to get the feature added to Android. We expect that feature to be released from Android soon. I believe Daniel will have some more to tell us; he's from Samsung, so he can give us more detailed information about the device manufacturer's perspective.

Regarding the general situation, we are seeing very good support. Specifically, we have Samsung here. They probably would not come if they didn't have strong support, but they have very strong support so they are here to show us how good they are doing, and they are doing very good. They have been a very good partner for T-Mobile in the handset area for IPv6. They are really our baseline that we use for measuring other handset manufacturers.

Strong support in Android; we have seen support in iPhone. T-Mobile does not have iPhone but we have seen support on Verizon's IPv6 LTE network, their support. Very high volume phones from Samsung support it, high volume from Apple support it.

Miwa Fujii (APNIC): Another question from a remote participant, Erik Kline, for Cameron: how about Apple

idevices, have you tested them on your IPv6-only network?

Cameron Byrne: No, I have not.

Dean Pemberton: Thank you for sharing that, Cameron.

APPLAUSE

Not all of us may be heavily familiar with the 3GPP standards, so let's learn a little bit more about them and how v6 fits into there.

Our next speaker is Jouni Korhonen from Renasas Mobile. He is a distinguished engineer and in the past years he has focused predominantly on IPv6 mobile issues and cellular networks. His interests include the Internet at large, IPv6 and 3GPP system architecture and its evolution across mobiles and, recently, mobile applications security issues.

Jouni Korhonen: First of all, I apologize that my slides look like a 3GPP specification, full of details with a small font. It's kind of a habit when you work in this area.

Today I want to go back into history and point out something about 3GPP and how IPv6 fits into that technology. We look into some of the basic concepts of the 3GPP end users of the IPv6 service, to point out there's a lot of details, that people who are not familiar with the cellular technology, usually those

things have kind of left people thinking, why they are there and why was it done like that? Because a lot of things don't seem to make sense at first sight.

Then we will look at what actually are the kinds of first drafts that you will need when you enable IPv6 in your core network for the end user IPv6?

The intention is not trying to scare people. At the end, it's quite easy to turn it on and have a running network. There's just a few things, because people tend to have old hardware and stuff like that on their network, there are certain things that when you are turning it on, there are kinds of things that you should know in advance, to avoid some kind of banging your head against the wall.

A few words about the transition; there will be more later on in the task force for transition.

Some steps how to actually go forward, when you want to enable IPv6 end user service on your network.

As I said, IPv6 has been there in 3GPP for a long time. For example, back in the time when I was working with a mobile carrier, we enabled IPv6 on a nationwide network in 2005, and already back then we had commercial phones that supported IPv6. So it really has been around for a long time, people just haven't been using it; there hasn't been a driver. In 2005 it was just a

fun experiment. But, as Cameron said, nowadays we really do have incentives for starting to use it.

The IPv6 connectivity, like all IP connectivity in 3GPP, is modelled after PPP. It's sold in many places, so all the connections are made to look like a pipe and so on.

At the beginning, when an IP entered in GPRS architecture, the IP service wasn't the main service; voice was the main thing, and text messaging and so on. So a lot of features of the IP have been pushed back, and we are still suffering from those. But it's not a bad thing actually today any more.

3GPP still promotes dual stack as the main transition mechanism for IPv6. It has a lot of kind of political pressure in the background and so on, and that standing hasn't really changed, but it doesn't mean that all the deployments have to be designed based on the fact that I'm going to enable dual stack. As Cameron pointed out, they have had very good success on enabling the IPv6-only service in their network.

Some basic concepts: in 3GPP we always talk about the PDN connections. PDNs are the networks that you connect from your mobile. That can be a walled garden, that can be a corporate intranet, that can be Internet.

The networks that you are going to connect to, they

are always named by the access points named APNs, and one example is like an Internet APN that will lead you to the Internet, like renasas.com would lead you to our walled Internet and so on. The access port name actually names a gateway that leads to the external network.

There are a lot of names for the actual connection, but it is usually many times called PDP context or bearer, EPS bearer, default bearer, PDN connection; they pretty much mean all the same thing. It's the connection that gives you the IP address and the IP connection.

Nowadays, when we talk about LTE and so on, PDN connection is a good kind of generalization. But be aware, when you are surrounded by 3GPP people, some of them can be very picky about the naming.

The connections are actually aware about the IP type they are carrying. One connection can carry IPv4 address traffic or IPv6 traffic or dual stack traffic, so IPv4 and IPv6. But you cannot really mix those. If your network, if you open IPv6 PDN connection, you cannot put IPv4 traffic there. So if you want to have the dual stack with this, one IP version connections, you need to open a multiple of those; or, if your network supports, then you open the dual stack

connection.

Something about the address configuration: from the IPv6 point of view, 3GPP architecture only cares about the prefix, it doesn't really care about the old address. For example, when a mobile is given an IPv6 prefix, it can do pretty much anything with it. The system doesn't track your address and so on, so it gives you freedom.

SLAAC is still the only mechanism to configure the end host IPv6 address. Sadly, there is no DHCP in reality in 3GPP networks, at least from the address configuration point of view, when you want to configure addresses to the end host.

There is a prefix delegation in future releases but those addresses are meant for the downstream interface devices, not the actual end host.

One last concept about the 3GPP is that it separates the user plane, control plane and signalling, and each of those can have their own kind of evolution and transition basis. You can run IPv6 on your user plane, but your control plane and transport plane are still in IPv4. Inside the control plane, 3GPP architecture has always been IPv6 aware about their information elements level, so you can see the IPv6 knowledge inside an IPv4 control plane.

Still that doesn't mean that the vendor has implemented the required code that would actually understand the information element that carries IPv6. This has been seen many times in the Internet.

The 3GPP system kind of evolves in the releases. We talk about release 7, release 8, pre-release 9 and so on. Every time you bring a new feature in the network, it usually comes with a new release, then the vendors have to care about the backwards compatibility with earlier releases, and think about all this kind of mumbo-jumbo and that stuff.

Sometimes there is a nasty kind of functional discrepancy between releases. One good example is for LTE release 8 you have dual stack but at the same time for 3G you don't; on 3G you get dual stack only on release 9. So when you go and buy from your vendor equipment you need to, for example, be very careful about these releases, what release software you are asking for.

Now we are hitting some of the things that are kind of good to know.

Some of these things might look disparate, but we have seen these in live networks and, having been on the vendor side, I also know that several vendors have software that have nasty features there. Still it

doesn't mean that you are able to deploy the service; you just need to know how to go around some of these limitations or not supported features.

Basic stuff: when you enable IPv6 on your user plane, it's amazing how often it hits people that it actually has an MTU impact. When you have been finetuning your network for a certain MTU size, you suddenly start seeing a lot of fragmentation and stuff like that. It should be the very basis of the networking, but still surprisingly often you hit this, and people go like, "We need to redesign our network."

Operators have a management system that might have been finetuned for IPv4. This has been a problem for certain operators, for example, how to provision their customers and the HLRs and so on with IPv6 knowledge, because that provisioning system might have been done 20 years ago and it is quite hard to go and change that.

For IPv6, for dual stack, the end devices need to know the new PDN type, so that the software can ask for IPv6 connectivity. Even if your modem supports that, you also need to make sure the middleware, applications and all these things are in sync and understand these new IPv6 features.

There are several fallback scenarios, like a device asking for something that the network cannot support,

and for those you need to have some kind of logic inside your device that you know what to do. For example, when you ask for a dual stack connectivity and the network says, "I cannot give you dual stack," but you can establish, for example, two bearers. So you need to implement this kind of logic inside your device.

3GPP has also defined header compression for IP traffic. Whether that is used is another issue, but your header compression code in the network has to actually understand IPv6 traffic. I have witnessed some networks where when you turn on IPv6 the RNC goes down because it didn't actually have the code path for IPv6 in the header compression.

The best way to avoid that is not to use the header compression, because I really personally don't find any reason to use that any more.

Subscriber management: you need to provision maybe new types of AP and at least you need to update your type of PDN that is subscribed for the subscribers. That might be an easy thing to script or it might be a hard thing to do, depending on what kind of business models and what types of packet systems there are.

SGSNs and MMEs need to know the new PDN types, so that you are able to establish your connections from device to network. In case you don't have all the

features for the dual stack, for example, you need to define the fallback mechanisms in your network. The same goes for the GGSN and PDN gateways; you need to define the subscripts and profiles; what type of IPv6 connectivity is supported, the DNS configuration and so on. This is usually just a configuration thing, but it shows that it is spreading to many places.

One basic thing that needs to be usually done is just go and verify that all the signalling interfaces actually support IPv6 information elements. It's quite annoying, for example, when you have connected your PCC element, to realize that basically from the release point of view it should support all the new features, but the code just doesn't have the support for IPv6 basic prefixes, for example. Then it's like next to useless from an IPv6 point of view.

Charging information might have a situation that you are not able to create a charging record for dual stack cases. Well, you can avoid that by turning off charging, that's one approach.

Basically, there are a lot of small things that you need to care about. But it falls down -- the thing that Cameron was saying, that you create your road map and you just check one by one what you need to do, and then you go and check whether your equipment supports it. If

it doesn't, what is the kind of workaround? Do I need to upgrade some of the elements, do I need to bring the software up to the next release? And so on. There is no rocket science; it is a lot of testing.

One thing that is visible from the 3GPP specification and architecture point of view is that the transition is made complex. It could have been laid out more simple. But it is like when you put too many engineers in the same room and don't let them out, they come up with something that doesn't usually look that pretty.

This is what basically happened with the transition. It's not that hard, it just makes people confused. It all goes around the fact that you have these IP aware PDN connections, and when you are asking something that the network doesn't support, then what is supposed to happen? The problem concretes around this dual stack bearer. If you are fine with single IPv6-only bearers then you do not need to pay as much attention on this transition, the things that 3GPP has defined and called them the fallback things.

I have one example, which is a very much used table, showing that there is a lot of combinations, basically saying that something that the device is asking, so the modem is asking what has been put in your subscription

profile, that is in your HLR. Then you have a network flag in your SGSN or MME, saying whether the network is able to support native dual stack connections or not, because in certain handover cases, even if some of your equipment supports dual stack, you might want to say to the device that because you are allowed to hand over to a legacy network, please don't open these dual stack connections; rather, open a single connection or two connections to make a dual stack.

Then actually we ask something, something happens in between, and then the network asks something, so SGSN or serving gateways are asking further Internet, and this is the GGSN and PDN gateway, what has been configured in your profile. Finally, what is the kind of connectivity you are going to get.

It might be a fun exercise to play around with these things. You can simplify those a lot if you just make a hard decision about what kind of scenarios you want to support.

One of the kind of nasty things that we found out is you have been subscribing to dual stack in your subscription system, saying you can ask for IPv4 only, IPv6 or dual stack, that would be okay. Your device supports IPv6. Actually, the SGSN that you have also supports IPv6 only, but it doesn't understand the dual

stack. So what happens is that when you download the profile, based on the rules in 3GPP, it interprets the dual stack subscription as an IPv4, and then you have a mismatch. You are asking for IPv6, but because of the internal behaviour, dual stack is treated as an IPv4, so the network just rejects your connectivity, even if you have an IPv6 capable SGSN.

These are kind of traps that you learn when you test.

That sounded bad, but it is not actually that hard. It is not. The sky will not fall.

As I said, 2005, the year wasn't that great, and even at that time we were able to get IPv6 service up and running. We had a lot of fun playing around.

Nothing will actually progress if you don't start experimenting. People need to find out what are the kinds of pain points. Then when you get up in public it's not kind of useful to try to find all the pain points with the real customers, you need to do that in advance.

I would say that every credible modem platform today, like my employer, they have IPv6 and dual stack support in their modems. Ours had from the beginning. So that's no excuse saying there won't be devices that won't have IPv6.

A lot of the modems and phones do have IPv6 capability already inside those. Whether it's allowed by the software is another thing. But I know folks like Samsung, they are allowing it, and people can actually start experimenting. It's usually buried somewhere deep there, and it needs people to understand for the subscribers to enable IPv6 with this kind of set from the end user's point of view.

There is no excuse of lack of content. We know that all the Google and Facebook are all in IPv6. As usual, there's going to be some hiccups with the Internet and so on, but you find those out when you actually start trying.

As we know, some of the existing applications, popular applications, they may cause some grey hair. You can use baseball bat, but sometimes that even doesn't work and then you need to do something else. We have heard already what that something else can be.

What to do then? This actually sounds quite similar to what Cameron was saying: you need to figure out where you want to be and then you sort the steps in between, the future thing and where you are today, and then you start making the plan of what is to be done with the network, what is the upgrade model, what is the transition mechanism, who I need to partner with for the

modems and devices, the other equipment vendors and so on.

It falls back to making a good strategy and not trying to solve everything at the same time. Piece by piece, start with people who actually want to play with this stuff, select a set of services, and don't try to roll out the whole network at the same time. If you have the luxury of doing it in small segments, do it.

Some of the troublemaker features can't be left off, like charging. If it doesn't work, don't charge for it. If it is a small voluntary group, they don't care about it; you are not going to lose much money for certain data users.

I have some examples that I'm not going to go into here because I'm running out of time. But for certain operators we made this kind of plan, how to provision things that you basically can support in one type of connectivity that you want, whether it's IPv6-only, a dual stack with two bearers or a dual stack with a native bearer and so on. It's quite doable, and you can put it in a few boxes, basically how you will do the provisioning.

Just as a conclusion, you can read this out. I am just pointing out, I want to encourage people to start experimenting. It's very likely that your equipment you

already have supports everything that you need, and also that if something doesn't fit in your model that you looked at through 3GPP glasses, then forget about that stuff. It's no use waiting for 3GPP blessing for all possible things. For example, what Cameron has done in their network is a good example. There's no blessing for XLAT in 3GPP specifications, it's not going to be shipped in the GGSN and so on, but they can do it. It's just an IP overlay. You always need to remember that, whatever you are doing, you are playing with IP, and IP you can do a lot of things as an overlay that you want.

Also one thing that cuts down the possible branches: don't try to solve everything. It's no use to try to kind of bring along all the legacies. One good example that Cameron had is that you enable IPv6 for new devices, don't care about the old stuff.

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

Michael Biber (APIPv6TF): Thank you for both those presentations, they were excellent. It highlights to me the religion between the new world and the old world, the do everything and conservative approach of doing it piecemeal. There are some issues there and we could spend some time developing all that.

I wanted to ask especially the question in dual

stack approach about the lack of IPv4 addresses that may be available to roll out the network. In the 3GPP approach in dual stack, is there still an issue? Where do you get the IPv4 addresses? Can you scale the sorts of numbers that you need to, given Cameron's example of SingTel's 416 million users? Is the lack of IPv4 addresses still a problem in the approach that you are suggesting?

Jouni Korhonen: Yes. The lack of IPv4 addresses is a problem. It is going to be a problem for new devices, new services that want to have IP connectivity all the time. Dual stack is not going to solve that at all. It just makes it worse, in a sense, if you want to keep up your IPv4 connectivity at the same level that you have IPv6.

Michael Biber (APIPv6TF): Essentially, do you get around that by being heroic and going for IPv6 as the base default position?

Jouni Korhonen: It is certainly doable, going for IPv6-only, but you still need to please the old legacy somehow. As from the experience that Cameron had, when you enable IPv6 you actually start pulling out a lot of traffic away from IPv4, and that kind of makes your keeping extending IPv4 life much easier, because you don't need to expand your NAT44 clusters to meet all

your traffic needs any more.

That is something that we actually said to a lot of customers back then, that when you go and enable IPv6 and dual stack, so you still have the problem with the NAT-ing, but over time the traffic will move away from the IPv4 and you have less problem with scaling stuff.

That works fine for certain customers because, unlike Cameron and T-Mobile, not all the operators are willing to put any kind of new translation boxes in their network. Certain operators don't want to have NAT64 or PLAT or anything in their networks, and they don't want to have any new software. For those who are dual stack, NAT-ing and hoping the traffic will move over to IPv6 is one approach.

Dean Pemberton: We will move on to our third presenter, who is Daniel Park from Samsung Electronics.

The readiness of handsets is going to be quite a critical matter in the large scale deployment of IPv6. So it is great to have Daniel here today to speak about that. He is working in the software R&D centre at Samsung Electronics and also chairing the Media Annotation Working Group at W3C. His research interests are in IPv6, mobile computing, web applications, meta-data and convergence services.

Soohong Daniel Park: Good morning. I am Daniel from

Samsung, Korea.

Basically, my material and my presentation is very simple, because I am just focusing on devices and perspective in terms of IPv6, and I don't care about infrastructure, like 3GPP, like the two guys that were talking about that issue.

I am just saying what sort of IPv6 functions are available in Samsung products. Also, I do not cover other smart devices, such as smart TV or smart electronics developed by Samsung; today mainly focusing on smart phones, especially the Galaxy products.

The Internet is everywhere, and IPv6 is a good candidate for that big trend. We have a lot of projects in Samsung R&D, especially IPv6 small chips to be embedded in Samsung products, to make smarter home networking and so on.

Also, there are big contents acquisition evolution from the product devices, from the product perspective. Through Internet and web connectivity, almost all the Samsung products can obtain content from the Internet and from the web directly. We don't need any storage devices and stored material to use content.

I believe IPv6 can be core as part of the IPv6 Smart World in Samsung products, so that is the main reason for IPv6 research in Samsung R&D. However, practically,

even if there are a lot of in-house projects within Samsung, we did IPv6 based home networking and even mobile IPv6 and DP based on IPv6 protocols.

Those solutions are still research stages, and interestingly the smart phones is at the front of the IPv6 commercialization, talking about the Android status.

We have IPv6 support in our smartphone. Our Galaxy products provide three Internet operating configurations, such as IPv4 only, IPv4/v6 dual stack and even IPv6-only protocol in our Galaxy products. Working with AT&T, Verizon, T-Mobile and these kinds of telecom providers, we do support native discovery protocol between Samsung products and telecommunications networks, and also these products can be used for tethering solutions to connect to other devices, such as laptop or tabs.

In that sense we have two connection modes. The first is USB tethering, by using IPv6 stateless address auto-configuration; and the second one, WiFi is also available for that connectivity. In that case, we need a DHCP v6 support, but however it's not available yet, and it is still under development in our lab.

One of the issues in terms of IPv6, to me, and I think we are still focusing on IPv6, a small part of

IPv6, such as peer-to-peer connections and auto-configuration, even if iPv6 has a bunch of address spaces, but I think we are still missing part of this area, the application of IPv6.

I think there are a lot of advantages from IPv6, in terms of applications and services, however I do not see any IPv6 spaces, applications, and so on. So we have to be focusing on that issue from now on, because IPv6 is already done in our products.

The biggest requirement from telecommunications providers is voice over LTE using IPv6 address; one good example from IPv6 deployment.

Several issues I have from the product division, such as only IPv6 responds with IPv4 address sometimes; or either IP configuration for IPv4/v6, not either one; and sometimes different IPv6 address strategy on access point names; and there is no IP layer response during PDN connection in the mobile networks. So those kinds of issues must be resolved as soon as possible, for success of IPv6 deployment in the world.

I can say we are working on a good solution. T-Mobile mentioned before 464XLAT translation solution is good for IPv6 deployment in the world. So we are working on that, and it is going to be available in the next Galaxy products. I think they will be released

around April or May this year. Then we can officially use 464XLAT functionality by using Samsung products.

I think it is reasonable today, because IPv6 service deployment in ISP infrastructure, and also IPv4 address is not available yet in device side. So 464XLAT solution is good for IPv6 deployment currently.

The same picture from the T-Mobile presentation.

This is my last slide. I think, to me, and to Samsung, there are few implications and limitations on the device itself, because we are ready for IPv6, and also 464XLAT functionality is going to be available in the market.

Also, we are using Linux operating system for Galaxy and IPv6 is already a basic part of the Linux operating system, so we have already done. However, we have to be focusing on IPv6 basis, service and applications more and more from now on and in that sense we have to work with our service providers and application developers more tightly and more closely to make more nice IPv6 work in the near future.

Dean Pemberton: Thank you. George, a question from the remote participants.

George Michaelson (APNIC): I have a question from the chat room, from Roy. He says: dual stack deployment in access networks, especially in the RF, is probably an

issue, what about IP core networks, what are the issues of dual stack deployment in the IP core?

Cameron Byrne: From our perspective at T-Mobile, the IP core network was probably the easiest part, because this has been around for a very long time, the core routers being able to support IPv6. So that's usually the easiest part, just moving the packets.

In our particular scenario, we used the 6VPE feature of MPLS, which allowed us to deploy IPv6-only at the PE edge routers. So that was a very quick and easy deployment, it's easy for our operations team. Once again, this is another example of using the existing hardware and software we have on the network to bring IPv6 from one end of the network to the other, with no capital cost; you just have to train the folks and deploy the edge features.

Laurent Maillot (Offratel Lagoon): I have a question regarding the Samsung products, especially the tethering. I noticed that DHCP was under development, but I was wondering which kind of address you will be assigning on tethering as part of IPv6, will it be provided as part of the subnet from the mobile operator? The second question: are you going to support IPv4 on tethering from the mobile over IPv6?

Soohong Daniel Park: Yes, IPv4 is available for tethering

service. Using DHCP v6, in that sense Galaxy already has IPv6 address from the service providers, and then using DHCP v6 on other devices, such as a laptop or a tab, can get IPv6 address from the Galaxy devices. So it's the same address from the service provider.

Laurent Maillot (Offratel Lagoon): The range is provided by the service provider?

Soohong Daniel Park: Yes.

Dean Pemberton: Any more questions?

Rakesh Mohan Agarwal (Dept of Telecommunications, India): My question is to Mr Daniel from Samsung. Basically you are saying the high-end devices which is Galaxy Samsung will be able with dual stack in April or May. But in India the majority of the low-end devices are there, and I think Samsung is the number 1 device provider; the low-end devices are mostly before.

Do you have any plan where IPv6 dual stack can be used in the low-end devices? Because other device manufacturers are coming up with a plan. The Government of India already has a plan to go into IPv6 in a big way. In case Samsung does not have any plan for low-end devices, then it may be a problem for Samsung in India. Is there any plan for low-end devices on IPv6?

Soohong Daniel Park: Unfortunately, I don't have any clear answer; I'm not in the marketing and training

group.

Basically, the big requirements are coming from the US market, especially from Verizon and T-Mobile, so that is the first, and it will be probably done step by step. That's my answer. I don't have a clear answer for the Indian market plan.

Cameron Byrne: What I have found is that all the Android devices from Samsung supported, that we have seen. It's not just the very high end, it's also the lower end of the Android. I don't have very much exposure to some of the other platforms, but all the devices we get from Samsung today, high end and low end, are Android supported.

One of the important things from a service provider perspective is to make sure it's a mandatory requirement for all handsets, so when the OEM comes to do certification on the network, this is one of the tests that must be performed. If IPv6 does not work then you have to have a business conversation about "this is a requirement for my network and you must conform to the requirement." That's a conversation we have had with Samsung and it's been a very good experience in getting them to deliver the feature. Some other OEMs may be a little bit harder experience, but it's that conversation you have to have.

You have to be persistent and it has to be a requirement. It's important for your mobile networks to have IPv6, so this is an important requirement that has to be part of every device.

Michael Biber (APIPv6TF): I have a simple question. Are the addresses you are handing out globally reachable addresses or are they ULAs or local restricted addresses?

Cameron Byrne: We have only global addresses, /64 for every handset.

Dean Pemberton: Do we have any more questions from the floor or remote?

No. Awesome.

Soohong Daniel Park: I am just curious: T-Mobile and Verizon available, in terms of 464XLAT functionality and infrastructure; how about other countries, probably India and Japan?

Dean Pemberton: The question is, we have heard quite a lot today about 464XLAT and how T-Mobile is using it. Is anyone here in the audience making use of that as a transition technology? If not, are there other v6 transition technologies that you are making use of within the mobile space? Anyone want to run for the microphone?

Soohong Daniel Park: Even if we have 464XLAT

functionality in the next Galaxy product, however without infrastructure support it's meaningless. I'm curious what the requirements are from providers.

Cameron Byrne: I know a couple of operators around the globe have deployed the NAT64/DNS64, which is the fundamental infrastructure, so once you attach the capable handset, it works. I know that Swisscom in Switzerland and Orange in France have similar opt-in services for IPv6 that support the DNS64 and NAT64. So these are networks where you could bring a capable Galaxy handset that does 464XLAT and the service would work.

Dean Pemberton: That's been a really good session. What it's shown us is that this isn't just a possibility any more. This session and the previous session makes it very much an inevitability. We are seeing more and more providers not only supporting IPv6 but in some cases supporting only IPv6.

I think the message is that all the parts are coming together. We are getting support from 3GPP and we have seen that we have high volume handsets support from players like Samsung with technologies like 464XLAT.

Let me leave you with one final message. If you are a mobile provider and you are just starting to deploy a new, maybe 4G LTE network, maybe you have just announced

trials, and you are doing it without IPv6, then the message is clear: you are getting it very, very wrong. Thank you.

APPLAUSE