These are unedited transcripts and may contain errors.

Plenary Session, 3 May 2011 at 11 a.m..



CHAIR: According to my clock it's eleven o'clock, so, I'd like to get started here. Our first talk in this session is by my fellow IPv6 co?chair, Marco, who seems to be on the phone. Marco, we need you.

MARCO HOGEWONING: Good morning. I'm Marco, I am ?? as I said this morning, one of the co?chairs of the IPv6 Working Group, I also work for the RIPE NCC as a trainer, and what I am about to do is provide an overview of all the transitioning techniques that are around.

So, recap: There was this plan and for those of you who have been around for some years know that the original idea was to have IPv6 deployed before the IPv4 world would have run out. But this clearly is not the case. By now, the whole world should have been dual stack. It isn't. And by now, I wouldn't be standing here.

Although what I am going to tell in this part what I am going to tell, keep in mind IPv6 is the end goal. Exhaustion of the IPv4 free pool is a permanent problem and it needs permanent fixing. Only problem with that permanent solution is it takes time to implement, time we may not have. IANA has already run out, APNIC has run out, soon there will be others. But eventually, you should be prepared to switch off IPv4, so, wherever you can, dual stack, and make sure that you are no longer depending on IPv4.

So, transitioning techniques. Well, we, as a technical community, we're pretty active and we have various options and in fact the testify is overloaded with drafts and RFCs on all different kinds of acronyms, I mean 6 in 4, 6to4, the whole list is there and it's into the even complete. Some of them are more serious than others. Some of them are actually relive deployment, some of them are just drawing board. But there is a lot of stuff out there and the main challenge is what do we choose, which are we going to use?

And keep in mind, it's actually by now at this point in time we need to solve two problems: First of all, you need to maintain connectivity. We don't want the Internet to break and IPv4 is still widely used by basically 100% of the Internet today is IPv4. So you need to find a way to extend the life?span of IPv4 while you you deploy IPv6 so either extending the address pace with NAT, whatever it's called today, or translating between the two protocols.

The other big problem is to provide a mechanism to connect to those IPv6 networks that are emerging. Sooner or later there will be somebody to deploys and IPv6 only network because he doesn't have the choice. And what you there see is a lot of stuff focusing on tunnelling of IPv6 packets across IPv4 only networks. So what options do you have, first of all, extending the address pool, network address translation. Fairly common technique, everybody uses it for the last ten years, and in fact probably got us this far without NAT, we probably would have depleted the IPv4 pool years ago.

It breaks end?to?end connectivity model. The old timers know that. But what I notice in the past is that for newer users they are actually so used to NAT they don't recognise what they are missing. Be aware of that. So, it breaks stuff, but people don't know it breaks stuff because in the meantime, we worked around it. And the main problem is it doesn't allow you to communicate with /T*EUBGS. So no matter what you do you still have this problem of IPv6 networks which you can't talk to. But in the meantime, you probably are going to need it in one way, shape or form.

So, as far as transitioning goes, what's there in between v4 and v6? Focuses on two main solutions. It's either trance pouring XNI, tunnelling or it's translating X to I, most commonly NAT 64, as far as the techniques go, these are the four most common. There are others around but these are the ones you encounter most and which are actually implemented in real life situations.

So, 6 in 4, it's actually manually configured tunnels and it's been there as long as IPv6 has been around. This is where it all started with people running manual tunnels. These days you have a couple of virtualised programmes. 6XS, hurricane collect Rick, and they allow you build a tunnel through a fixed end point and it's very stable and it's very predictable because if you don't move and that end point doesn't move, you know what the legacy is going to be, you know who to call when it breaks. The only problem is it requires manual configuration. So, while you can deploy this to a couple of hundred, maybe thousand text server users, you can't do this operating in a mass market. You can't do 100,000 residential customers with this system. It doesn't scale and it's unmaintainable. An as soon as you start picking stuff, you start putting 6 packets into v4 shall, with that you are lowering the MTU so MTU might cause issues here.

So people try to solve that. One of the things is automatic tunnelling, 6to4 is the most well known. It can configure itself, what it basically does is it takes its IPv4 address and creates and IPv6 address from that. So, as soon as the man has IPv4, it has IPv6. Only problem with that is it requires a public IPv4 address, and well, problem is, we are out of public IPv4 addresses. Another main thing is, it started off without it and it started off to live at the network boarder, so you, as a network, could supply yourself with IPv6 without any of your neighbours doing IPv6. Later on, that system moved words to the end and is now implemented on Windows machines or CP at home users, and people add any cost to the /KWAEGS, because it provides stability and reliability, so they thought. Well, it uses any cost to reach any nearby server and problem there being is: Do you know who owns it? Does it come with an SLA, who to call when it breaks? And at the same time, because it uses Anycast in both directions your return packets might choose a complete different path. So you see huge legacies and again, if you can reach your server, it doesn't mean that the path back is also okay. And the same for 6N4, it's shipped as protocol 41, IPv4 and IPv6 and a lot of security guys don't like it. They drop it. They don't know what protocol 41 is so they decide to drop it.

People started thinking about this and working around it. And Microsoft came up with Teredo, the other big automated tunnelling system. It solved a couple of problems. It uses UDP as a transport. So it works across most NAT implementations, you no longer need a public IPv4 address because, while set it go up it's capable of figuring out what the public IPv4 is. It uses a bill of signalling to do that. And as its UDP, it's less likely to get dropped. Other big thing they solved, although it's still Anycasted, traffic will be similar metric, so at least it will run both streams across the relay server. The one it picks is the one closest. If you connect to an IPv6 basically the packet back will dictate which relay server will be used. Again it's probably not in your control, so, who do you call when it breaks? Do you know who owns it? And people are always afraid of man?in?the?middle?attacks. This is man?in?the?middle attack happening right there and people are voluntarily using it.

6RD.
Again, it's a solution to solve some problems. This was actually developed by free, who has a huge deployment, they took their solution to the IETF and standardised it. It's similar to 6to4. Main difference is it uses space assigned or allocated to the operator. Instead of using Anycast, all traffic will be directed towards ?? to its operator. That means he has full control over the relay. It also means that it allows to you run private IP space because of that relay sits in your network, you can run this with RFC 1980 space because as long as the address is unique in your network, the rest of the world doesn't matter. For them it's just an IPv6 address.

Traffic should be symmetric across a relay. Depending. You can still use Anycast but at least it sticks in your domain. Draw back: It requires patching. It needs additional software signalling, there are a couple of DHP 4 options that are used to at the time Receiver that it's allowed to use 6RD and what prefix to use. It may seem a nice solution, but you need to do something to deploy it. It's not completely automatic. So, in general, tunnelling it mostly uses your IPv4 only clients, or clients in an IPv4 only network to connect to the IPv6 world. The other way around might be difficult. With 6to4 you might be able to do it. It's not advisable. But, for instance, Teredo, you can't host content behind Teredo. That's not the way it works. It should also be initiated from the client. As I said, tunnelling, MTU issues might be a real issue. As soon as you start adding headers, stuff gets smaller. So be aware that you might see packet too big and make sure that you accept them and don't filter ICMP.

Again, it's not that one technique is that much better than the other. They all have their drawbacks. Your mail list may vary and it also depends on the rest of your network which technique you have to choose.

The other big option: Translating. NAT4 combined with DNS64. What you will have then is a single stack client, that machine will only have an IPv6 address. Somewhere in your network is a translator box, that basically takes the whole packet apart, saves the content, builds and IPv4 packet from it and sends it on to its destination. This does, however, come with some problems. If your client only has IPv6, it doesn't know what to do when it requests a DNS and only sees IPv4 coming back. So, you need to do some magic there and actually capture the request and if you see that the host doesn't have an IPv6 address, you strip out the v4 reply and replace it with a crafted address with IPv6. So the client will always get an AAAA back, so the client thinks it's communicating with an IPv6 host while in fact, it's communicating with an IPv4 host. It's a little bit of nice crafting because you put the IPv4 destination address in the IPv6 response address so you know where the send the packets to.

Also, when doing this, that translator box needs to connect to the IPv4 world and it usually only has a small pool of addresses, so, this implies address sharing, so you fall into the same situation you had with NAT, who is talking? It's no longer an individual which you are after. If somebody spams, which of the 10,000 users was it?

So, the end game, because if you deployed IPv6, you are not there. IPv4 will probably be around. Everybody adopts in its own tempo, so the fact that you got IPv6 doesn't mean that your neighbour has IPv6. So, you need to connect to an IPv4 host, and maybe all you got was that /22, because IPv4 has run out. So sooner or later, all you can get is a slash or maybe not even any addresses. So how do you do that? This is the other big thing: DS?Lite. I talked to a lot of people and a lot of people tell me they are thinking about deploying DS?Lite. Well actually DS?Lite turns it around. Its tunnelling of IPv4 packet over IPv6. That's quite nice, because everybody tells me yeah, we are going to do DS?Lite. Well not that many tell me they are going to deploy IPv6 natively and if you want to do DS?Lite you need IPv6 as the basis so first need to deploy IPv6. Then you can use this to connect to IPv4. Without doing NAT themselves. Etc. Actually a little trick so you take your private IPv4 packet in IPv6 and ship it off to a centrally located NAT inside a provider. That one uses the client's IPv6 address to maintain state, so in fact it last a duplicate IPv4 ranges. All your customers can be intense ?? they can you'll use the same address and your NAT can still keep track of it. So it saves you the hassle which you normally had a with DUM NAT where you have conflicting address space if you decide to run 10 /8. Your customer probably can't do that. Other alternatives to this, A+P, it shares addresses between complaints. What it does is restrict port ranges. So a client gets a real IPv4 address, but it's only allowed to use port 1000 to 2000, then its neighbour is allowed to use port 2000 to 3,000, that way you can run the same address and multiple clients. It requires a lot of work in the routing because you can no longer route on IP addresses you have to route on port numbers.

R4 RD is a bit similar although it uses automated mapping. Based on the IPv6 address, you create the IPv4 address of the client. As I said, other alternatives, I haven't come across real implementations. I think A+P had a small demo set up, I stand corrected if somebody is actually using this.

Now the main question of this is: Which to choose? Where do you go from here? We have so many options. We are actually internally busying with writing a paper or building a matrix that should go in a lab somewhere about this and we already had a couple of sessions, lengthy sessions, hour, hour and a half, to discuss what options we have, and in which case, which technique you use and we still haven't finished it.

Basically, there are three groups of people. If you want to divide them up. First of all, there is the group that's not in this room, there is the group that will find out next year that will run out of IPv4 addresses, they are too late. Maybe they get a /22, maybe they are so late they don't have any IPv4 at all. There is the people who still have IPv4 space and that probably means you. And those can be divided into two new groups: Either the people who have enough addresses for the next two, maybe three years, and that can happen if you are providing a saturated market, it might be that you can do until 2013 with the addresses you now have. There is also a huge group, for instance mobile, that's rapidly growing and they are pretty sure that they won't make it for the next two years with with the IPv4 space. So, focusing on them, the guys that have enough IPv4 space for the next two years, well, there might be lucky. They don't have any immediate problems. Yes, there is this IPv6 thing coming, but the fact that content operators deploy dual stack, the fact that Google switches on IPv6, doesn't mean that they switch off IPv4. So, as long as you can supply your customers with IPv4 at the moment and probably for the next two years, they are perfectly fine. They experience the Internet as it should be. So, what you should do is focus on dual stack deployment, but don't delay it any longer. You still have one, two years, but you probably make it, and as those IPv6 only networks are are emerging, you can also consider offering a tunnel server, just in case somebody wants to connect to an IPv6 only network, but as long as that content doesn't appear on IPv6 only, there is not that big of a problem.

Now, what do you do if you don't have enough addresses? Well, you have these two problems and you need to go to IPv6, and in the meantime, you don't want to break the Internet. You don't want to break your customers' experience. So you have to maintain IPv4 connectivity and one way or another, it's probably address sharing or network address translation, and the fact that you are losing your options with IPv4 might be a bigger problem. That's an immediate problem. That will break the user experience. V6 is still some way ahead. So, for now, focus on fixing your IPv4 problems, but don't cut your path to IPv6. Make sure you keep all options open.

So which technique? Well, it all depends on what your network can do. How easily can you deploy IPv6 in the end? If it's easy to deploy a native IPv6, DS?Lite becomes an option. If you are forced to run address sharing or private addressing, some techniques are no longer usable. 6to4 is out of the equation. You have to do ?? well, you don't have to do 6RD, but it's probably your best bet because it saves most problems, it runs automatically. But, maybe there is something else. You really have to look into what fits your need and what can be done with the stuff you have.

What if you only have the final /22, or maybe not address space at all you don't have any choice. You have deploy IPv6 natively. There is no other way around it. You don't have IPv4, end of story. So, NAT64 is the only thing you have left. Translating. What if you have only 1,000 addresses how many clients can you support on that? That's the main thing. In this case the key is actually not with the access providers, the key in this lies with content. The more content gets dual stacked, the more easy it will get A for those IPv6 native customers to connect to that content, and also, 80% of your traffic moves to IPv6, that remainder, that 20% that's left over might be doable at NAT64 but if you really rely full mobile network with millions of customers on NAT64, with only 1,000 addresses on the v4 side, probably ain't going to work.

Content providers: What if you are offering content? Well, again, these two groups. If you have enough IPv4 addresses left, don't bother with anything. Dual stack your network. Don't use any intermandate solutions. Tunnels, your mileage may vary, MTU issues, it's all flaky, don't go there. Dual stack. If you don't have enough IPv4 addresses left. Well, I guess your luck just went out of that door. Address sharing in content length won't get you very far. You can try it with virtual hosting, but how many v?hosts can you actually run on an IP address? You only have one port 443 to give out, when you give it to one customer, you can't give it to another. So if you have 1,000 addresses, as it currently stands that's all you will get in certificates. So you are really stuck between a rock and a hard place. Dual stack, that's about the only option you have. Otherwise hope that you will get IPv6 connectivity later and offer your content on IPv6.

So main message here is choose wisely. There are a lot of factors taken into account and you can't say what's best. It really is a custom job. Can you deploy IPv6 at the moment? If not, what does it actually take to get IPv6 out there? Do you have enough IPv4 addresses available? Can you stretch it until you are fully dual stacked or do you need NAT as well? If you start looking into 6RD or other options, do you have control with the client side, DS?Lite, A+P, it all requires patches on the client's side. Can you run software upgrades to most modems easily or do you have to rely on customers taking action themselves? What would the traffic balance be? NAT64, as I said, might be an option. But only as the majority of your traffic has moved to IPv6. So with guys like Google and other big fellow deploying dual stack, you might see a the love traffic disappearing to IPv6 so translating the remainder or NAting the remainder of the traffic might be a feasible option. As it currently stands, if you have to translate a hundred percent of your connectivity, it may not be. And whatever you do, keep in mind that these are temporary solutions and the runout is going to be a permanent problem. So, whatever you do, don't go out of your way, dual stack should be the focus.

Any questions? I see Randy coming up.

AUDIENCE SPEAKER: Randy Bush, IIJ, Marco thanks for replaying the talk from five years ago, three years ago, two years ago, one year ago with only the names of today's hacks for transition mechanisms changed.

MARCO HOGEWONING: There was still demand for this content.

RANDY BUSH: I think that demand comes from the people who hope that the idiots are going to listen and do something. I think they are going to do something when they actually hit the wall and not until then. Not until then. And what the question I think that's most critical is: When they hit the wall, they can turn right, or they can turn left. Okay. We do not want them to turn right into NAT 444. NAT 44, etc. How do we make it so that the choice is clear to them that turning left into IPv6, when they hit the wall ?? and they will not act until they hit the wall, okay ?? that turning left to IPv6 is easier and lower cost?

MARCO HOGEWONING: You tell me. I am no longer a network operator, but I do think that ??

RANDY BUSH: Well, we turned left in 1997. So, in fact, you know, we will have to, due to the wonders of NTT's layer 2 network, we will turn off IPv6 for world IPv6 day. It's really going to be world IPv6 minus Japan day.

MARCO HOGEWONING: Thanks for pointing that out. Yeah, I think my personal opinion is that the more content get dual stacked, because if people get stuck beyond multiple layers of NAT and their neighbour has IPv6 connectivity, he might be ?? share a better experience. They may not know that it's IPv6 that's causing it, but if you are stuck behind three layers of NAT and your Facebook is pretty slow and your neighbour's Facebook is doing perfectly fine, that customer might vote with his feet and go to his neighbour's operator because it works more ?? really, I do believe that the key is in the content. As soon as you have the content on dual stack, then the clients will realise that v6 is a better option than trying your luck with NAT or translation.

RANDY BUSH: When I'm sitting there with a choice of either I buy cable or I buy Telco, okay, and both of of them see it in their interest to provide a walled garden and trap the customer...

MARCO HOGEWONING: You may not have that choice, but...

AUDIENCE SPEAKER: Geoff Huston. I am feeling a bit depressed and you haven't made my mood any better. Part of the problem is that content folk look at dual stack and reach the obvious conclusion, that right now they service folk in v4 and they are happy. If they turn on dual stack, a small number of folk who were happy won't be. They either will get the spinning beach ball of death that never stops because of a path MTU black hole or they get just folk that wait for three minutes before something happens because it does it and then reverts. Not many, but a few. Why should content provider piss off people? Where is the gain? And they look at this and each time they look at that they go, wow, so I can either wait or I can go dual stack and piss off some existing happy customers and every single time, most of the content folk go: I am going to wait. And they have been saying that for three, four, five, six, seven years.

MARCO HOGEWONING: At the moment you might piss off one or two in 10,000 that have connectivity, but by not deploying it in a year's time you might piss off that 20,000 people that are behind multiple layers of net.

AUDIENCE SPEAKER: That's two years hence. I could be working for somebody else. I don't need to do anything today, do I? That's what this industry has been saying to itself collectively now for so long now it's so funny.

MARCO HOGEWONING: I am afraid you are preaching to the choir here.

AUDIENCE SPEAKER: I am saying the story is really far worse than you are making out.

MARCO HOGEWONING: Getting the story out of this room is the main objective.

AUDIENCE SPEAKER: Paul Boot, again from the Netherlands IPv6 foundation. Marco, as I talked to network operators, and they are saying a few things. Single stack, a single stack network is far cheaper than a dual stack network. They are saying I have old equipment, I have old DSL, I have old equipment. They cannot be upgraded and I am poor. What should I do? So that's for old networks, and they are saying: I want to build a new and fast network, but I only want to do one protocol, because one protocol is cheaper than two protocols. I would be a fool if I would deploy two protocols at the same time, because it all ?? multiple ?? it makes my problems not two times worse, but perhaps four times worse. Things can go wrong on multiple levels. So, what would be your advice to, one, operators that say I am not going to change anything in the old, in my old network, it will stay IPv4, what should I do and what would you say to building a new network that will be what kind of protocol and which transmission, translation mechanism would you advise?

MARCO HOGEWONING: The only response to shows who don't want to upgrade this is either wait for that lightening strike that forces to you buy new equipment; otherwise, it's making ?? closing your eyes doesn't make the problem disappear. This problem will be there in four years time. Eventually you will have to replace that box anyway. It might take you another three years but it won't last forever. As far as the other group ??

AUDIENCE SPEAKER: And deploying 6RD as a temporary measure to extend the life for two or three years?

MARCO HOGEWONING: Yeah, it might be an option, but maybe with 6RD you end up replacing the modems anyway, or at least software upgrading. As far as your comment about the stuff ?? well, dual stack becoming more expensive, and the cost is probably in IPv6 anyway because that requires you to get people trained, that requires you to buy new stuff, if you buy stuff that's v6 capable, you basically get v4 for free because there isn't any v6 only equipment on the market and by the time you have trained your guys to know and understand IPv6, you probably get IPv4 knowledge for free as well, so I don't see that as a big deal, but it's my personal opinion.

AUDIENCE SPEAKER: Okay, so solving problems, multiple management systems that do both monitoring of IPv4 and IPv6 of all your devices, all your routes, that won't make a network any more expensive you think? I mean, it's highly unlikely.

MARCO HOGEWONING: You have to incur that cost anyway. I am getting signals that we are running out of time so I would like to ?? I have got Gert Doering there standing and I think... this gentleman in the back, yes.

AUDIENCE SPEAKER: I have a question from Jabber from Tore Anderson from Red Pill Linpro, he says: "Marco, you said that if you are in a situation where you are only have the final /22, the only option available is NAT64, DNS64. I don't understand however why DS?Lite is also an option for operators in that category. As far as I can tell, both NAT64 and DS?Lite will only require IPv4 addresses to number the outside the interface of the translator system and the number of public IPv4 addresses required should be roughly the same for both alternatives."

MARCO HOGEWONING: If you can deploy native IPv6, DS?Lite would be an option, yes, he is correct there.

AUDIENCE SPEAKER: I have a couple of notes. I missed the beginning of the talks so maybe you mentioned it, but there is an alternative in some cases to all that NAT64 and whatever stuff which is application of a proxies. That can be useful in certain environments where you have customers that basically use, well the Internet meets HD PS. The second thing is, we should expect the IPv4 address space to get depleted faster than we currently think because we don't just have the normal exponential growth any more but we have people trying to get addresses because ?? before we really run out of them. We will have problems with the default Freezone, with the routing tables, for black market for IPv4 addresses, speeding up the growth of the routing tables in all likelihood. Then there is one more thing about NAT in all sorts of variants. We have, once we have to move from full cone to restricted cone NAT, some obscure protocols like STUN will blow up right in our customers faces. If an ISP believes he can get away with carrier grade NAT and not risk the sort of problem that's fairly optimistic.

One more thing: How do we make people move from IPv4 to IPv6? Money. Charge them extra for IPv4 and a lot of things will happen very quickly. And if you have the extra cost for IPv4, that may actually happen and bring the entire thing up to speed as well.

And one final thing: For an ISP host error whatever, it may be reasonable right now to wait with IPv6 deployment because there are a couple of customers that will be concerned, but that may be reasonable, in my opinion it isn't, but it definitely doesn't mean we should ignore IPv6 until its too late. If I was an ISP, at least the one thing I would do was make sure as soon as people actually demanded, I can provide it as quickly as possible because otherwise I am going to lose customers.

MARCO HOGEWONING: Tell your customer the truth I would say. You can scare them with IPv6, you can also tell them the truth that IPv4 has run out. I am really cutting this short on time so we have got Kurt and Lorenzo. Otherwise we won't make lunch on time.

AUDIENCE SPEAKER: Gert Doering, I will be brief. I have some good news for Geoff and that's not just beer. Some major content sites have measured brokenness and have decided that the brokenness level is acceptable and so big sites like Heizer.ve.vg.no and others recently have moved to offering dual stack content, and I am quite happy about this. And so should you.

AUDIENCE SPEAKER: Lorenzo. Yeah, the content, I think if we actually look at the chicken an egg. The content chicken is moving first, so ?? but more about that later. I just wanted to address an earlier point about dual stack networks. We do see an increased operational costs due to running dual stack. The infrastructure is all there. The hardware is all there. You don't get extra cost there but you have to two with two extra tickets, all this stuff right, does have a cost. We would love to be able to do v6 only. For example, in looking at a greenfield deployment like the Google home stuff. I would love to make that v6 only. The question is that it's not quite there yet. The hardware ?? the gateways don't do hardware accelerated dual stack so you can't actually dual stack light so you can't do DS?Lite, because you know if you have offering a gig it has to be hardware accelerated. So you don't have that. You don't have some little things on the NAT side, so you can't do that today. But, even in our offices, I would love to be able to do dual stack light because it, it's not just an operational cost, it's also a reliability cost. Some of the times you get weird failing scenarios where v4 is working an v6 is not working. Some of the times you only get to Google because v4 is working and v4 isn't working so that's a reliability cost as well.

MARCO HOGEWONING: Then again the net on the other side might also be acting up and causing a lot of cost in trouble shooting that.

AUDIENCE SPEAKER: Your points are valid in general. I am just saying don't dismiss the ??

MARCO HOGEWONING: I think we are stuck. Sooner or later one way or another you have to spend some money on this. The problem is do you spend it twice, first on a temporary solution and then on a permanent fix or do you aim for the permanent fix directly? With that, thank you. And I will make space for the next presenter.

(Applause)

CHAIR: Thanks Marco. There is a lot of interest. The next speaker is and Andrei Robachevsky.

ANDREI ROBACHEVSKY: Good afternoon, I work for ISOC. I may sound a bit strange but in this presentation I'll talk more about IPv4 than IPv6. And I'll probably not tell you a lot of things that you don't know and it may sound like a play off of other presentations, but, well, at the end of the day, we'll be talking about IPv6 transition and coexistence for quite a while but I just wanted to make like a summary presentation this these ten slides and look at the strategy for IPv4 and IPv6 coexistence.

So, let's start with the need. And when we talk about IP addresss in this particular context, we actually talk about connections because we need them to uniquely identify connections. So that connection is what matters in fact. Unfortunately for a connection, IPs have to be from the same family. If you want to connect to somewhere on IPv6 network, you need to have an IPv4 address.

So, if you look at the need for a particular ISP it depends on the ratio for IPv4 only Internet and the global Internet but also add the growth of this ISP. If ISP doesn't grow it doesn't need new addresses, right. And of course the definition of the Internet is different for different providers in different regions.

Unless you have huge reserves of IPv4 addresses, which is unlikely for most of us, because well current policy has set the allocation horizon to 6 and soon to three months, or you can acquire IP addresses from someone who doesn't need them any more. I think address sharing is the only option to prolong the existing pool that you have.

But, don't forget that the ultimate path is IPv6, so, while sorting out or resolving this IPv4 shortage problem, we shouldn't forget about putting IPv6 growth alongside. And mark made an excellent presentation on transition technology that can allow to you deploy IPv6 connectivity along IPv4.

Well, an IPv4, dealing with IPv4 will become more and more painless. IPv4 sharing is not fun. NAT breaks applications. Reputational reporting presents a problem. Geolocation breaks. You can't afford port 80 or 443 for everyone and this is a long list that probably many of you know.

And well at those questions: It requires new technologies requires new expertise and we ?? well, they are quite new, they are not mature. They are probably less mature than IPv6 itself. So, let's briefly look at different types of ISPs and their need for IPv4.

If you look at transit providers. I think they need ?? although they need to support IPv6 transport and routing, their internal requirements are quite modest, and the internal network in fact they can run this on IPv6.

If you look at enterprise, again for most of the enterprises the need is modest. Also they have more control over their network and the installed client base so the structure of the network is simpler, I am not saying they are cheap but they are simpler than for other types of service providers.

It's painful because you need a real IP. For a long long time, but not a lot. That's good news, and virtual hosting might help a little, but what is important here is that at the moment, I think content providers, they are the main drivers of IPv6 deployment. They have the best chances to break this chicken and egg problem and that's why IPv6 is probably important for them.

Now, that is where the pain is. Residential providers: Broadband. They would require technology upgrade to deal with IPv4 shortage problem. They would require hardware upgrade to provide IPv6 connectivity. And they need, and remember this formula, they need is proportional to the number of house holds, which is big.

And that's another painful group, it's mobile operators. Probably the best path for them is to deploy NAT64 and IPv6 only but they still need IPv4 addresses and still to support IPv4, if only for data roaming. And their needs are even higher because they are proportional to our population numbers.

So, if we analyse the dynamics of this need for IPv4, one can draw a diagram like this, and while the light green is the growth of the Internet which we all hope will continue growing, the dark green is the size of the IPv4 only Internet, which we hope, and if we all behave responsibly, should go down at some point. And the rest of the lines, the blue and the red line, are specific to a particular ISP and the blue one is the growth of this ISP, and the red is the hump I mentioned in the title of my presentation. So what is important here, that this graph, and this is a positive, that's a good scenario. I mean we can draw a less good scenario here, but what is important here is that this graph assumes and this particular shape of this red curve assumes that ISP deploys IPv6. Because if ISP doesnt deploy IPv6, the IPv4 needs are insensitive to the global deployment of IPv6. So in this case, this red curve will go up along the growth of the ISP and I am afraid this growth will not last for long.

So, I hope many or more and more ISPs are answering to this question as yes to deploy IPv6. Because deploying IPv6 is the only way to get all of this, to create this hump and get over it. It's good for the Internet. I think, again, if we look ?? we are talking about public good and I think if we talk about our responsibilities as players in this global system, that's one of the things we shouldn't forget. And it's also good for you. Yeah, you have to get over this hump, otherwise it just continues pain. And another thing is, it's easier to start doing this while IPv6 is relatively small, and that applies for content providers, that applies for other ISP service providers, etc., etc.

And, well, you have to manage coexistence in parallel. Ensure that collusion, you will support, support your growing needs for IPv4. So you have to plan your investments as well, otherwise IPv6 alone will not help you.

Any questions? Thank you.

(Applause)

CHAIR: Thank you Andrei. Our next presenter is going to be Olaf Bonnest.

OLAF BONNESS: Hello everybody. I want to give a talk today about a mechanism we call On?demand IPv4 address provisioning in dual stack PPP deployment scenarios. And I see that the front is a bit broken. Sorry about that, but we are used to ?? we are forced to use some special forms.

I want to structure my talk as it is shown, hopefully in the next slide. I will begin with a short introduction and motivation. I will not tell you so much new things you don't know already. Then I will go and explain a bit which use case do we see behind this approach. Then I will describe this mechanism and the presentation is a short summary or conclusion.

This is already known to you. The last unused /8s have been delivered already beginning of February. Appears in the newspaper from which mention that already at the beginning of February, but this is not the last development.

Two weeks ago APNIC has already said, okay, we are out of addresses and we are starting to use the new policy for dealing with our last /8 we have. So that today only few still have addresses that could be given to their customers according to their used policy.

But what is the real problem? What went wrong with IPv6 deployment? I think we do not see the state of deployment in IPv6 as we would like to see. And that's because of different reasons. One reason is that many stakeholders do not see a compelling business case in deploying IPv6. Decides that, there are complex network scenarios where it's not easy and it is not cheap to deploy IPv6 and furthermore we have still today leaks in standard identification. Everybody who participates in the IETF for instance see that is there are still a lot of work to do to fill the gaps and to close the missing links. The same is true as for BBF and 3 GPP. That means we are still on the road, whatever you want to say IPv6 is really. Besides standards identification, the other leg of implementations, they are partially incomplete and they are missing in lots of devices we need in our network infrastructure. Home gateways, just name it, decides the mismatch in time line and of course there has been no search in compelling customer request that every ?? all ISPs started to move. So, this brings me to the conclusion that in a, that the foreseeable IPv6 deployment will not happen in the mid?term, so that we can serve the customers with IPv6 only. What does this mean? This means we have still to realise and to provide dual stack services, IPv4 and IPv6 services.

But looking at, say, the chart here. End of this year, latest, beginning of next year, the free IPv4 pool will be gone. But we want to deploy IPv4 dual stack services in order to be sustainable with IPv4 services for a long time and for this time we still need IPv4 addresses. After this time line then IPv6 will have been deployed very widely, and the Internet will rely on IPv6.

What can a provider do in order to overcome this problem? There are several possible theoretically possible methods to extend the IPv4 for usage. For instance, you can try to increase your IP address efficiency, this means you have to restructure your network, have to look in all the pools, excess pools you provided and have to think about okay, are these pools too huge, can I shorten them and so on.

You can start shifting all the traffic which is let's say always on to IPv6, especially for instance voice, voice traffic, other presence applications. You can do some time multiplexing of public IPv4 addresses, and this is the task I want to speak about, the On?demand IPv4 address provisioning. I come back to this with the next slide. But, other means you can implement are, for instance, you can let's say, virtualise your network, separate it into different regions which can operate with more or less the same address range. But this means at the end that you introduce some kind of NAT within a service provider network and this is, let's say, really, are the the last measure you would want to implement. All this NAT 444, Dual?Stack Lite and gateway initiated Dual?Stack Lite, just name it. All these approaches are, rely on a NAT ?? service provider network and it's really hard to maintain. Another solution you can think about is for instance, you can the other possibility to make protocol translation from v4 to v6 or vice versa. But I want to speak a little bit more about this time multiplexing of v4 addresses.

First, I want a little bit more to describe the use case we see behind this technical approach here. We assume here that we have already a dual stack PPP deployment, which means you have a PPP session which is capable of IPv4 and IPv6 transport. Besides that, we are assuming that the home gateways are used, are able to implement this On?demand IPv4 proportioning and they may provide operations. Another major assumption we have is that they always on, we call it always?on services, services like VoIP or DNS have to have a permanent connectivity, that these services are already running on top of of IPv6. And only in that environment it is also to provision or release public IPv4 addresses on demand if they are needed.

Many people are asking us why didn't you think about using two PPP sessions, one for IPv4 and one for IPv6, but the answer is pretty simple: It's just more avoiding scaleability issues on the home gateway and network access service. We did not want, let's say the customer has ?? might be different credentials, one for IPv4 and one for IPv6. Besides that, some licence fees are covered to let's say the number of PPP sessionings you have on the system, and if you use an explicit session for IPv4 and one for IPv6, then this will half the number of customers you can provide.

Another approach, or another often raised question is: Why do you not want to use a CGN, or NAT 444 approach? The answer is, it's only our last resort solution and it comes with complexity it comes with costs. It will impact the customer experience and at the end, it doesn't provide and IPv4 exit strategy.

Hence pre?assumptions we have for our mechanisms here. We have good IPv6 connectivity, but also to say the communication peer. Most connections are assumed to be IPv6 capable already. And all the things I mentioned already regarding the gateway. The network services have to be adjusted, but the protocols already there and already known network control the IP CP and IPv6 CP which are used together with PPP.

This mechanism I will show you in the next few slides, it's already has been discussed in the BBF, it's part of the systems there and there is also some ongoing discussions about this to make it a standard in the IETF.

Just to make it a bit more clear. We think that this mechanism can give us some, again can provide us with some additional or address savings. If you look at this daylight or weekly curve of IPv4 addresses you need, then you see the dark blue one is a regular IPv4 address usage which are more or less the ?? IPv4 address usage, which are more or less the IPv4 sessions that are active. At the time of the measurement. In order to provide these customers with IPv4 addresses, you have to make, or you have to reserve this amount of IPv4 addresses in your ISP address pool for instance. So it means that the light blue ones on IPv4 addresses which are reserved but not used at the moment. And if you assume that for instance, in the middle to long term deployment, you will have to provide all your customers with, for instance, voice communications over IP, then order to get all your customers served, you have to deploy additional IPv4 addresses and our mechanism shows how this could be done with IPv6 addresses and that you do not need for these dual stack connections in the IPv4 address.

Coming to the mechanism itself. Okay, here you have an RG, remote gateway, it means a customers device. The BNG, and let's say back end systems inside your provider platform, normally, if the customers is attached to a DSL or whatever, he will bring up PPP OE session with LCP authentication, then it starts only with IPv6 CP. It is a dual stack PPP session more or less, but it only starts with IPv6. So is that you will be assigned only an IPv6 address parameters. The BNG will assign it to the RG and at the end, after step 4, you have a running IPv6 only communication over PPP. Again, assuming that most of your always?on services are running IPv6 and now the case happens that there are still some other, or let's say legacy services coming up which are using IPv4, maybe because of the applications in the homeland are IPv4 only or maybe perhaps the communication peer in the Internet is still IPv4 only. Hence, the RG recognises some demand for IPv4 traffic and requests, via ICPC, and IPv4 parameters, from the B Ross gets it from the platform steering contents and locates IPv4 address, so that after step 8 you have a real dual stack PPP session deployed. You started with an IPv6 only PPP session, IPv4 has been added now, and after step 8, you are really dual stack connected to your BNG.

And if the RG recognises, for instance, by time loss, or by looking into the communication and detects no IPv4 traffic after a certain amount of time, then the L G L actively trigger to release the IPv4 address, will send this IPCP message to the BNG which relow leases the IPv4 context and after that in step 11 here, again the PPP session is still IPv6 only. With such a mechanism, you can, let's say, provision and release IPv4 addresses only if they are really needed. And this perhaps may help you to, let's say, save some of the addresses not in the near term, but in the middle to long term.

Coming to some conclusions.
This approach can be used to write customer address pools since after a certain amount of time, if more or less, IPv6 has been deployed and used more, IPv4 addresses will be given back, or will not be requested from the beginning. So that it will be possible to reduce, for instance, the pool sizes on your B Ross systems for instance. Of course, the assumption is that the always on or permanent services are produced on top of IPv6.
And that IPv4 addresses are only temporarily assigned and provisioned.
This can be seen as an exit strategy for IPv4 since, in the future, nobody will request IPv4 addresses within a dual stack PPP session any more, and at the moment, this mechanism is more or less already inherent in the existing standardisation documents but the problem is that it's only said okay, you have to handle IPv4 CP and IPv6 CP independently of each other, but nobody has made, let's say, a standard talking about releasing IPv4 context within a dual stack PPP session. So that's one of the ideas we want to bring up with this presentation.
This On?demand IPv4 address provision will not break existing implementations since I have to upgrade the B route of course, when I want to roll out IPv6 support and, I can do this, add on in the same moment when I make my BNG or B Ross IPv6 capable.

Okay, so the idea is to get some feedback from you, and that's why I thank you for your attention and would be happy to answer some questions.

AUDIENCE SPEAKER: Gert Doering: I think it's an interesting approach. It's not without risks. Of course if you have something like customer applications that do periodic IPv4 things, it might actually backfire and create lots of additional signalling load in your network without saving any v4. So, I assume that more studying will be needed. But still I think it's a reasonable approach to actually go to the end game where you just don't have enough IPv4 addresses for every customer, and most of the content as we see, so most customers won't actually need v4 all the time.

What I am curious about actually, that's a question bit is: Whether you have already lab tested this with implementations, because while the standard certainly permits this, I have the nagging suspicion that most implementations out there will do really interesting things if, like, for example, you have a long lasting PPP session, you have IPv6 active and then IPv4 signals, please shut down IPv4. I am curious.

OLAF BONNESS: Thank you Gert, I see your point. Perhaps to the first one, let's say IPv4 applications which are in periodic curve. The idea is not to switch down the, let's say ?? shut down the IPv4 PPP context immediately if you you don't have ?? after a second you have to play around with timers, our assumption is that it would make sense, for instance, to think about 10 to 15 minute period since this is more or less the use for the net states in holding and also for some reconfiguration or things. That's why I ?? I see the point that there might be some additional signalling traffic in a platform, but you can also use ease it a little bit if you say, let's say, keep the addresses in a pool on the BNG and doesn't acknowledge back to the radios or whatever. So, perhaps that would help.

So your second questions, I have not seen implementation of that up to now and we did not make any lab tests till today. So, I am also very interested in, if there is already some, let's say, tests happened somewhere, I would be interested in getting some feedback here.

(Applause)

AUDIENCE SPEAKER: Do we have time for another comment or question? Okay, Benedikt Stockebrand, freelance IPv6 guy. This sort of leads back to the situation where 10, 15 years ago when we were charged for online time, which at least in those parts of the world I am reasonably familiar with has been out of fashion for sometime. Do you have ?? made some assessment what sort of applications might be affected by this behaviour that would actually break and cause a problem to the customers?

OLAF BONNESS: Break by giving back the IPv4 address you mean now?

AUDIENCE SPEAKER: Means giving back the IP address while there is possibly still some sort of connection, maybe not a TCP connection but maybe some UDP stuff being active for example?

OLAF BONNESS: That's right. But we had to look into the NAT implementations, if they are implemented in the ?? today and we looked at these time?out sessions and we looked okay, if these time?out sessions are correct, then it's fine with us. Assuming, simply, that if NAT doesn't break, these applications, then we wouldn't do it either. Okay. Thank you.

CHAIR: So, in principle, we'd be over now, but we have one more presentation to keep you from lunch, but hopefully you'll find it interesting, so Lorenzo Golitti from Google who always does interesting stuff is going to come and show us some stats here.

LORENZO GOLITTI: Hopefully I'll be able to get my machine to project.

I apologise. To actually present these slides, I need to use ?? enter a one time password, sorry, I can't do that at the moment. But I can say something about the data that we have been looking at.

So ?? and also, I wanted to provide some feedback to the discussion that happened before about content. And the way we see it, from the content provider perspective, there is a clear incentive to more to v6, because v4 and NATTed v4 will just work really badly. And there is basically, that's not an option for us. But this is not something that's content controlled. This is something that only ISPs can do, so we can't necessarily actually make that happen ourselves. So all we can do is stand on the side lines to see if something actually, to see if the users actually show up, right. And we measure that very carefully. And if I had the data I could actually show it to you. But sadly the window is gone and to get it back I would have to log in through three different systems to get into the corporate network and I don't have the token here, so I can't show that to you.

But, so, we can't help, right? So we can provide content, but when there are no users, we can't really make the users appear and all we can do is avoid brokenness, right. So that's really our strategy. So, we have to ?? we have to do contingency planning. Right. Okay, so we don't want to ?? we don't want to be in a world like this, okay. So this is a problem for us. But at the same time, we can't ?? the only thing that we can do is inincentivise ISPs to actually deploy v6 and the way that we see it is, it's really the the only thing that will actually make that happen is if there is cost incentive to deploying v6 compared doing large scale NAT. The way we see it is, there is the real only incentive is the operational cost and especially the hardware cost. At the moment, it seems that there is a cost incentive to doing v6 because it's expensive in terms of ports. You have to throw away a whole line card slots with today's hardware. If you want to do NAT end line, doing it fully and lying on the same line cards isn't there yet. You have to spend money for logging and you have to do a lot of complicated stuff to keep the logs. You have support costs, my feeling is that's fuzzy. ISPs definitely know that better. But the way that we can help is, you know, we want to avoid all this stuff, right. But the way that we think this can go forward is that large scale NAT will have to be deployed anyway because you simply can't expect a long tail of content to move to v6 any time soon. So we are talking 10, 15 years whatever, so large scale NAT, unless you have v4 reserves sitting around, which for some is true but definitely is not true for new entrants, large scale NAT will have to happen. But if we can move the bulk of the content away from the NAT, then we'll win. Because, you know, the big content doesn't have to suffer the unreliable performance of large scale NAT, and the ISPs don't have to pay for the unare reliable large scale NAT. So, the idea is, you know, the ISPs save money, we get better performance, the user gets better performance. Everybody wins. The problem with that is we can't turn on v6 today because of the ?? you know, the broken users that Geoff showed you, and we basically have very good data around this at this point. We have been measuring since June of last year, and it's basically slowly going down but not going down fast enough. And at this point, we are at the level where we can look at individual networks, figure out, you know, how much, you know, how reliable they are, what's the impact of doing v6s, how many v6 users there are in that network, and we can, you know, evaluate whether it's worth enabling v6 for that network or not.

So, the way we see this going forward is that, you know, after v6 day, we'll be sort of looking at that data and trying to make it into something automatic. We could look at it and say well, if you have 5% of v6 users behind this resolver and they have acceptable performance, then we'll just turn it on, okay. So, that's something that we're thinking of doing. This is similar to what I think Akamai is talking about doing, which is basically just provide the record that has the best performance. If you have good performance over v6, we'll hand you a v6 record. If we found out that your users really don't have good v6 connectivity, we won't give you a v6 record, right and that is no different to what we do today as in, we'll give you the v4 record that we think will give you the best performance because it's close to you or because we measured it to have the lowest latency, so, this is kind of an extension of those systems.

So, that's the idea.

But ?? so, that's more longer term. So, what I wanted to say as well is, you know, why exactly we think that IPv6 days day is very important and why we are participating and how we are participating, okay. So, as, you know, you have probably seen this before, but, you know, a load of OSs try v6 first and just sit there or after 75 seconds or three minutes or whatever and sit there and for every connection, they'll fallback to v4 and the user just sitting there waiting. In particular 75 seconds is a lot longer than you think. Try it. Type it into your browser, start a stopwatch and then 75 seconds later I'll guarantee you will have forgotten where you are going. Depending on the browser, there was an interesting presentation at the IETF, you can dig it up in the slides. Some of the browseers say oh v4 didn't ?? v6 didn't work before, I am not going to use it any more for all the connections to the same host, we will just reuse the v4 connection. Others simply want to wait 20 seconds or 75 sections for a new connection. Firefox is particularly bad on this. There is slides on that if you want to know all the details in the IETF Working Group. We hope that chrome can be made a little bit smarter on this and to alleviate the impact, but, you know, to a large degree, the question facing application developers is: Why should I put a hack into my application that's only in there to avoid a temporary problem that is in another layer anyway? So if you go to application developments, you say, hey, you know, this stuff will break on v6 day, you can do it by reimplemented RFC 348 application that typically they will say to you, that's right the OS's job, I am not going to do the OS as jobs for it because if I make a mistake down the road I am going to be a bit ?? and also I am going to have extra code lying around I have to maintain. This is something applications would like to avoid if they can.

But, we are hoping that we can get some stuff in chrome so that, you know, on IPv6 we can say hey, you know, if you are, if you can't fix your connection and you can't fix your browser, try chrome it might work better.

So, okay, so we have been measuring the impact. The impact is about 0.03 percent and it's reasonably ?? it's reasonably constant across OSs. There is definitely the vast majority of it is due to Mac OS. Some of that is getting better. In particular, one of the things that we learned from looking at the data is that 6to4 is ?? it's terrible, right, it's a lot worse ?? having 6to4 turned on is worse than not having v6 at all because the failure rate is just so horrible that if you multiply the probability of people that have 6to4 with the failure rate, it's a higher failure rate than basically anything else. So, that's ?? that's one of the reasons why we'd love to see 6to4 depreferred and sort of declared historic by the IETF, which is, you know, something that's making progress now.

An example of this is if you look at the statistics of failure rates, again I had graphs for all of this, but I can't get to them now, but if you look at the failure rates. You will see that 6to4 ?? sorry, that v6 failure among Mac OS 1064 clients is over 1%. So over 1% of Mac OS 1064 users can't get to dual stack websites. And this is in the Internet as a whole. And 1065, which is the version after that, instead of gone from 1% to 0 .05 percent. Okay. So there is a 20 X improvement and that 20 X improvement is due uniquely to the fact that 6to4 is depreferred in 1065, right. So, you know, anyone who thinks that 6to4 is better than nothing, from our perspective, it's not better than nothing. It's a lot worse. Because every 6to4 user that's there, is potentially a broke every user that we'll have to deal with down the road and it's stopping us from turning it on.

This is an example. There is lots of bugs here. I think you have seen this before so I am not going to talk about that. It's an MTRA, and all sorts of violations here.

We can't fix it really in home routers. We are hoping kind of that we can fix it in the hosts. I think the OS manufacturers are making progress. I don't know that Apple fixes will be there in time for v6 day so I think we'll just, as regards apple, we'll ?? what we have today is what we'll have on June 8, which is 0.03 percent. Microsoft has already, you know, a significantly better than apple, so, if you look at sort of non apple clients, the brokenness is about four 9s, which are where you can start thinking about turning things on. Not we object search, because we can't have a user not be able to reach web search and not even be able to do a search to figure out what's wrong, right. That's not acceptable. But, you know, other properties, you know, when you get to four 9s, you can start thinking about turning on v6 for other properties all the time.

So, we are hoping that the OS manufacturers will make these changes. We are hoping that deprecating 6to4 will help.

Other issues IPv6 day intended to solve is some backbone operators don't talk to each other. If you are a customer of one of these you can't talk to a customer of one of those. If you are a level 3 customer, you can't get to Facebook, that kind of thing on v6. So this is essentially the same problem. So, basically, you know, time?out on every connection. And so we'll see, you know, hopefully this will get resolved before IPv6 day, because at least, you know, there is a reason to fix it now.

Other issues that we want to solve is in some, you know, some access networks they have, you know, there has been evidence in the past that when, you know, for example, in Japan when a big Japanese website went dual stack they experienced and immediate 5% drop in QPS, and that's because, well, it could be because the walled garden that's used in Japan the walls fell over and stopped working because these ?? because these users have ?? walled garden connectivity and have firewalls that reset all their TCP connections. What could have happened a few years ago is that all those firewalls fell over and they couldn't generate any resets any more. So, we hope that this time this won't happen. The problem is that these users also experience a one second latency here. And if you take, you know, if you take ?? if you imagine that Japan is, I don't know, 3 percent of, you know, 3 percent of global Internet traffic, pull a number out of a hat, take population and then adjust for you know penetration, call it 3 percent, and if you say, that's you know 1 second latency hit, then that's a 30 millisecond latency hit across the board for all your properties which is a number we would very much like to avoid. So in the future we'll have to deal with this by simply blacklists those networks because we just can't have that latency hit.

So, okay ?? finally, we need to find out if this v6 thing is actually going to, you know, is actually going to do what it promised and fix the Internet for us. Because if we ?? if it doesn't work, then we have, you know, we don't really have a plan B, right. The idea is that even if all the transitional solutions and everything, the idea was always yeah, at some point we'll have to do v6. Now if we can't make it work, then we have to figure out what to do instead. Okay.

But on the other hand, if all goes well, the sky won't have fallen and we know that we can actually do this. And that is a significant, I think, gain because what I have seen in many organisations is that when they do v6, it turns out to be easier than they thought it was, and then that basically unblocks the deployment. It's oh yes, we have done it already, let's do some more. We have seen this I think in a recent, you know, conference there was a large hotel Wi?Fi operator and the organiser of the conference was very effective in getting them to actually deploy v6 on the conference wireless. This is mainstream operator, it's not a RIPE meeting or anything, what happened was the guy that was working on this came and gave a presentation after the conference saying, yeah, we turned on v6 and it all worked for you and it was a lot less work than we feared it would be, and you can bet that those guys are going to offer v6 as an option to future conferences, right. So that is a huge gain. Actually having something that builds confidence is very important.

So what are we going to do on IPv6 day? June 8, mid?night UTC to midnight UTC. Major players, I think there is over 100 websites on the list today. I think there is a talk on Friday on it, these guys will be, we'll be on it, and we'll be publishing AAAAs for many websites. For Google that means basically everything. There are a few Google service that is don't have v6 records but there are not very many. So basically if it's a Google service and it's over HTTP it's likely to be over v6. G?mail, yes, ABS enterprise, yes, YouTube, yes, videos, yes, blogger, yes, g?mail, web search, everything will be v6, so, you know, keep that in mind. Okay. So if the v6 network is broken, people won't be able to get to g?mail, things like that.

So, and we are working on how to send messages to our users about this.

We are using perhaps something like this, or if test IPv6 dotcom can't scale to the levels that we need, he can provide our own test, okay.

One final note, is, you know, every ?? when other organisations have done their v6 day, it's always resulted in v6 being left on. So, the plan is to turn the records off, okay. We will turn the records off at 23:159 UTC, but some services, from some operators, you can't rule out them staying on, okay. So, don't put in place a temporary solution and expect to be able to roll it back, you know, at midnight of June 9 without any consequences. It's possible that some operators will decide to leave some services on. I can tell you that dub?dub?dub dot Google dotcom won't stay on. I can tell that you now. But, you know, and this is not just Google, right, there is major websites that are participating and they may decide to leave something on, okay. Maybe not their main website. Maybe a smaller website, maybe a secondary thing, but, you know, if you basically have ?? if you are basically taking the position you are not going to support v6 and you are going to weather one day support calls this will turn into a permanent outage for you on that website. The way that I see it as you know from the content provider perspective, this is basically all we can do, right. We can't just publish AAAA records for our services and just suffer the damage, right. That's not productive for anyone. So ?? but I do ?? you know, I'd like to hear suggestions from the floor on the how we can do this. So, you know, what else we should be doing, and, you know, whether it makes sense for you, for us to automatically detect, you know, networks that have lots of v6 connectivity and automatically turn AAAA records on for them. Whether that would cause you problems or whether it wouldn't. Whether it's something you'd welcome. So oh, finally, if you do participate in v6 day, do it right. Don't rush your deployment just to make the day. It will just give you know ?? if it doesn't work it will give v6 a black eye and that's worst than nothing, okay.

AUDIENCE SPEAKER: David Friedman. Am I not right in thinking that a Google NAT has a form of single sign on authentication for Aps and YouTube, it's all pretty much the same thing. That kind of correct?

SPEAKER: I know as much as you do. Yeah.

AUDIENCE SPEAKER: Following on from that thought, I have noticed that within YouTube there is an option to change from Flash to HTML 5 and it's a preference that somebody remembers. Would it not be an easy thing for instance, to have the user saying, yes, I'd like to access the services at v6 and have everything switch over to v6. Much like Google moving stuff over to SSL.

SPEAKER: You are talking about the cost of an HTTP reconnect.

AUDIENCE SPEAKER: Yes.

SPEAKER: We don't like increasing latency and also ?? and yes, opt?in is helpful but basically, if you are thinking about any sort of opt?in mechanism, nobody opts in, nobody opts out, right. Nobody changes defaults, right, so if ?? and this is a bunch of engineering work to make sure that everything redirects properly and it basically gets you no benefit because nobody ever changes settings. By nobody I mean, you know more than one in 1,000 or something, right. So... you want to take that as well.

AUDIENCE SPEAKER: I think one of the other complications, you have to start using other host names and then that begins to complicate the whole login process with the same origin policy and cookies. Then you have got URLs that can't necessarily be shared across users and things like that. It becomes kind of a marketing branding nightmare as well.

SPEAKER: This is my colleague from Google. He's the v6 engineer. I am the v6 infrastructure guy.

AUDIENCE SPEAKER: Lorenzo, I have a question on chat from Sasha Pollack from six. He asks are you selling? Give us all your network data under the guise of an IPv6 transition strategy.

SPEAKER: I didn't understand the question. Maybe, and I don't know what the question is ?? I really don't understand the question. Maybe the question was about, you know, whether to turn on v6 for particular networks. That's data that we measure right. When you connect to Google, we figure out if you have working connectivity or not. So, we are not asking anyone to give us that data, but I could be misunderstanding the question.

AUDIENCE SPEAKER: Paul Boot from the Netherlands IPv6 foundation. Lorenzo, I think IPv6 day is a cool initiative. You told us that you currently measure that about 1% of all Mac OS users will have problems.

LORENZO GOLITTI: No, no, 1% of 10 /64 and below users. After 10 /65 the situation gets much better. It's not as good at Windows but Windows has its own issues with v6 because it sometimes ?? it's basically Windows is a lot peakier about trying to use it at all and even when it's there it won't use it because of things like bugs. But that was not your question, go ahead.

AUDIENCE SPEAKER: Was the percentage of Mac OS users that is currently using 10 /64 which is broken?

LORENZO GOLITTI: So, 1% of 10/64 users has issues. How many 10/64 users in, as a percentage of global Mac users, I don't have that data. Tora has that data on his website. It's, I think, around 30% and declining very, very, very slowly.

AUDIENCE SPEAKER: And because it's declining very slowly, that's a problem, right?

LORENZO GOLITTI: Yes.

AUDIENCE SPEAKER: Could you consider informing those users before IPv6 day that they have an outdated computer and that they should update and redirect them to proper information about that?

LORENZO GOLITTI: Well, part of the issue there ?? we definitely are looking at trying to warn users that we think will have connection problems. Part of the issue there is we don't want to tell users to buy a new laptop. Because apple has stated on the record that there is no upgrade path available for 10.4, if you have a power PC notebook. You can't upgrade. And even from, you know, if you were to upgrade from 10.6 to something more recent like, I don't know, lion, I would expect that ?? I don't use apple so I don't know, I would expect that you have to pay for it. So we can't ?? we also can't go out and tell users your v6 connection is broken, go pay Apple, right. It's not necessarily ?? I mean we can say upgrade your application, download this free application. But I mean, the best we can do is make Apple aware of the problem.

AUDIENCE SPEAKER: Are they aware of the problem or is it insolvable because it's a money issue?

LORENZO GOLITTI: They are aware of the problem. I think it's not a money issue. I don't know obviously, but my impression is that it's a trade off between the risk of backboarding patches and the release process, and these are operating systems that don't receive updates anyway, they are completely closed right, so nobody is pushing even security updates to these operating systems. Why do we have to go and do the engineering work to by port a patch to an operating system that we are not updating anyway? What's the harm, right? And so, really the only variable in the equation is the harm, because I think they probably know what the cost is. It's just a question of, you know, how many of their customers will complain and, I would imagine those are the metrics they use.

AUDIENCE SPEAKER: I have another question from chat. He says, lack of v6 support to Google and global caches is putting off many of you're dual stack users. Is Google planning on dual stacking them any time soon?

LORENZO GOLITTI: I actually forgot to mention that. There are two answers to that. The answer is it doesn't matter until they are users and, softwaring a latency penalty for not going to the Google global cache is really, if it's only affecting you know a tiny percentage of users, the impact on the network isn't that great. If there are issues that the connectivity sun reliable, then it needs to be fixed but that needs to be fixed regardless. So that's one part of the answer.

The other part of the answer, actually three parts ?? the other part of the answer is yes, we have GGC nodes doing v6 in beta at the moment and they are up and serving, okay. So the technical capability is there. The problem is that what's not there yet is the the automatic provisioning for v6 and the process of bringing v6 to an existing GGC node is basically manual, right. And so, the question is: Given that it costs, you know, engineering time to bring, to turn on v6 on those nodes, does it make sense to do that work now or does it make ?? does it make sense to users the engineering hours for something that's more useful at the moment and actually enable the v6 on GGC nodes when they are actually used to serve those nodes? Because one of the things that we have difficulty with in prior advertising this stuff is we get a lot of requests from outside saying please white list me, please turn on v6 for this service, please turn it on for POP, right, and to us, we need to find out what gives the greatest benefit to our users because we are a very small team, right. So, you know, what is important? You know do we need to have v6 support on XT nodes even if there are no users there? Or should we be working on how to warn our users for v6 day? On the other hand if if breaks it affect 7 hundred thousand users. The users on GGC nodes, that's a different number, right.

AUDIENCE SPEAKER: You are talking fast but you sound just like an ISP why they are sticking with v4.

LORENZO GOLITTI: I mean it's supported, okay. It's there. It's a roll?out yes, right. We can, you know, we have two sets of hands each, so... but yes, so the answer is it's coming and you'll see it in new turn?ups, you will probably see it in new turn?ups soon. At some point there will be a check box saying, give me v6, this is a v6 prefix, and it will all be turned up. The capability is there and we know.

AUDIENCE SPEAKER: Lorenzo, am I wrong if I interpret what you said about Google initiative on the IPv6 day, that you will be disabling AAAA white?listing on that day and enable it again the day after?

LORENZO GOLITTI: I think ?? let me say something again, that the plan is that we will effectively white list the whole Internet on the day, okay. And then on the day after, we will go back to the previous list that doesn't include the whole Internet. Does that clarify?

AUDIENCE SPEAKER: Yeah, that means that you will be enabling again white?listing for the servers you are supporting? Right now you are enabling DNS white listings only if your people might connect your services in IPv6 and I am not going into the reason behind, I know that. So on the IPv6 day, you will be putting your AAAA records in the wild for everybody, that's right?

LORENZO GOLITTI: Yeah.

AUDIENCE SPEAKER: And the day after ??

LORENZO GOLITTI: We will go back to the way it is today.

AUDIENCE SPEAKER: Are you considering white?listing, or putting also in white list or whatever, DNS records of service alongside with 8888? You have competitors right now, you know...

LORENZO GOLITTI: What's the question?

AUDIENCE SPEAKER: You have a public DNS records of server which is 888 in IPv4, and there are some demands out there asking you whether you consider putting also it, that service in IPv6 whether it is white?listed or not.

LORENZO GOLITTI: So the question is: Whether IPv6 support come to public Google DNS? We are working on T it will be available at some point in the future: You knew that already.

Sorry to stand between you and lunch.

CHAIR: Thank you very much.

(Applause)