 That didn't start playing, did it? Do you already have IPv6? What is IPv6? It is a new protocol for the internet. The current one, called IPv4, soon will not have enough addresses for everyone. IPv6 will help solve this problem. This is not a problem at all, because we have NATs. They are great. This may work for you, because you are using only small number of hosts at the same time, and control all of them. But if you have a lot of hosts you do not control, you would not do NAT. I have a perfectly running network. And NATs are good. They provide security. Mindside network is not seen from the outside. This is because the NATs are stateful. It is statefulness that provides the security, not the NATs. You can have stateful firewall and IPv6. But NATs are good. I get security for free. You pay for it. You pay for the hidden costs that are required to support the NATs. A lot of people spend a lot of time working to make the applications work with NATs. It is good for the economy. I give them work. So, go and throw some junk on the street. Someone will have to be paid to clean it, and that will be good for the economy too. NATs are good. I use them all the time. Why do you need them? Because they are good. Do you not rather have a way to cleanly express your subnetting and your security policies? The much bigger address space allows that. No, NATs are good. I will take your IPv6 if you give me NATs. They make me feel comfortable. Go buy some weed and smoke it. It will make you feel much more comfortable than NATs. Weed is prohibited by law. NATs are not prohibited by law. They are great. Stupidity is not prohibited by law either. Do not insult me. My applications do not work with IPv6. This is because you think you will be able to use the IPv4 forever, and instead of testing your applications and paying the developers to fix the applications so that they support IPv6, you are buying more NATs. Yes, NATs are great. I want to buy one for IPv6. But you said you do not need IPv6. Yes, I do not need IPv6. But I need NAT for IPv6. Are you NATs? NATs are great. I do not need IPv6. And you do not need all the customers with the mobile smartphones which will run IPv6 only? My customers are not asking about IPv6. That is because they are asking from your competitors who they know have IPv6 and with that they can offer innovative applications. I do not need new applications. The old ones are working well with NATs. NATs are good. Not so good of a conversation this is when you keep repeating yourself. Yes, NATs are good. Do you know that in Netherlands and France and other countries the people are getting native IPv6 already? I live in other lands. So I do not care. I do not care about their IPv6. Everyone has to use NATs. NATs are good. Do you have an iPhone? Yes I do. It works with NATs. And do you know that it already has IPv6 and you cannot use it? Oh. You mean my iPhone has a feature I cannot use? Yes. Your neighbor already uses IPv6 on the iPhone. I want to use IPv6 on my iPhone. Too late. You have been talking about the NATs too much so you cannot have IPv6. I want IPv6. Sorry, I cannot help you. You need to go and ask your provider. What if they do not have IPv6? I need IPv6 for my iPhone. You can get IPv6 from a tunnel broker. What is a tunnel broker? Do they do NATs? NATs are good. No, they provide the IPv6 connectivity using your IPv4 Internet as a wiring. If you terminate the tunnel closing up to you, it is almost as good as native IPv6. What are they? Go and ask your ISP. They need to know that you want IPv6. I will not tell you. Then I will ask them about NATs too. Yes, ask them what is better for them, NATs or IPv6. And I am going to the farm in the meantime to drink some milk from the madhouse. This conversation has exhausted me. Ask them if they have IPv6 for my iPhone. I will. Goodbye. Okay, everybody is here for Fibersplacing 101, right? Okay, we are out of IPv4 addresses. Is there anybody for whom this is news in this room? Yeah, that is what I thought. So what we are going to talk about today is where we have been, where we are, a little bit about how we got there. We will have some fun. I am an assistant professor at SUNY as we go in our computer science department. I have been there just about two years. Excuse me, I am finishing up my fourth semester. So I like it a lot. The windows have not been too terribly scary for me up there. We had a lot more snow. Problem solved. Sorry about that. We will have some fun and we will talk about how we can motivate content providers and then we will get into questions and answers. You can ask me questions about anything v6 related, not just the stuff in the talk, so feel free. And if you have a question on something during the talk, raise your hand, yell something. I will throw a microphone at you and you can ask your question on the mic. Okay, so a brief somewhat accurate history of the Internet. In 1967, believe it or not, Larry Roberts published the plan for ARPANET, which is the original genesis of the Internet. The first version of the Internet did not run on TCPIP. How many people know what the protocol was for the first version of the Internet? NCP, very good. You don't win anything, but right answer. Network control protocol. How many bits in an NCP address? Bueller? Eight. Eight bits. We had a worldwide market for an Internet of 256 hosts, people. Imagine that. The first host on the network was actually 1969, although I wonder if you can call it a network with only one host on it. But it literally was a single host Internet in 1969. By 1971, that was up to 15 hosts. Can you imagine an Internet with just 15 hosts worldwide? But it was at one point in 1971. I was five years old at the time. In 1972, we got email, the first email on ARPANET, 1972. 1977, we actually saw our first multi-network demonstration where ARPANET actually communicated with another non-NCP network. And where multiple independent topologies started talking to each other. In 1980, we were up to 213 hosts on the network. Those 8-bit numbers are kind of getting cramped. Maybe we need to do something about that. In 1981, we saw the establishment of CSNet and BitNet. And in 1982, TCPIP and the exterior gateway protocol were established. This was literally when we did the development of TCPIP as a new protocol for the Internet. We went from 8 bits to 32 bits, which at the time 16.7 million seemed like a really large number. So we went to 256 times that and said, 3.2 billion hosts worldwide for this network of research institutions and US military specifically is probably pretty generous. And from the available perspective at the time when computers were still pretty expensive and a given university might have a couple of hundred hosts, it made sense. It actually seemed like going from 256 to 3.2 billion would allow for an awful lot of growth. And it did. And in fact, it wasn't a problem as long as that's who was getting on the network. In 1983, so in one year, we went from TCPIP is a protocol that we now know how to write to we're going to turn off NCP. 1983, January 1st, we turned off NCP forever. It was still running on some hosts in some isolated places, but it was no longer the lingua franca of the Internet or at the time ARPANET as of January 1st, 1983. Everybody had to speak TCPIP or they couldn't talk to anybody else really. In 1984, we introduced DNS. Believe it or not, does anybody know what the TFTP host file or the FTP host file for IEN 116 was? Prior to RFCs, we had IENs, Internet Engineering Notes. And IEN 116 described a file that was maintained by the Central Registry that had a list of addresses and their host names line by line. You may remember most of your systems even today have an Etsy hosts file or equivalent. That is an IEN 116 host file. Now it just tends to contain your local information. But back in the day, there was a central host file and host names had to be unique across the entire Internet and you submitted your IP address and the host name you wanted to use to the Central Registry and they put it in the host file and everybody FTP'd that file once a day or once a week or whatever suited them onto all of their systems from that Central Registry. It was called host.text on the Central Registry. So we decided that wasn't scaling. In 1984, we implemented DNS. By 1987, the Internet was up to 10,000 hosts. Yeah, we need more than 8 bits for sure, but 32 still ought to be enough, right? I mean 10,000 hosts, that's a lot of headroom to 3.2 billion. By 1989, that 10,000 was up to 100,000. In 1988, we upgraded the Internet from 56 kilobit links to T1s. So we got 24 times the bandwidth. That was nice. In 1991, we went from 1.5 megabit backbone links to 45 megabit backbone links. That's right, 30 times growth in just two years on the bandwidth. Those were exciting times. By 1994, we were up to 4 million hosts on the Internet and we realized that 3.2 billion might not last as long as we thought. So we chartered the IP and G working group in the IETF and they started working on a way around this 32-bit problem. We're bad about scaling. Here are some famous scaling quotes that you might recognize. Thomas Watson once said in 1943, I think there's a worldwide market for perhaps five computers. I think we're a little bit past that at this point. In 1989, Bill Gates said, I have to say that in 1981, making those decisions, a move from 64K to 640K felt like something would last a great deal of time. Yeah, about six years, Bill. In 1995, Bob Metcalf famously said, I predict the Internet will soon go spectacularly supernova. Well, that's true. And in 1996, Capstrophically collapsed. Not so much, Bob. You get to eat your column. And he literally pureed his newspaper column and ate it from a bowl at the World Wide Web Conference in Santa Clara in 1997. So you can review the slide deck to get the details out of the article. In 1997, a certain exodus facilities planner that I was working with told me that 400 watts per square foot of power should be enough for any data center ever. I told him that he should put down the crack pipe. In 2007, Steve Ballmer, another wonderful Microsoft quote, there is no chance that the iPhone is going to get any significant market share ever. All of these have one thing in common. They were completely and totally 100% wrong. We're bad at predicting how things will scale. Very, very bad. The same with IP. Interestingly with IP, each time we run out, we seem to square the square and hope that's enough. We started with eight bits. Then we went to square that and squared that again to 32 bits. And now we've squared it twice again to get to 128 bits. But at 128 bits, we're talking about 3.4 times 10 to the 38th addresses. So it's literally going to be very difficult for us to produce enough hosts to overcome that because you're talking about more addresses than there are molecules in the known universe. And it's very hard to build a single molecule host. You have a question, Joe? Use the mic, and then you get to pass it to whoever has the next question. I said we're polluting the routing table anyway, and we already have networks with 12 bits of network addressing anyway. So whether we run out of number of bits for host addressing, we will eventually run out of number of bits for network addressing. Yeah, we're going to have to address that, but that's not going to be an address scaling problem. It's going to be a routing scaling problem. It's unfortunate we didn't address that with V6. Just hang on to it until the next person raises their hand and pass it to them. But, you know, he's right. He's absolutely right. We've still got a route scaling problem. The way we currently route packets based on destination address is utterly stupid and non-scalable. And we're going to have to eventually solve that problem. So that takes care of where we've been. Where are we now? We are out of IPv4 addresses, mostly. Four out of the five RIRs are no longer making conventional assignments. One RIR has some addresses left, but if you're not operating in Africa, that doesn't really matter, because they're the AFRNIC RIR. IPv6 now accounts for just over 10% of the internet traffic globally according to Google, speaking of Mike Joseph there. It now accounts for more than 37% of U.S. mobile traffic, and it is roughly 50% of the traffic at scale, based on the statistics I just saw in the knock a few minutes ago. Apple will stop accepting IPv4 applications in the App Store this year. They've already made that announcement. The App Store is going V6 only, and your apps all have to support V6, or you're going to be out. So now that we're out of V4, we have a few options. You guys saw the Mornat video earlier, if you were here at the beginning. We could stop all internet growth and live with the internet we have today forever, but I don't think that's going to be a very popular decision. We could start taking people off the internet in favor of higher priority uses. Let's make the internet entirely servers, and people just have to not talk to the servers. I'm not sure what good servers are without people to talk to them, but that's a thought. Spammers don't work too well without clients to read the spam, actually. Microphone. Get the microphone from Mike. Mike doesn't still have the microphone. If we got rid of the spammers, that would free up a whole lot of Appnic IP blocks that were assigned to China. Well, except that they were assigned to CNNIC first, and CNNIC doesn't turn loose of anything, but that's a different issue. The reality is the spammers are already on V6. Trust me, I run a V6 mail server. The spammers are already there. I think Michael vouched for that, too. His company runs some V6 mail servers. He does a lot more V6 email than I do, or his company does. So really, V6 is the only solution that's going to actually allow us to continue to grow the internet in a meaningful way. Mornat really, really fails spectacularly in a number of ways, and it just isn't going to continue to scale for more than maybe another two or three years, and then it's just going to become really horrific to try and keep using it. So with that, let's talk about asking your ISP for IPv6 because it's fun. In 2008, I called a particularly popular large cableco I won't name Comcast's name, but I was talking to them about my residential service, and the general response I got from the first person on the phone was IPvWoot. So they escalated it to tier two, and their response was IPvWoot. So they went to tier three where it was, yeah, we're not going to do that. So I kind of escalated it through the sales department and said, you know, I'm going to eventually need to be able to communicate with the entire internet, and the extent to which the internet can grow on V4 is limited, so some of that growth is going to end up on V6 eventually, so we're not going to do this as not a valid answer if you want to be an ISP in a few years, and they basically said, yeah, we don't care, we're not going to do it. So that didn't work out so well. In 2013, by then I was actually able to talk to Comcast, and they went, yeah, we don't have that in your neighborhood yet, but it's coming. And then it was, yeah, we don't have that for business class yet, but it's coming. And to their credit, today Comcast pretty much has IPv6 available for every customer that wants it. All you have to do is turn it on. Question? Get the mic. Get the mic. No, this is being recorded, so if you want to ask a question, you have to do it on the mic. No, no, exactly, I do not have a question. That's a work for small internet provider. So I see that customers don't want IPv6, so how to run the business without IPv4, version 4? Well, so your customers are going to eventually want V6, and you can't obviously force V6 down their throats. I don't know how you keep providing V4 to your customers when you can't get it anymore. Yeah, we're going to have a similar problem in probably 50 or 60 years where people are going to continue wanting to run their cars on gasoline, but we don't have any more gasoline. Once there's no more, I don't know how you keep selling it. I don't have an answer to that question. At least in the case of internet protocol, we actually have V6 to offer them as an alternative, and it works. I don't know what the alternative to fossil fuels is going to be when we run out of fossil fuels, but when you run out of a limited commodity, you run out. You can't keep selling it. That is the nature of a limited commodity, and IPv4 addresses are a limited commodity. So I don't have an answer to that problem, other than to convince your users that they need to consider V6. We have a lot of IPv6, but mostly we sell IPv4. Let's say there was a worldwide shortage on oats, and there were people that only liked oatmeal and didn't want to eat any other food. They're called the Scottish. Once they get hungry enough, they're going to eat something else. Trust me. You've got to pretty much treat it like that for IPv4 at this point. We're out. I don't know what else to tell you. I'm going to move on. So in 2013, I was looking at my iPad, and as long as I was on a Wi-Fi that had V6, I could get to V6 websites, no problem. But when I got on my AT&T cellular connection over LTE, it wouldn't do anything. It wouldn't get to the V6-only sites that I wanted to go to. So I called up AT&T. What do you think the first person I talked to said? IPv1. IPv1. Exactly. The next person at Tier 2 was actually more interesting. They started out with IPv1, but when I explained what IPv4 was and what IPv6 was, they were like, oh yeah, we don't support getting to websites over Internet protocol. This was Tier 2 support, mind you. Not the idiot that just answers the phone, the escalation engineer. To which I responded, what do you use to reach websites then? They didn't have a good answer. I managed to escalate it to Tier 3, who told me, well, the problem is actually with the web server you're trying to reach. We can't get to it either. And I said, yes, that's because your network is what's broken. And so they didn't want to believe that. So they called Apple and they got Apple on the phone with me. And Apple said, yeah, we can't get to it either. So it's a problem with the website. And I said, no, your network also doesn't support V6. So you're having the same problem because your network is broken in the same way as AT&T's. Needless to say, this argument went on for a while and then I finally got tired of playing the game and walked away without it getting solved. AT&T to this day, to the best of my knowledge, still doesn't know how to spell IPv6 on their cellular network. Yes, on Uverse, they actually have some support for IPv6 if you know exactly who to talk to and the right secret IPv6 handshake to get 6RD, which isn't even really IPv6, but it pretends rather well. So finally, I'm going to talk about a trade show that I was at in 2012 where I was in the Aaron booth and we were stationed next to a booth where they were pushing a monitoring software. I don't even remember which one it was. It wasn't Xenos. Though they would have had the same answer at the time, though they might have been more honest about it. And literally, people would come to the Aaron booth and we'd talk to them about V6 and get them all hyped up and they'd walk next door to this guy's booth and say, you know, does your product support V6? To which he'd say, well, you know, you're actually the first customer to ask us about that and so why don't you tell us what your V6 requirements are and we'll get back to you about it because we don't have any plans yet. So at the end of the day, I walked over and said, so, does your product support IPv6? And he said, you know, you're the first customer to ask about that. And I said, you know, that's really interesting because we've been talking to people next door. I've been in the booth next door all day and we've been telling them about IPv6 and I've heard them walking over to your booth and I've heard you tell more than 100 people that they're the first customer to ask about it. And he says, oh, you heard that, huh? And I'm like, yeah. And he says, well, actually we're working on V6 but we don't want our competitors to know it yet. We want to get out in front of them. So we're telling people that they're the first person to ask until we actually have a story to tell. I'm like, well, that's great for your marketing strategy but have you thought about the consequences that's having on people's thoughts about their ability to move forward of V6 on their networks? Oh, that might be kind of bad, huh? So, yeah. Fun, fun, fun times. So how do we go about encouraging content providers? Well, I've tried a few different tactics over the years. One of my favorites was the IPv6 buddy which is a little USB keyboard that has, it's a numeric keyboard mostly but it's 0 through 9, A through F, comma, period, colon, and double colon, and slash. So you can actually type addresses in really fast, even V6 addresses. And they called it the IPv6 buddy. And when I saw the announcement of the IPv6 buddy I thought this is really awesome. So I go to my shell window and I type host www.ipv6buddy.com or whatever their website was. And all I get back is an A record. And I was so disappointed. So, so disappointed. So I opened my email, you know, MUA, and I wrote an email to the guy's support address and I said, you know, I'd like to buy your product but it's very hard for me to take a product like IPv6 buddy seriously when I can't get to the website on IPv6. By the way, I work for Hurricane Electric and I'd be happy to help you get your website on IPv6 through a variety of possible measures. Please contact me if you need help. A day later, the guy had a tunnel up and working through our tunnel broker and had put his website up on V6 and had it fully functional on V6 and he wrote me back and said, thanks for pointing that out. You're right, it was a really stupid oversight. Send me your postal address and I'll send you a bunch of free IPv6 buddies. So that was pretty cool. Yeah, it was nice to get the free keyboards but even better, I got the website on V6 overnight and I didn't even have to really lift a finger other than writing an email. So I call that a success story. On the other hand, there's a company that's been coming to scale every year and I talked to them at scale in several other conferences every year and in about 2009, I talked to them and I said, you know, you guys got to come up with a way to support V6 on your server instances or it's going to be a real problem for your clients and they said, yeah, we looked at that and it cost us $100,000 and we don't have the budget. So in 2010, I talked to them again and they said, yeah, we looked at that and it cost a quarter of a million dollars and we don't have the budget. So I talked to them again in 2011 and they said, yeah, we looked at that and it'd be half a million dollars and we don't have the budget. So I talked to them in 2012 and it was a million dollars and I said, you guys realize that four years ago I talked to you and it was $100,000. Three years it was a quarter of a million. Last year it was half a million and now it's a million. This is not getting any better while you wait. We know but we don't have the budget. So Amazon is a fail. I recommend moving your servers off of Amazon if you care about being on the rest of the Internet. Unfortunately, the Google Cloud still doesn't support V6 either and neither does Microsoft Azure. So you need to look at alternatives like Linode. Linode fully supports V6. SoftLayer, which is now part of IBM, supports V6 though the older IBM data centers still don't. Or you can look at Host Virtual. All of those three providers do virtual hosting that does support V6. Sorry, Mike, you've got to get it on V6 or I'm going to keep bashing you. And you've got to admit that's fair. So, you know, if you care, move your stuff to one of those providers that actually has V6 and by the way, if you care about helping the Internet in general, let them know why you're leaving. That's the important part. Some success. Talk to Blizzard Entertainment at Game Developers Conference in Moscone Center once and at the time their reaction was kind of like, yeah, we don't care so much. Nobody's doing games on V6 and we don't really care. But in fairness, like a year later, World of Warcraft was starting to do trials with V6 and today I'm happy to say that universally across the board, if you've got V6 capability on your network, you can turn on V6 in your World of Warcraft client and it just works. World of Warcraft usage has dropped by 90%. No. Are you sure? Yes. People have mostly just gotten bored with it. That's why it's dropping. So, if you are a content provider and prefer not to get featured or bashed in one of my talks, there are two requirements. One, implement V6. Two, send me an email saying, please don't talk about us. I will not honor your request if you do not talk about you if you don't meet requirement one. So, be forewarned about that. But I will happily honor your request if you meet requirement one and send me the request. With that, we're on to questions and answers. I'm from Akamai and they're paying for me to be here partially. So, sponsor, slide, whatever. Questions? Comments? Concerns? Andrew, you're drafted. You can run the mic around. Yeah, that's what I've been doing. I think it's a likely situation that some part of the market, some country has IPv4 only mostly and the rest of the world gets IPv6. Like, one or two countries don't adopt the IPv6. Well, I don't think that that's necessarily unlikely, but I think that once it gets to that point, those countries are going to try and find a way to get on V6 pretty quick. Because once most of the world has adopted V6, they're not going to keep supporting V4 just to reach those two countries. Right? I think in three to four years, you're going to see the larger cable codes and cell codes starting to at least charge extra if you want to reach V4 content. Because by then we're going to be at a point where they can get away with that and where it's actually costing them so much extra to maintain V4 connectivity for customers that care that they don't really have a choice in the matter anyway. So, Archimai is a big content provider and you guys ship multiple terabits per second all around the world. So, my question is more around your global load balancing of this and moving from V4 to V6. As you learn these routes and you collect the data to decide, I think you can do a lot of DNS load balancing, you decide where to serve traffic from. How have you been able to work with a couple thousand IP addresses in a V4 slash whatever and then you have these big V6 subnets that you have to decide where to load balance things to. Without getting into too much detail we don't get down to the individual client address on the load balancing in either case. About as granular as we get in V4 is the 24 and about as granular as we get in V6 is the 64. So, we just deal with them that way so the load balancing we usually if able will return both an A and a quad A if the client is the customer producing the content is actually able to work with us to supply the content in V6. We actually support a lot of customers that have their back end server, the origin server, only on V4 and we will deliver their content both V4 and V6. So, if you have V4 content and you want to be available over V6 actually reaching out to Akamai is one way you can dual stack your entire web content without having to do any work on your side to get V6 enabled. Having said that, I want to do clarify one thing that you got a little bit wrong. We are not a content provider in the sense that we don't produce content other than the Akamai website and so the internet weather report and some things like that. We are a content deliverer and a content accelerator and also we provide DDoS mitigation services. So, I actually did have a question. We discussed Amazon's inability to provide IPV6 and I think it's supposed to be glaring at someone over there but I'm not exactly sure who. No, I wasn't glaring at anyone. I don't know if there's anyone from Amazon in the room. I was glaring at him for Google. Oh, okay, sorry about that. I like to pick on Mike because he picks on me about what kind of event. Is it possible to run a V6 tunnel into AWS? Can I just go to HE? You might or might not be able to do that. I don't know. I haven't experimented with Amazon's ability to cope with tunnels. To the best of my knowledge, everything at Amazon is rather strangely natted. It is, and therefore I don't think the tunnel would survive the NAP process because the tunnel is a protocol 41 tunnel. So we're going to blow up the same way AT&T did. So Stateful NAT is going to kind of blow chunks on that. Mike, and then the guy in the white shirt. I know that guy. I wouldn't answer his question. So I can't speak to GCE either, but if you can embed your tunnel in UDP, you can probably get it to each individual host on any cloud. But then you're going to have to run a per server tunnel. Because even if you get it into the cloud, most of the clouds are not providing a true layer 2 emulation these days, so you're still going to have to worry about host-to-host traffic. To answer the gentleman's earlier question too, I don't know what Akamai's doing. But a lot of networks are having trouble actually trying to approximate the aggregation layer for V6. V4, as Owen said, 24 is pretty safe. And it's relatively easy to collect the entire list of slash 24 is in a 16 million row table. But it's much harder in V6. So you can't assume 64. You actually have to approximate where the subnet mask lies for a particular user range. And there's a bunch of people out there doing that. But it's challenging. I did have a question for Owen. Akamai used to charge an IPv6 premium. Do they still? No. When did that drop? I have no idea when it dropped. It was before I started working there. All right, good to hear. Yeah, if it hadn't been before I started working there, I'd have found the appropriate person and beat them repeatedly about the head and shoulders until it got fixed. Yes. So at home, I have what, for all intents and purposes, a really great ISP with one obvious exception. Every time I bring up, when are you going to support native IPv6, their response is, but we have 6RD. And I have this wonderful conversation with them about the difference between tunnel and native. Never get a good answer out of them as to why 6RD or me setting up my own tunnel is their only option. Any tips for how to find the right camera? Sure, ask them about jumbo frames. Okay. Because the main problem that you actually have with 6RD is the inability to send a 1500 octet packet. So if they'll support jumbo frames for your V4 at 4096, for example, then you can get your 1500 octet packets through 6RD and you don't care. Yeah, it's still issues with firewall failover and 6RD is not fun. Yeah, okay, that's fair. Because they actually can't do it native at the particular modem they pride. So I have to do it myself and then it gets ugly. Yeah. I believe they blame AT&T because they're leasing equipment from AT&T and the COs. Well, yeah, and AT&T doesn't know how to do V6 except 6RD. So it may be that they don't have the ability to bribe you a better answer, in which case, again, I returned to the ask them about jumbo frames and that'll at least solve the MTU problem if they can figure out how to talk to AT&T about jumbo frames. I'm not sure AT&T can spell jumbo frames. The biggest problem with AT&T is that it's a very large organization full of very specialized individuals. Such that if you need a line of code typed into an AT&T router, it may take 38 people to do it. One to type the A's, one to type the B's, one to type... Yeah, any other questions? Down here in the front. I'm gonna make you walk as far back and forth as I can. So, as Akamai has rolled out V6, a V6 address is four times the length of a V4. Do you guys have any performance numbers? Were you able to, did you have to send more packets because you lose? Actually, by and large, it's the same number of packets because the header, believe it or not, is only twice the size of the V4 header even though the address length is 4X because we simplified the header, a great deal in V6. But no, we generally don't see much of an increase in packet count. And generally speaking, V6 actually performs better because of the simplified header. It's faster for the silicon to parse the header. The addresses are moved closer to the beginning of the header, so the silicon is able to do more advanced lookup while the packet is still arriving and other tricks like that. The fibs are actually simplified quite a bit on V6 versus V4. The firewall rules tend to be simpler because you're not having to deal with, well, what if it's not and what if it's not and all these other weird complexities that come with V4 and address shortages. And so, as a general rule, all of the V6 stuff is just so much easier, so much cleaner that it turns out to also be slightly faster but not noticeably. TE is much, much simpler in V6. Hold on. There's been a bunch of studies at NANOG about this and because V6 traffic tends to be on tunnels that are independent of V4 and those tunnels are smaller, they tend to be able to TE on more direct paths than V4 tends to. So, when you're talking about- Yeah, but hopefully the tunnels are gonna go away. Hopefully that's a temporary artifact. Well, no, but I mean like, yes, although, I mean, most of the carriers are still running MPLS, so they're still sticking it in some kind of MPLS tunnel. And a lot of the ones that carry V6 traffic tend to be smaller and therefore easier to merge onto more direct paths than before these days. But as V6 adoption increases, that will go, that benefit will go away. Yeah, but yeah, we try to avoid doing traffic engineering on our quote unquote network, but that's partially because we don't actually operate a network. So a governance question, you pointed out RFC 33, which had a drop dead date for eight bit IP addresses. Yep. My question is, is there any discussion within RN or within the wider community of regional internet registrars to have a drop dead for IPv4 or do we just not have enough IPv6 adoption at this point? Well, so there's two problems with your question. The first one is that that wouldn't be an RIR thing because the RIRs don't deal with RFCs. And this would be more in the lines of an RFC that would have to come out of the sunset for a working group in the IETF. Now, as to whether that's happening in the IETF, it's funny you should bring that up. Jacques Latour from Canada and I are actually at the moment working on a draft that we're going to submit an ID to actually propose just such a date when we move IPv4 to deprecated and then a later date when we move it to historical status. And we're still kicking around exact dates but the current thinking that we're probably gonna congeal around is proposing that it be deprecated around April 4th of 2020 and that it be moved to historical 4-4 2024. And are those dates going to slip as much as ADSB? Probably. But, you know, who knows? Any other questions, comments, rotten fruit, tomatoes? Yes, over here. Hopefully he's not going for rotten fruit or tomatoes. Do you see IPv4 ever going away for local networks or something? That depends. Would you say Novel has gone away for local networks today or not? Novel, IPX. So you would say yes, but I'm willing to bet there are some people here that are saying, well, wait, I'm still running Novel. Okay, so the reality is the answer to that question depends a great deal on your definition of going away. I think that it will probably not be in my lifetime that the last host running IPv4 is turned off or stops running IPv4. But I do think that IPv4 as the lingua franca of the internet is not going to be much more than another five years, if that long. I could be wrong about that. We may somehow limp it along much longer than that and really just like keep hitting ourselves in the head with a hammer as long as we can. But eventually we're going to lose consciousness and stop doing that. So because the guy hitting himself in the head with a hammer once he loses consciousness stops doing it. And that's what it's going to take for IPv4 to stop on the global internet. Right now we're hitting ourselves in the head with the Nat hammer over and over again. And some people seem to enjoy that. I myself am not such a masochist. So I don't run Nat at home. I've got enough before addresses that I don't have to. But other people are doing different things and have to support more growth than I do. So I think in terms of the global internet, four or five years of IPv4 is going to be achievable but painful. Going beyond that is going to be much more painful and the cost just keeps escalating. There's already a rather large social network that is actually trying really, really hard to stop running v4 at all. They want the CDN that they're working with to accept all of their origin traffic over v6 and then front them for v4 and v6 so that they can turn off all of their v4 internally and run just v6. And they wanted us to do that last year. So you're going to see more and more of that, I suspect. More and more people just not wanting to face the continuing and escalating expense of supporting v4. And that's what's going to kill it eventually. But I think we're probably at least three or four years away from that. And sadly, maybe more. Because as the other gentleman pointed out earlier, our customers want v4, they don't understand. Well, yeah, people want stuff they can't have all the time and it is what it is. Anything else? Great, go for it. Oh, one more. We still have 13 minutes left in the session so use them wisely. So when we get enough folks migrating over to IPv6, like are there any other concerns that you see on the horizon or is it all? Routing scalability, like Mike mentioned, is going to be the next great thing we have to solve because currently maintaining a global table of everything somebody considers to be a uniquely routed prefix, including the people that think that if you get a slash 16, you need to turn it into 256 slash 24 routes all with the same next hop because that avoids DDoS somehow that it doesn't. Kid you not, look at the routing table. Almost every provider in Asia has developed that religion. They disaggregate everything into slash 24s. It's horrible. That's why we have a 700 and 7,000 routing table today in v4. It's a little better in v6. They mostly are not disaggregating every 48, fortunately. Don't say that, just don't even think it. Yeah. So that's going to be the next thing we have to solve is we have to find a better way than global prefix based routing to route this. I personally think that if we started routing based on the closest transit AS, it would be much better because then the transit AS can do conventional prefix routing. But in order to do that, we're going to have to either add an extension header or change the format of the v6 packet. I've been looking at that for a number of years and I haven't found a way to do it that's clean enough that I can propose it to the IETF. I'm happy to talk about it with anybody that wants to help do better protocol engineering because I am not a protocol engineer and I don't want to play one on TV. But that's the state of things and that's what I think is going to be the next big problem. Mike, do you have any other ideas on the next big problem? Second? No, I mean, I think the point I was trying to allude to earlier was not just table growth, but we are, and you and I, you and I both supported a draft in Aaron to actually implement slash 12s. And the problem is that we are giving away large swaths of the v6 address space to the largest operators of which we are, the largest operators and of which we are the ones who approved giving that away. So, you know, but right now that hasn't bit us. I do worry that what happens 20 years, 30 years from now, when v6 would otherwise be fine, but for the fact that we've kept sort of the number of large operators at some fairly small value and we find ourselves running out of network bits. I mean, because v6 has brought back classical addressing, let's face it, the slash 64 is a pretty hard classical boundary and we moved away from that before. On the slash 48 is a fairly firm but not as hard classical boundary. And then so we've narrowed, we've whittled down those 128 bits to as much smaller range with which we can play. And then on the IR and numbers space side, we've been giving out chunks of those pretty liberally, partly to support v6 adoption, which I think is right. But, you know, that pastel did the same thing and Vince made similar comments about the early days of v4 allocation. So, I worry a little bit about what happens in 20 or 30 years. I worry a little bit about it but at the same time, I actually think we're probably okay because if you look at it, there are maybe 40 or 50 organizations that could qualify for a slash 12 today under Aaron policy worldwide. And there are 4,096, well, less than that because we gotta subtract a few for silly things like ULA. ULA is silly, I'm sorry, it's just silly. It has no purpose in life. It makes no sense whatsoever to me. Unique local addresses. It's basically the IPv6 equivalent of RFC 1918. Yes, it's a much bigger RFC 1918 space within which you may not collide and you have a much lower chance of collision but it's still RFC 1918 effectively. But the reality is it's still probably more than 3,000 slash 12s available. And even at that, what I have repeatedly said is that if we manage to exhaust the current slash three in less than 50 years and I'm still around, I'm happy to work on more stringent policy for the next 1 eighth of the address space. So we actually have a safety valve there. If we burn through the first 1 eighth of the address space faster than we anticipate in the next 30 to 40 to 50 years, we can apply the brakes on the next 1 eighth or even the 1 eighth after that if we have to keep issuing while we develop new policy. Arlena wants the mic. So I think it's gonna be okay. You know, I know a few organizations that I haven't worked for that could probably get slash 12s. You work for one of them. The others I can think of are AT&T, Comcast and perhaps Verizon or Time Warner. But that's about it in terms of providers I can think of that could qualify. It's relatively easy and I've actually so far qualified for three slash 24s but they were for tiny little organizations like Akamai, the US Department of Agriculture and Hurricane Electric. So we're not talking about particularly small organizations that are qualifying for slash 24s and in that first slash three, we've got 2 million of those available. So I think we're gonna be okay for quite a while with the current policy which is not by the way universal across all five RIRs. Erin is probably the most liberal of the five RIRs. Strangely enough, the RIPE is the most liberal IPv4 policy. They have the strictest IPv6 policies on the planet. So go figure. Arlena. Just out of curiosity, any imminent network security concerns concerns in the future of IPv6? Yes. IPv6 is very, very insecure. It has all the same security threats as IPv4. Are you aware of any class of enterprise network device like a firewall load balancer proxies that just that class of device when the current market is actually gonna be hindering IPv6 adoption? I'm sure there are several that don't support V6 and are therefore hindering V6 adoption among their customers but there are enough out there that now support V6 that my recommendation is vote with your dollars. Don't patronize those vendors and they won't hinder you. Juniper supports V6. I believe Checkpoint now supports V6. Who's the really tiny, goofy one? Not Sonicwall but... Zizel? No, not Zizel. No, not Palo Alto, it's Fortinet. It's Fortinet, even they support V6 now. And even some of the home stuff like from D-Link is supporting V6 now. My HP printer supports V6 though not very well. Even the IPv6 firewall in my HP printer supports V6 except you can't enter new addresses for rule sets. So, I mean... It has everything it needs to support V6 in the firewall built into the printer except the user interface for entering an address to put into a firewall filter only accepts V4 addresses. Thank you, HP. So one of the challenges actually is in home networking. Just recently I think we were both privy to a Comcast issue with prefix delegation and I think one of the things I know for, I mean I remember sitting down after V6 launch day with some of our colleagues from Apple talking about, I know Tony was working on issues in, well Tony and Cisco rather, but also our colleagues at Apple both were working on issues around prefix delegation in the home because one of the problems is V6 doesn't support NAT. So the class of devices that won't work in V6, all NAT devices won't work in V6 because V6 has a bullish NAT until somebody bastardizes it and starts doing NAT which we know people are doing. You can already do NAT with IP tables in V6. You can and that's unfortunate, but we know people are doing it and when V6 was designed it was designed with the premise that yeah. Actually amusingly that wasn't by design, it was by accident. They generically added V6 capabilities to the IP tables code and it turned out that when they added it, all of the same things you could do with V4 became things you could do with V6. So the problem is in the home there's remarkable amount of double or triple NAT right now because when home users want to expand their home network they stick another NAT device in and they don't think much about it. They just stick it behind their existing router and it will happily double or triple NAT their traffic which isn't great for performance and makes NAT punch through like really difficult. So gamers figure this out quick but average home users browsing don't. And so one of the challenges with V6 is when you have, how do you detect for example devices that are behind of the devices? How do you deal with prefix delegation within the home, the idea that right now most homes are getting flash 64s but really they should be getting 56s but even when they get 56s. No, really they should be getting 48s. There's still some debate about that. I'm strongly on the 48 camp. I remember. And I'm gonna stay there and I've got the microphone up front. That's true, well whatever size prefix it is whether it's 48 or 56, there's not a great way to distribute that within a home. Most home users aren't gonna go in and construct a routing table for their multi-tiered topology and so there's still a lot of work being done on the CPE end. Actually, once the CPE supports PD generically, stacking CPEs that support PD should be relatively simple. It should be and that's what you do get into the 56 problem, right? Cause like one of the things that Cisco has pointed out is if you're device, if you're doing 56s how many, what size prefix do you allocate to an individual port on each device and how do you figure out? Well, yeah, at that point you're limited to some version of four by two. Yeah, so that's where you start to get into those problems. Right, which is why 48 is better because now you've got all kinds of possibilities, two by eight, four by four, lots of different things you can stack together. It is true, but then it further pushes down the earlier aforementioned prefix size for networks. It doesn't do that much damage. The reality is that if you're assigning 48s to your, and here's the interesting artifact of error in policy that you can get stuck in. If you assign 56s to your residential customers and 48s to your business customers, which I realize Comcast is not doing, they're to their credit screwing their business customers just as much as they're screwing their residential customers no matter who you are, you get a 56. It turns out that if you're issuing 56s and 48s all of your error in measurements for whether you qualify for additional address space are based on the 56 number. So everybody you gave a 48, you better be able to justify 256 slash 56s. It's true, I did write that section of policy, but the community supported it, so. We got one minute left, so one more question. All right, thank, oh, there we go. Last question. You've talked a lot about various ISPs in telcos. Any comments on Verizon Fios? Verizon Fios. Anybody here who has Verizon Fios? Please call them and ask for V6 once a month or so until they finally implement it because they have been completely stubborn and intransigent about it and they still don't know how to spell IPv6 and they're almost as far behind a sprint these days. Believe it or not, in this regard, AT&T is slightly better than Verizon. AT&T Uverse, where you can get it, does V6 more than Verizon Fios. And in fact, Verizon Fios is the first one to put CGNAT on to their customers, but at least they give you the option of opting out. So you may want to check whether you have a real public address or an address in the 100.64 range on the outside of your gateway if you're on Verizon Fios and if you have a 100.64, I strongly encourage you to opt out of the carrier-grade NAT and tell them that you don't like it. I'll get to you offline, but I gotta clear the podium for whoever's next in the room. Who does support V6? Comcast, over their cable network, Time Warner over their cable network, AT&T Uverse, T-Mobile and Verizon over their mobile networks, Google Fiber, as long as you don't need a Google Cloud instance. Google Mail supports V6, YouTube, all of that stuff. So anyway, thank you all very much. Have a wonderful day at scale.