So, hi, everybody. Good day. I'm Matt Reincek. I'm Aaron's network operations manager and I'm going to talk about IPv6 implementation at Aaron, basically how we did this and when we did it and problems we encountered, successes we had, things like that. I'm really curious how many people were in John's presentation an hour ago. Okay, it looks like a lot of you were. He covered a lot of IPv6 history and things like that. So I'm not going to get into that. I'm just going to assume that you know what IPv6 is and what it does and that you probably need to look into getting it soon. So with that in mind, I'm going to pretty much skip this slide. I think one thing that's worth mentioning, though, is IPv6 is still in development. There have been several updates in the last 10 years that are worth knowing about and worth reading about. Most of them are related to security or routing table bloat and growth issues. So you can go back and look at this slide later on in the conference materials and give you some good reading material. I also want to mention just kind of my little anecdote for this presentation. What happened to IPv5? And John hit it at this during his presentation, but there's really kind of a bigger bit of trivia here. It's not just IPv5. There were a bunch of different versions of IP when they were developing the next generation after IPv4. IPv5 was a streaming protocol. It was developed, I think, by BBN originally, but it was Apple, IBM, Sun. A bunch of people looked at it in the 90s. This is before IPv4 had things like QOS and other things that made multimedia really possible. The streaming protocol was thought of as the answer to doing any sort of real-time multimedia stuff, whether it be voice or video or whatever. And eventually, because of QOS and other features in V4, especially hardware that really didn't suck, it kind of fell by the wayside. But it hints at kind of a bigger thing. There were actually IPv7, IPv8, IPv9. There were actually two different versions of IPv9. Two I referenced here and one of them never had an RFC because it was developed by the Chinese and it never really saw the light of day. I know that it had 256-bit addresses, so it had absolutely just huge headers. And the argument was that IPv6 wasn't big enough. If you heard John's presentation, he compared the golf ball to the sun sort of thing. There's a lot of V6 addresses and the danger of running out is pretty minimal, at least during our lifetimes. So maybe some other generation's problem. So here's the timeline for implementing IPv6 at Aaron. We started really thinking about it in 2002. V6 was pretty much finalized and I guess deployed in 1999. The RFC came out in December of 1998 and I think the IAB, part of the IETF, they ratified it in the spring of 1999. So in a way we were a little bit behind. We looked at things, we want to see if this was something we could do. I know that RypenCC, which is the European counterpart to Aaron, they had already done this. I think APNIC had done it. And we really wanted to get on the bandwagon and do it ourselves. So we started planning for this. And as you can see, we've deployed, well, six, five IPv6 networks throughout my time at Aaron anyways. And really these days we're standardized on dual stack. We do V6 everywhere. And I'll explain that as we go through this timeline. The first network we set up was a little standalone stub network. It was based on the Sprint T1 circuit. We used a Linux box with a Sangoma T1 card. We actually had Cisco routers that could do V6. The Cisco's have been doing V6 for a long time now. And I'm not completely sure I remember the rationale for why we chose a Linux router other than it was kind of cool. I remember that we had to actually hack the Sangoma T1 drivers to get them to work with V6. And Sangoma was actually pretty thankful for that. We gave them the code back and I think that they used it for a while while they were doing this. It really helped us with troubleshooting. And I think that was kind of serendipity. We didn't intend for that to be the case, but having TCP dump and other things like that directly on a router was really, really helpful at this time to figuring out how things were breaking and things were breaking a lot actually at this time. We used an open VSD firewall. I can't speak highly enough for open VSD in this kind of situation. Its support for V6 even back in 2002 and 2003 was exceptional. You know, full state in V6, the ability to combine V4 and V6 rules together. It's really, really good. We use it to this day. I don't know if you're familiar with open VSD as a firewall, but, you know, Carp and all this stuff, it just rocks. And it supports V6 really, really well. Another feature that it has that is really nice when implementing a V6 network or any sort of experimental network like this is its ability to log drop packets directly to PCAP files so that you can look at them in TCP dump basically in real time. This also proved invaluable as we were tuning our rule set trying to figure out what the right thing to do was because we were really worried about security when we did this. It was one of the reasons why this was a segregated network. We didn't do a dual stack. We were really afraid of somebody's, you know, snack-smashing attacks, the ping of death. I don't know if people remember the 90s, around 95 or 96 somewhere around there. There was the infamous ping of death that one packet could dump, well, pretty much the entire internet for a while there. It affected everything from routers to Unix boxes to Windows boxes, just about everything. We were really worried about that. So we kept this network completely separate. We deployed our website on it. However, we did not have a quad A for www.erun.net at this time. We used v6.erun.net. We had a DNS server and an FTP server. Erin has a big FTP site that hosts a lot of the Erin zones, a lot of statistical information about the IP addresses that we allocate. You can go there anonymously and look around. There's actually all sorts of interesting historical information on there. In a way, it reminds me of FTP.UU.net from way back when. It has tons of stuff on there. It's interesting to go explore. Issues we had with this network had a lot of path into you issues. Basically, what that means most of the time is that somewhere there's a tunnel on the network and Sprint certainly had tunnels at this time. Even though our T1 to them was native IPv6, upstream here in their Sprint head infrastructure that didn't support IPv6 at all. So they did set up tunnels to get around that. This caused us problems because he had these sudden drops in MTU. V6 has mechanisms that are supposed to detect this. You have path MTU discovery. However, that didn't always work for us at the time. I think that's partially because our Linux router didn't work so good. OpenBSD, we had firewall rules that dropped the wrong kind of ICMP packets. So fragmentation would break and packets would just fall on the floor. We also had a lot of routing issues. We saw everything from Sprint would drop routes here and there, but frankly, usually they weren't the problem. We'd see entire countries fall off the network. They were doing maintenance or whatever and all of a sudden Finland would be gone. You wouldn't see them anymore. They would come back maybe the next day or the day after that. You'd see the same thing with a lot of corporations. They would just go away and some of them would be gone for weeks. It's because nobody noticed usually. Nobody was using this stuff, so it didn't really matter. Over the years, service has gotten a lot better. We actually just retired the Sprint circuit early this year. It served us really, really well. Things have changed. We're able to get V6 on a lot more circuits and it just didn't make sense to use this anymore. But that was our first 4A. In 2004, we basically did the Sprint circuit all over again. The reason why we did this is we, well, VentSurf offered it to us. That's probably the easiest reason. We have a data center at Aqueducts out in Ashburn, Virginia. And VentSurf, who is somewhat affiliated with Aaron, he's right down the road at the time. He was working for MCI, which was part of WorldCom. He had an experimental IPv6 network and he knew that we were running V6 and he was really interested in getting us to use his network and basically help us test it. It would give them traffic that they could look at. This is very similar to the Sprint network. The biggest difference is that we used a Cisco 2800 router this time. It just made more sense. In fact, we ended up going back later and replacing the Linux box with a Cisco router as well after the Linux box died. Pretty much everything else is the same, though. We stuck with OpenBSD. It continued to work really well for us. We had the same website, same DNS, same FTP, still a segregated network. We were really worried about security issues. People compromising V6 or bringing down hosts and causing problems on our V4 network. So we just kept everything completely separate. Still had a lot of path into discovery issues, had a lot of routing issues. Nothing really changed there. That's really about all there is to say about that network. Until we got to here. I mentioned earlier that we were in equinex. This is really the Worldcom network. What happened is Worldcom went belly up. I think people remember that. We had this kind of zombie T1. I think we got billed for it for a while, but eventually the bills kind of stopped coming and we got lost in this ether. We wanted to keep the service up. We kind of used it as a DR site for IPv6. Around the same time equinex started the Equisix IX, which was an experimental IPv6 exchange. Talked to some people at Aaron meetings and Nanogs and stuff like that. We figured out we could join that and it was free at the time for any commerce since it was in beta. All we had to do was pay for a cross-connect. We could get transit. We have an organization called OCADE. OCADE was kind of an IPv6 evangelical place. I think it's still around today and they'll provide transit to any network. The autunnels are natively if you can get to them. I think you have to be an ISP or an enterprise. There's an agreement you have to sign, but it's a pretty good deal. It's a lot like HEnet today or GoGo 6 or 6s and some of these other tunnel brokers. They'll do very similar things for you. However, they will offer native traffic if you can get to them on an exchange somewhere, which is pretty cool. Stuck with the San Francisco router. I think it was a 2811. OpenBSD firewall. Same website. The biggest difference now is that we felt like since we had good V6 connectivity for the first time, that we added a quad A for www.aren.net. This proved to actually be kind of a neat thing. It meant that people finally noticed that they could no longer get to Aaron and started emailing us. This led to an opportunity to help people figure out why their V6 was broken. You have to understand that we don't make money from our website. We aren't Google and we aren't Facebook in places like that. Having a quad A associated with our main website really was kind of an alarm bell for people. People that come to our website are usually ISPs or other networks. When they notice that things are broken, they do what they normally do with us. They email host master at aaron.net and they say, hey, your website is down. We say, no, it's not. It looks like your V6 is broken. That would lead into this whole conversation between my department and their ops department. We'd figure out what was wrong between us and them. Sometimes it was them, sometimes it was us. Usually it was somewhere in between and we could get a filter lifted or figure out where there's a tunnel or a routing issue and get all of that fixed. By having a quad A for www.Aaron.net, we were able to actually make service better for a lot of people and I think educate, which was really, really cool. I think it was the first time that my department really got involved with helping customers troubleshoot their network. This is also the first time that we started to play with dual stack. Because we had 100 megabit ethernet connection into the V6 internet, we were really interested in getting away from the segregated network. It made pushes really hard. It made everything really hard. We had to have these weird bastion hosts that had V4 and V6 and we could kind of push stuff and hold it there and then push it over later. We wanted to get away from that. We really wanted to get some hosts that had access to this great 100 megabit V6 circuit. So we started to dual stack very slowly. This slow rollout ended up V6 on our entire backbone after about a year. I think by the end of 2007 we had V6 across our entire backbone and in 2008 we finally rolled V6 over to our client network where we had hosts on the network. This included Windows XP hosts and Linux boxes, Macs. Basically we got to the point because of this network and how well it works, where we were deploying V6 everywhere we could in a dual stack configuration. And that led to these networks where they were dual stack by default. Basically what these networks were, there's two separate networks here. One was powered by NTT, the other one was powered by Tiskley at the time which is now TI net. These were Aaron's next generation public facing services networks. Basically what these networks were were the home for all of our public facing stuff. So the DNS, all of the Slash8 Internet or ARPA stuff, the Aaron.net zones, the Whois clusters, the Internet routing registry, and eventually a lot more list mail servers, web servers, just about everything that you can get to over the public we were placing on these networks. So I mentioned they were dual stack by default. They were completely standalone networks, basically stub networks, and we bought all new gear for these things. We used what we're fairly new at the time, Cisco ASR routers. I think we used 1004s. It's all gigabit. They worked really, really well. Had no problems with those. No firewalls at all. We had load balancers that we put in front of these services. We used Foundries at the time, had some problems with the Foundries to be honest. V6 support was beta, and for those Foundries, V6 support I think will be in beta forever. They're no longer, they are not going to release a production version of this software. I think we helped them take it as far as they could. If you look at their new stuff, it supports V6 far better than these things do. But we were able to get things to work. While we missed a lot of advanced V6 features, there's certainly not parity between what you could do on V4 with these Foundries, with what you could do on V6. We were able to get the support that we needed, and things worked pretty well. These networks are still around today. They've seen some upgrades. We're getting ready to replace the Foundries with newer gear that has better V6 support so that we can do things like GSLB over V6 and some other stuff. We're working closely with vendors. Brocade now. They bought Foundry, and we're working with them on their code to get all of this stuff working. And it's actually been a really good relationship. They really listened to us, and it's kind of surprising, but it's also cool. Other networks that we set up over the years are meeting networks. Aaron has two meetings a year. I think John mentioned that earlier. They discussed policy, and we were able to take advantage, starting around 2005, of the good V6 connectivity that we had developed at Aaron to set up our own tunnel broker, basically. So no matter what network provider we had in a hotel, usually we get a sponsor to come in and give us a DS3 or whatever for our meeting networks. But we could provide our own V6. So we'd set up a router on the edge, and we'd tunnel back to the air offices, and we'd get V6 to our members so that we could say, you know, all of our networks are V6-enabled. Try it out. You know, let us know if you can get it to work. This led to us doing tutorials where we would spend, like, half a day with people at our meetings helping them configure IPv6 on their laptops to get it tested, you know, whether it's Windows XP or Vista or Linux or Mac or whatever. We'd set up DHCPv6 servers, or we'd use RA, or we'd use Slack, whatever. You know, try out these various things, try to get them to work, and it was a really cool exercise for both Aaron's staff and for the members that attended our meeting. This evolved over the years into a testbed for all sorts of transition technologies. We've tested NATPT, IV, which is kind of a variation on NATPT. It's developed by the Chinese, and I think that it's basically dead as well. It's worth noting that NATPT is also dead in the water. Nobody's really using it anymore. Things like NAT66 and NAT64 are in the work at the IETF. This kind of goes back to the IETF finally starting to take the transition seriously, which is something that's fairly new. We've also tasted a lot of the CGN technologies in NATLite. You know, John mentioned earlier Comcast and the work that they're doing, deploying V6 in several different modes, and one of the things that they're doing is something called NATLite, which basically deploys RFC 1918 V4 space to a customer on their internal network, and then uses V6 transport from their CPE up to the network to another big NAT box that strips off the V6 and converts it back to V4 to get people to the V4 internet. We've tested that at our meetings. You can actually test that yourself. It's worth noting. It was developed by ISC. It's completely open source. You can go to the website and download it. There is an image for open WRT or you can deploy it on any Linux box, and it works actually really, really well, surprisingly so. At least on a small scale. We'll see how it works in large scale rollouts. Comcast is finding out right now, I believe. So how much V6 traffic do we see? We don't see a whole lot. I don't know if you can see the red on these graphs, but there is some red on there, I promise. We get a lot of traffic. We're a little tiny company. I think Aaron is about 50 something employees, but we get a lot of traffic. We get many hundreds of megabits worth of DNS traffic, for instance. So in a way, half a percent of DNS traffic over V6 is actually really good. Who is? I think that this status is a little bit wrong. It's gone up a little bit. So I think by the end of the year, we'll start to see probably about a half a percent of who is traffic over IPv6. Web traffic is kind of interesting. We get over a half percent of web traffic in general, which is kind of high for most sites. If you look at other sites out there, they're a little bit less. If you count Aaron into these statistics, we get almost 10 percent of our traffic over V6. Because internally, so many of our hosts are dual stacked that all of our push scripts and everything else goes over IPv6. All of our monitoring for web content and stuff, that happens over V6 now. So we generate, actually, quite a lot of V6 traffic internally. I think that that kind of helps speak to how well it generally works. It does just work. So that's kind of the end of the internet works. I want to talk a little bit about security. This is DEF CON, and I think that this is something that everybody likes to think about here. We learned a lot about security, and I think that it's worth noting how security changes in V6, what's different. Many things are the same. John hinted at this in his presentation as well. TCP is still TCP, UDP is still UDP.  That's really all the same. If you understand that in V4, you understand it in V6, there's a lot of differences as well. There are a lot of unknowns. V6 stacks really aren't all that well tested. Nobody really knows if there are these pings of death out there. It's worth noting that. I think it's something you need to be aware of. It's just new territory. Built-in features of V6 that promote security, they can also promote insecurity if they're used for evil, and we'll talk about that a little bit. Also, just multiple protocols means multiple policies. I don't know if people, how many people in this room were around in, say, 1993 or 95 in that time when TCP IP was really taking off, not just on the internet, but also on corporate networks. At that time, I was working on networks that held on network. So we had IPX, and in one particular place I was working on a network that had a nationwide IPX network. I could see printers in Alaska. It was basically all done using RIP. It was a big, well, it was a big mess, actually. They also had IP on their network at that time, and the access control lists and just the policy about routing and everything else was an absolute disaster. You could easily have this problem with v6 and v4 if you aren't careful. I think it's something that the policy side of this is probably the most important thing. If you want to have a secure network, you have to make sure that any decisions you make about what happens in v4 also happen in v6 in a similar way, at least wherever possible. More protocols, more problems. IPv4 and IPv6 are not the same. IPv4 features don't necessarily equal IPv6 features. For instance, IPv6 doesn't have ART. This is a huge thing. People are used to securing their networks with kind of layer 2, layer 3 ARP stuff to where MAC addresses are bound to ports and other things like that. You can't necessarily do that in v6 the same way, because v6 uses ICMP v6. You have similar concepts there. ICMP v6 is very multicast based, and it supports similar things. You still have MAC address on hosts and stuff like that. However, finding a switch that supports filtering of ICMP packets in that way right now is very difficult. D-links make some stuff that works, believe it or not. Cisco makes some stuff that works, but you have to have the right iOS image and things like that. It's just not very easy to do. So it's something to be aware of. One thing you can do right now, if you need that level of security, is to look at 802.1x, something that's basically agnostic to the protocol, and it works at the ethernet layer. You can simulate a lot of that same access control and whatnot using that technology, which at least will help you right now. I expect that within a year or so, you're going to see just about every switch that Cisco makes, everything that Juniper makes, and you know, given that D-link has switches out now, even Linksys and other people will start to make managed switches that support some of these v6 filtering functionality. It's also worth noting ICMP v6 is critical to v6 functionality. Fragmentation of v6 is drastically different than it is in v4, and ICMP plays a really big role in that. If you filter ICMP, you're going to break your v6, and this is basically how it works. In v4, fragmentation happens at routers, or it can happen really anywhere a v4 packet is passed. Usually that's in a router. In v6, that's not the case. What happens is somewhere you send a packet out, somewhere along that transit path, a router will say, this packet is too big, I can't pass it on. It sends an ICMP packet back to the source host. The source host then fragments the packet itself and sends the fragments on. This is a huge difference. If you filter those ICMP packets, the packets just fall on the floor. Your host never knows that it's packet was too big, doesn't get forwarded, and your connection will literally just die right there. Another big difference is DHCP. John mentioned earlier DHCP was developed for IPv6, and router advertisement, all that auto configuration stuff was, you know, people thought about that for v6. It was all back ported to v4 in one way, shape, or form. When v6 came out, it had no DHCP v6. It actually just had router advertisements. DHCP v6 was added on later in order to provide functionality that the router advertisement stuff just didn't do. So, for instance, with RA, you can't get name servers, at least not by default. And that's a big problem. You can't get network time servers and things like that. This has changed a little bit. There's been some updates to RA that allow some of this functionality, but a lot of people still want DHCP v6, and it functions a lot different. Basically, it uses ICMP to do all of this. It is nothing like how it works in the v4 world, and that's worth noting. Hardware and software support is less than ideal. I mean, this is just a fact, and I don't know that this is going to change overnight. It's changing slowly. I mentioned earlier that we've worked with Brocade as one vendor that's starting to introduce really good v6 support for their load balancers. But things like firewalls, finding good v6 support in firewalls outside of the open source world is difficult. I think the checkpoint in some of the big vendors have v6 support, but I don't think that they have v6 support that will look at all of the extended headers and some of the other things yet. That's going to take a while to happen. The good news is that there's basic support there now, I think, pretty much across the board. So you can do the basic routing policy. I think there is some worry about people taking advantage of some of the optional extended headers and v6 to full firewalls and do some other things because they won't know exactly where to look in the header offsets to figure out that this is a bad packet or not. So probably the best thing to do is just have really strict rules that drops all that anomalous traffic on the floor and look through your logs and sort it out later. I've mentioned switches and load balancers previously. Certainly they lack support there, but it's getting better all the time. One area that is actually really good is routers. I think if you have a Cisco or a Juniper, it supports v6 and there's almost complete feature parity between the two, which is really, really great. So security through obscurity. What does this mean? It means that we don't really know about much about v6 security in some ways and this is something people need to be aware of. IPv6 has been in many of us for a long time, 10 years. Even Microsoft has had v6 since Windows 95 and 98. They released I think something in 1998 before it was even in final form that would give you basic v6 support for Windows 98, believe it or not. The Comma and Wide Projects for Linux and FreeBSD provided IPv6 support basically while the RFCs were being written. They've had it almost since the beginning of time and OSX has had it since it came out because it was based on FreeBSD, but they aren't very well tested. How many people in this room have run IPv6 on their laptops? Some people have, but it looks like the majority of you haven't. That's generally the state of things. A lot of the stuff just hasn't been tested. Applications haven't been well tested. You have, it's not just the field, well it can even put an IPv6 address into this application. Is it capable of logging a v6 address? If you have any sort of log configuration stuff, does it support v6 well? Apache is a great example of an application that works really, really well, but there's a lot of applications that just don't. Which leads to stack smashing, buffer overflows. Who knows what we'll find with v6? I think that there's a lot of unknowns out there for applications that people, they tacked on v6 support real quick, but they didn't think about the consequences of what they were doing. That's all going to be exposed and it's just something I think that, you know, over the next few years we're going to have to deal with having good network monitoring, good log analysis, things like that are areas where you can try to catch this kind of stuff. There are just many unknowns to v6. The good news though is that, you know, exploits aren't well known either. I'm sure that there are probably even people at this conference that have taken v6 apart, read the RFCs, look at all these stacks and they have some zero days in their pocket right now waiting to wield against some site somewhere. But I think that those people are in the minority. The good thing about that is that security today is a lot better than it was back in 1995 and 96. Back then people didn't even really think about security. There wasn't a lot of malicious activity on the internet the way that there is today. When v6 stacks were designed for a lot of these hosts they were designed with the fact that people are going to try to smash this. They're going to try to get into it. We have good practices for auditing code and things like that now that we just didn't have before. So I think that things are a lot better built now. That will help us. It's also difficult to scan v6 networks at least from outside the network. You know, in-map tools like that they don't work as well over v6. There are some multicast exploits that you can use to discover v6 networks. Some of those can be used remotely. A lot of them you have to be local and using, basically 802.1x and other local network tools to secure your ethernet are good ways to mitigate those kind of attacks. It can be hard to guess addresses. It can also be easy to guess addresses depending on the addressing format that's being used. We'll talk about addressing formats here in a minute because that can be confusing in itself. But generally v6 addresses are just complicated. It's not nearly as easy to sequentially walk through a v6 network to try to discover hosts that way. And that can be helpful. In a lot of ways everybody is starting over again. Everybody is going to have to explore this and figure out what's the right thing to do is how to exploit it but also how to protect it. The good news is that you can't exploit something until you know how to exploit it. So at least right now I think the good guys have a little bit of a lead. So security features built into IPv6. These are actually really, really cool and very, very useful. You have the ability to set up encrypted sessions between hosts cross-platform. It just works. Right now it's mostly using pre-shared keys and things like that. However, opportunistic encryption, which you can do in v4, it's coming to v6. It's really just a matter of people writing the software and doing it. This allows you to have on-the-fly VPN servers. You know, on-the-fly encryption between hosts and authentication of hosts between hosts. It all just works. It's really neat. You can use this to enhance your routing security. So you can have routers running BGP between each other using AAH to make sure that there's the most spoofing going on between those links, which can help shore up your BGP connections and other routing connections. It also can provide routing layer security. You can have your typical three-tier application, for instance, and use AAH on the back end to make sure that all of the hosts they know who they're talking to. They're authenticating all those sessions. It's a lot like running SSL or something like that on your back end, but you're doing it down at the IP stack. And it should be lower overhead. I think eventually you'll start to see hardware that supports accelerating this stuff, just like you see some TCP and IPv4 header acceleration stuff in hardware today. You'll start to see IPsec acceleration for v6 because this is just really, really handy. It gives you an additional layer of security that you don't even really have today. I mean, technically, I guess you could do this in v4, but nobody does because it's just too hard. I think having it ubiquitously everywhere is going to make it much more usable. Of course, this also means that this stuff can be used for evil. Having encrypted packets can make deep packet inspection impossible. Difficult. It depends on who's doing the encrypted and if you have the keys to that. But potentially, your packets are completely opaque. This can be used for a lot of evil. Think botnets and command and control that packets are just completely, completely, you're blind to what's inside of them. How do you know if they're doing bad things or not? H is hard to configure. H is authentication headers. Basically, this is what allows you to set up two hosts to cryptographically authenticate each other. They know that they are who they say they are which can help prevent spoofing and replay attacks and things like that. Right now, it's really hard to configure and maintain. I think in some cases, it's not even cross-platform compatible. It will be eventually, though. I mean, it's in the spec and there's only really one way to do this. And eventually, you'll see interfaces like LDAP and DNS-based configuration for this stuff so that it becomes naturally easy to turn on. I believe that soon you'll see it integrated in things like Active Directory. So it basically just works, which is pretty cool. But right now, it is difficult to use. IPv6 has a lot of potential to be used for backdoors, Trojans, command and control, things like that because of these security features. As I mentioned, packets can just be opaque and you have a botnet that uses AH, for instance, to authenticate all of its botnet nodes, as well as the command and control servers and stuff like that. You make it a lot harder for researchers that research that stuff to break into them, but also to take them over and mitigate them or turn them off. That gets really, really difficult. I mentioned NAT here and it's not that NAT doesn't necessarily exist in V6, but technically, right now, there really is no NAT. There's no 6 to 6 NAT and this has one big security problem that I can think of right now, other than the fact that it's NAT and that causes its own security issues. And that's the PCI. The PCI spec right now stipulates that you must have NAT on your network. If you're taking credit cards or any of that kind of payment stuff online, you must have NAT. You have no NAT in V6 right now. There are some RFCs out there for NAT 6.6 and NAT 6.4 and all this other stuff, but that's not really, you know, I don't believe that any of that stuff exists on networks today, at least not in a production capacity. So if you have V6 only, you can't be PCI compliant and I think they're going to have to update their spec to address that. That's a real problem. It's also, IPv6 addresses are really complicated. They're long, they're confusing, they have letters, they have numbers, they have colons. If you have bunches of zeros, you can chop them off or you don't have to. It depends on, you know, what your preference is. Writing reg Xs for those, it's hard. Just reading those as a human is hard. You know, the ability to type them in is hard. It's going to lead to errors in confusion and things like that and just, you know, as a sys admin, working them with them is more difficult, which is going to lead to security problems because people are going to type them in wrong. And this is back to the dual stack. I mentioned dual stack earlier and how it can cause problems from basically a complexity standpoint. And this slide talks about that a little bit. If you have multiple stacks, you have multiple targets, you have basically, multiple problems there. You have a single host that has a V4 address and at least one V6 address, maybe more. All of these need to be in the right access control lists. They need to be in the right firewall rules, all of that. They need to be monitored properly. That's really difficult to maintain across one protocol. It's even harder across two. And, you know, so maintaining policy for routing or ACLs, all that's very difficult. Applications, they lack feature parity. So you have an application that does, you know, function X over IPv4, but it doesn't do it over V6. So what do you do? You know, and that can be as simple as listening on a TCP port. How do you fix that? So you have this application, it, you know, I have a box, it's dual stack, but the application that's running is only V4. How do you fix that?  So how do you audit these connections? How do you know when somebody is abusing the service and things like that? It's a real problem. You know, you have really the same problem with appliances. I mentioned the load balancers and firewalls and things like that. It's a problem that really we have to wait this out. We have to wait for vendors to come in and help us fix this stuff. So what did we learn at Aaron when implementing this stuff? We learned a whole lot and a lot more than really are listed on these slides. A lot more than we could probably talk about when we get into asking questions and things like that, but here's a few things. Tunnels are less desirable than native and that's really just to do with MTU. There's ways to work around MTU problems. For instance, for a while on the Sprint Circuit that we originally implemented, we just set our web servers to an MTU of 1280. That's the minimum MTU size you can have on V6.  It's not very efficient, certainly less than ideal. And that was to mitigate issues with tunnels. If you can avoid tunnels, I would say do it. If you have to use them, then go for it. Especially right now, there are companies out there that will give you free IPv6 transit over tunnels. And if you're in exchange, you can get 100 megabit tunneled connection to some really good V6 providers basically for free. Some of these providers will give you 48s. So you can set up and route your entire network. You may not get to get SLA for that, but it's great for your lab and things like that. So for experimental, use a tunnel. When you really want to deploy it on your network, try to find a provider that does it native. At least in our area, Aaron's located outside Washington, DC. And things have really changed in the last three or four years. It used to be that I could barely find a provider that knew what IPv6 was. And as providers now, even little ones, and little ones to me are kind of the remarkable ones, I can call them oftentimes, and not only do they know what IPv6 is, but they want to sell me a circuit with no hassle. It's harder to get that out of Verizon or AT&T or somebody like that. Oftentimes I can say, oh, well, I'm with Aaron and can we talk at DanAug or the member meeting and I'll kind of go in the back door and I can short circuit that. I think you guys can do the same thing. You just have to make a whole lot of phone calls. It's a lot harder for you to find somebody there that will listen to you, unfortunately. But that's changing. I really do suggest that if the big providers won't help you, go to some of the smaller ones. They may be a few hops away from the core of the internet, but to get native V6 circuit, it may be worth it. Continue to route V4 over your primary circuit. Use another circuit for V6. That works really well and I know people in the DC area anyways that are doing that through some of the smaller ISPs. Routing is not as reliable. This has gotten a whole lot better though in recent years. When we started doing this, the V6 internet was like the internet of 1989 or something. I mean it was really, really horrible. Now I would say it's like the internet of maybe 1999 or 2000. You still have routing issues, but they're really few and far between and I think a lot of the routing issues are actually related to growth more than people not knowing that their circuit is down or the router breaking or them running experiments during the middle of the day and things like that. It's usually because they're replacing equipment or they're having capacity problems on their old junky V6 router that they're using and they're upgrading them. So yeah, things have seen a great deal of improvement there. Dual stack really isn't so bad. You know, we feared this so much and we haven't had any problems with it yet. Though, you also saw our graphs and we aren't really getting any traffic yet either. So, we'll see what happens with that. You know, I have a great deal of confidence that our firewall rules and things like that are good and we're only letting the traffic through that we need to let through. So, you know, if we have an exploit there, it's really in some ways just as likely as it would be over before because it's probably an application issue anyways. Prox is really good for transition. They're bad for logging but they're great for transition. We use SixTunnel to proxy, you know, all sorts of non-HTTP services especially. You know, things like who is the routing registry, some of the before we replaced some of these services with V6 native versions, we used SixTunnel and some other home-built tools to make these TCP connections just work. We did lose logging but we were able to get the services to work. If it's a web-based service, Apache makes a great V6 proxy and you get full logging and all sorts of stuff with that. It works really, really well. I can't speak enough for how well it works. Squid also works but we don't have as much experience with it, Aaron, but it's worth mentioning because I know that it works really, really well. Mentioned that native support is better. DHCP V6 is not very well supported. Our client network at Aaron has dual stack. It's V6 enabled, it's got V4. We have DHCP on V4. We use RA on V6 and the biggest reason for that is is that most clients don't support DHCP V6 yet. If you have OSX, you know, I have a Mac, a lot of people at Aaron have Macs. You have a Linux box. It won't work with DHCP V6 out of the box. You have to go do stuff to it. The only platform that I know of that you can just install and go is Windows Vista or Windows 7 and right now we don't run any of that at Aaron. We'll probably have a few hosts that run it here by the end of the year. We actually have a lot of hosts that run Windows XP and they are V6 enabled and the way we do that is we use DHCP V4 to assign them name servers and they get V6 Transit. It just works, but I should back up a little bit. Windows XP doesn't support DNS over IPv6.  However, if you're in a dual stack environment it actually works just fine. So if you have this huge network of Windows XP boxes, you can actually dual stack them right now if they have V4 name servers that they can talk to. And that was a real boon for us because that meant that, you know, certain departments at Erin we didn't really have to do anything to other than go to their boxes and turn on V6. It's very convenient.  I mean, there's some technical issue that prevented from doing that but they did the best they could and it worked really well. Bugging vendors does work. Brocade and Foundry are great examples of this but gosh, Cisco, all sorts of people. Have been really good to us and they've listened to us and given us the support that we need. I really do think that it works. It's a lot like bugging ISPs. If you bug them long enough they'll start to listen. Every RFP that we put out for equipment, bandwidth, whatever, it lists IPv6 as a requirement. We will not do business with you if you do not support IPv6 and that has gotten vendors to support V6 because they want to be able to put Erin's name on their whatever it is, their website, their t-shirt, whatever and say that we are a customer of theirs and in order for them to do that they have to do V6 and it actually it does work in our case and I think that if you have enough buying power in your organization it'll work for you too. You tell them you're going to go somewhere else I'm going to use this transit provider I'm going to use this vendor because they have better V6 support they're going to listen to that their sales guys are going to cry when they lose that commission that they're used to getting from you. Security, DualStack makes policy makes policy more complex there's just no way around that I mean you have multiple protocols and policy is going to be more complicated the trick is to make sure that your policies are there's parity there wherever possible where there's not parity it should be well documented a good example that is in ICMP make sure that you document why ICMP is allowed in V6 in certain cases and it's not in V4 so that future generations will understand that IPv6 security features as I mentioned they're double-edged sword they can provide a whole lot of security but they can also be used against you and if your network is compromised I fully expect to see Trojans and other things that go into machine go into networks via web browsers to start using IPv6 especially when you think that Windows Vista and Windows 7 have V6 turned on by default and they'll even use Torito and other mechanisms to just tunnel it right out of your network it's one thing to detect a V6 connection that's encrypted and it's native where you can actually see it on the wire try doing that with Torito when it's inside a bunch of UDP packets over V4 it gets a whole lot more complicated V6X relatively untested relatively untested we talked about this before there'll probably be some exploits it almost seems inevitable maybe not but hopefully they'll be minor and it'll be a DOS kind of condition rather than UID0 sort of exploits but I mean I think that'll happen somebody's going to have some bug in their code and it will eventually get on earth this is a whole new world for hackers to explore whether they're white hats or black hats I actually think that's kind of cool no matter what your thing is if you're into compromising machines if you're into securing them this is a whole new playground to play in it's effectively an entirely new internet and I mean what's more cool than that really is something brand new and we're right on the cusp of it happening so understanding ICMP V6X is an absolute must you will break I mean I just can't say this enough fragmentation is very different in V6X in this related ICMP multicast is in tech vector it's a discovery vector it's also turned off by most ISPs right now and I mean much like it is in V4 finding multicast enabled provider or getting your provider to even turn on multicast free is difficult it's the same thing in V6X the biggest difference with V6X is that it's used to for neighbor discovery and other things so you can it's very easy to write tools that well basically it exposed an entire network to you or you can use that for real evil and use it to you know is for DOS attacks basically by using spoof packets and other things there's ways to mitigate this you know using ipsec and aah that helps having good filters on your network not allowing packets that are spoofed to get on you know basically common sense approaches that you use in V4 now a lot of that applies to or that she used for V4 also applies to V6X and one last thing is read rfc 4942 this rfc described security considerations when implementing ipv6 it's got a lot of really good information in there especially from kind of an ipv4 context talks about the differences between v4 and v6x and things that you can do to help secure your v6x network when you're implementing and that's that's it


We're talking all things AWS Summit, but right now I've got two powerhouses. You know them, you love them. John Furrier, Dave Vellante, going to be talking about SuperCloud, guys. We've been talking a lot about this. It's a big event coming up on theCUBE August 9th. And I got to start, Dave, with you, because we talk about it pretty much in every interview where it's relevant. Why SuperCloud? Yeah, so John Furrier years ago started a tradition, Lisa, prior to AWS, which was to lay down the expectation for our audiences of what they should be looking for at AWS re-invent, okay? John, when did that start? 2012, 2013? No, actually 2013 was our first, but 2015 was the first time when we'd get access to Andy Jassy, who wasn't doing any briefings. And we realized that the whole industry started looking at Amazon Web Services as a structural, forcing function of massive change. Some say an inflection point, we were saying complete redefinition. So you wrote the trillion dollar baby, right? Which actually turns into probably a multi-trillion dollar baby. We got it right on that one, surprisingly. It was pretty obvious. So every year since then, John has published the seminal article prior to re-invent. So this year, we were talking, we're coming out of the isolation economy, and John had written- Also, Adam Sileski was the new CEO, so we had our one-on-one with Adam. And then that's where the converges between Andy Jassy and Adam Sileski kicked in, which is essentially, those guys work together, even though he went off and boomerang back in, as they say in AWS. But what's interesting was is that, Adam Sileski's point of view, piggybacked Jassy's, but he had a different twist. Some, so, you know, people who didn't have a lot of thought into it said, oh, he's copying Microsoft, moving up the stack, we're like, no, no, no, no, no. Something structural is happening again. And so John wrote the piece, and he started sharing it, we're collaborating. He said, hey, Dave, take a look, add your perspectives. And then Jerry Chen had just written, Castles in the Cloud, and he talked about sub-markets, and we were sort of noodling. And then one of the other things was, in 2018, 2019, around that time, at AWS re-invent, there was this friction between like Snowflake and AWS because Redshift separated compute from storage, which was Snowflake's whole thing. Now, fast forward to 2021, after we're leaving the COVID economy. And by the way, everyone was complaining, asking Jassy, are you competing with your ecosystem, the classic trope? And then, remember, Jassy used to use cloud era as the example. I was like, dude, maybe pick a better example. Snowflake became that example, and what the transition was, it went from, hey, we're kind of competitive. For sure, there's a lot of examples, but it went from we're competitive, they're stealing our stuff to, you know what? We're making so much money building on top of AWS specifically, but also the clouds and cross clouds. So we said, there's something new happening in the ecosystem. And then just, it popped out. This term super cloud came up to connote a layer that floats above the hyperscale capex, not IS, it's not PAS, it's not SAS, it's the combination of those things on top of a new digital infrastructure. And we chose the term super cloud, we liked it better than multi-cloud, because multi-cloud can talk in one way. And Lisa, one other point too, I think four or five years earlier, Dave and I across, not just AWS, reinvent all of our other events, we were speculating that there might be a tier two cloud service provider model. And we were talking with Intel about this and others, just kind of like evaluating it, staring at it. And we met by tier two, like maybe competing against Amazon, but what happened was, it wasn't a tier two cloud, it was a super cloud built on the capex of AWS. Which means, initially was, a company didn't have to build AWS to be like AWS. And everybody wanted to be like AWS. So we saw the emergence of the smart companies saying, hey, let's refactor our business model in the category or industry scope and to dominate with cloud scale. And they did it. That then continued, that was the premise of Chen's post, which was kind of rift on the cube initially, which is you can have a moat and a castle in the cloud and have a competitive advantage and a sustainable differentiation model. And that's exactly what's happening. And then you introduce the edge and hybrid, you now have a cloud operating model that that super cloud extends as a substrate across all environments. So it's not multi-cloud, which sounds broken and like, put it back together. Disjointed, disparate, siloed. Hybrid cloud, which is the hybrid operating model at scale. And you don't have to be Amazon to take advantage of all the value creation since they took care of the capex. Now they went to on the other side because they're selling ECU and storage and ML and AI. And this is new and this is information that people don't might not know about internally at AWS. There was a debate, Dave. Okay, I heard this from sources. Do we go all in and compete and just own the whole category or open the ecosystem and coexist with Mongo? Why do we have these other companies or Snowflake? And guess what? The decision was, let's make it open ecosystem and let's have our own offerings as well and let the winner take all. Smart, because they can't hire enough people. And we just had AWS and Snowflake on the Cube a few weeks ago talking about the partnership, the co-operation, the value in it. But what's been driving it is the voice of the customer. And I want to ask you, paint the picture for the audience of the critical key components of SuperCloud. What are those? Yeah, so I think first and foremost, SuperCloud, as John was saying, it's not multi-cloud. Chuck Whitten had a great phrase at Dell Tech World. He said, multi-cloud by default. Right. Versus multi-cloud by design. And multi-cloud has been by default. It's been this sort of, I run in AWS and I run my stack in Azure or I run my stack in GCP and it works. Or I wrap my stack in a container and host it in the cloud. That's what multi-cloud has been. So the first sort of concept is, it's a layer that abstracts the underlying complexity of all the clouds, all the primitives. It takes advantage of maybe Graviton or Microsoft tooling. Hides all that and builds new value on top of that. The other piece of SuperCloud is it's ecosystem driven. Really interesting story you just told because literally Amazon can't hire everybody, right? So they have to rely on the ecosystem for feature acceleration. So it also includes a Paz layer, a SuperPaz layer, we call it, because you need to develop applications that are specific to the problem that the SuperCloud is solving. So it's not a generic Paz, like OpenShift. It's specific to whether it's Snowflake or Mongo or Aviatrix so that developers can actually build on top of and not have to worry about that underlying complexity. And also there's some people that are criticizing what we're doing in a good way because we want to have an open conversation. But here's the thing that a lot of people don't understand. They're criticizing or trying to kind of shoot holes in our new structural change that we're identifying to comparing it to old. That's like saying mainframe and mini computers. It's like saying, well, the mainframe does it this way. Therefore there's no way that's going to be legitimate. So the old thinking, Dave, is from people that have no real foresight in the new model. And so they don't really get it. So what I'm saying is that you look at structural change, structural change is structural change. It either happens or it doesn't. So what we're observing is the fact that a Snowflake didn't design their solution to be multi-cloud. They did it all on AWS. And then said, hey, why would we, why are we going to stop there? Let's go to Azure because Microsoft's got a boatload of customers because they have a vertically stack and integration for their install base. So if I'm Snowflake, why wouldn't I be on Azure? And the same for GCP and the same for other things. So this idea that you can get the value of what Amazon did, leverage and all that value without paying for it upfront is a huge dynamic. And that's not just saying, oh, that's cloud. That's saying I have a cloud-like scale, cloud-like value proposition, which will look like an ecosystem. So to me, the asset test is if I build on top of, say, Mongo or say Snowflake or SuperCloud, by default I'm either a category leader, I own the data at scale or I'm sharing data at scale and I have an ecosystem. People are building on top of me. So that's a platform, so that's really difficult. So what's happening is these ecosystem partners are taking advantage, as John said, of all the hyperscale capex and they're building out their version of a distributed global system. And then the other attribute of SuperCloud is it's got metadata management capability. In other words, it knows if I'm optimizing for latency, where in the SuperCloud to get the data? Or how to protect privacy or sovereignty or how many copies to make to have the proper data protection or where the air gap should be for ransomware. So these are examples of very specific purpose-built SuperClouds that are filling gaps that the hyperscalers aren't going after. What's a good example of a specific SuperCloud that you think really articulates what you guys are talking about? I think there are a lot of them. I think Snowflake is a really good example. I think VMware is building a multi-cloud management system. I think Aviatrix and Virtual Private Cloud networking and for high performance networking. I think to a certain extent what Oracle is doing with Azure is definitely looks like a SuperCloud. I think what Capital One is doing by building on taking their own tools and moving that to Snowflake, now that they're not cross-cloud yet, but I predict that they will be. I think what Veeam is doing in data protection, Dell, what they showed at Dell Tech World with Project Alpine. These are all early examples of SuperCloud. Well, here's an indicator. Here's how you look at the example. So to me, if you're just lifting and shifting, that was the first jet of cloud, that's not changing the business model. So I think the number one thing to look at is, is the company, whether they're in a vertical like insurance or Dintec or financial, are they refactoring their spend, not as an IT cost, but as a refactoring of their business model? Like with Snowflake today, or they say, okay, I'm going to change how I operate, not change my business model per se, or not my business identity. If I'm going to provide financial services, I don't have to spend CapEx. It's operating expenses. I get the CapEx leverage, I redefine, I get the data at scale, and now I've become a service provider to everybody else, because scale will determine the power law of who wins in the verticals and in the industry. So we believe that Snowflake is a data warehouse in the cloud. They call it a data cloud. Now, I don't think Snowflake would like that data.  No, I call it a super data cloud. But so, the other key here is, you know the old saying that Andreessen came up with, I guess, with every company's a software company? Well, what does that mean? It means every company's software company, every company's going digital. Well, how are they going to do that? They're going to do that by taking their business, their data, their tooling, their proprietary, you know, moat, and moving that to the cloud so they can compete at scale. Every company should be, if they're not, thinking about doing a super cloud. Walmart. I think Andreessen's wrong. I think I would revise and say that Andreessen and the brain trust at Andreessen Horowitz is that that's no longer irrelevant. Every company isn't a software company. The software industry is called open source. Everybody is an open source company and every company will be a super cloud that survives. So to me, if you're not looking at super cloud as a strategy to get value and refactor your business model to get advantage of what you're paying IT for, but you're paying now in a new way, you're building out value. So that's, you're either going to be a super cloud or get services from a super cloud. So if you're not, it's like the old joke, if you're at the table and you don't know who the sucker is, it's probably you, right? So if you're looking at the marketplace, you're saying if I'm not a super cloud, I'm probably going to have to work with one because they're going to have the data, they're going to have the insights, they're going to have the scale, they're going to have the castle in the cloud and they will be called a super cloud. So in customer conversations, helping customers identify workloads to move to the cloud, what are the ideal workloads and services to run in super cloud? So I honestly think virtually any workload could be a candidate. And I think that it's really the business that they're in that's going to define the workload. I'll say what I mean. So there's certain businesses where low latency, high performance transactions are going to matter. That's kind of the Oracle's business. There's certain businesses like Snowflake where data sharing is the objective. How do I share data in a governed way, in a secure way, in any location across the world that I can monetize? So that's their objective. You take a data protection company like Veeam, their objective is to protect data. So they have very specific objectives that ultimately dictate what the workload looks like. Couch base is another one. They in my opinion are doing some of the most interesting things at the edge. Because this is where, when you really push companies in the cloud, including the hyperscalers, when they get out to the far edge, it starts to get a little squishy. Couch base actually is developing capabilities to do that. And that's, to me, that's the big wild card, John. I think you described it accurately. The cloud is expanding. You've got public clouds, no longer just remote services. You're including on-prem and now expanding out to the near edge and the deep, what do you call it? Deep edge or far edge? Low or far edge? You've got a sucer called the tiny edge. Right, deep edge. Well, I mean, look at Amazon's outpost announcement. To me, HPE is opportunity, Dell is opportunity. The hardware box guys, companies, they have an opportunity to be that gear. To be an outpost. To be their own outposts. They got better stacks. They have better gear. They just got to run cloud on it. Yeah, right. That's an edge node, right? So that would be part of the super clouds. This is where I think people that are looking at the old models like operating systems or systems mindsets from the 80s, they're not understanding the new architecture. What I would say to them is, yeah, I hear what you're saying, but the structural change is the nodes on the network distributed computing, if you will, is going to run hybrid cloud all the way across. The fact that it's multiple clouds is just coincidence on who's got the best CapEx value that people build on for their super cloud capability. So why wouldn't I be on Azure? If Microsoft's going to give me all their customers that are running Office 365 and Teams, great. If I want to be on Amazon's got a suite which is their ecosystem, why wouldn't I want to tap into that? So again, you can patch it all together in the super cloud. So I think the future will be distributed computing, cloud, architecture, end to end, and... And we felt it was different from multi-cloud. You know, if you want to call it multi-cloud 2.0, that's fine, but frankly, sometimes we get criticized for not defining it tightly enough. We continue to evolve that definition. I've never really seen a great definition for multi-cloud. I think multi-cloud, by default, was the definition. Oh, I run in multiple clouds. You know, it works in Azure. It works. It's not a strategy. It's a broken name. It's a symptom, right? It's a symptom of multi-vendor is really what multi-cloud has been. And so we felt like it was a new term. What is the traffic rate of examples? Look at what we're talking about. Snowflake, Databricks, Capital One. Databricks is another good one. These are examples, Goldman Sachs.  And it's part of a digital platform. You know, people poo-poo the metaverse because it's really not well-defined. But every 15 or 20 years, this industry goes through a transformation. Dave, let me ask you a question. So, Lisa, you too. If I'm in the insurance vertical and I'm an insurance company, I have company editors. My customers can go there and do business with that company. And they all know they go to the same conferences. But in that sector, now you have new dynamics. Your IT spend isn't going to keep the lights on and make your apps work.  Now it's like I have cloud scale. So what if I refactored my business model, become a super cloud, and become the major primary service provider to all the competitors and the people that are the channel partners of the ecosystem. That means that company could change the category. Totally. Okay, and become the dominant category leader literally in two, three years. If I'm Geico, okay, I got business in the cloud because I got the app and I'm doing transactions on Geico. But with all the data that they're collecting, there's adjacent businesses that they can get into. Maybe they're in the safety business. Maybe they can sell data to governments. Maybe they can inform logistics and highway patterns. Roll up all the people that don't have the same scale they have and service them with that data and they get subscription revenue. And they can build on top of the Geico super cloud. Hey, Consumers Cloud. Right, yes, it's unlimited opportunity. That's why it's the multi-trillion dollar baby. So talk to us, you did an amazing job talking, which I knew you would. Why super cloud? What it is, the critical components, the key workloads, great examples. Talk to us in our last few minutes about the event, the Cube on super cloud, August 9th. What's the audience going to, who are they going to hear from? What are they going to learn? Yeah, so August 9th, live out of our Palo Alto studio, we're going to have a program that's going to run from 9 a.m. to 1 p.m. And we're going to have a number of industry luminaries in there. Kit Colbert from VMware is going to talk about their strategy, Benoit d'Ajaville from Snowflake is going to be there. A G written house of sky high security. I don't want to give it away, but I think Steve Mulaney is going to come on. Adrienne Cockroft is coming on. We have a lot of influence panels, we've got an analyst panel. Keith Townsend, Sanjeev Mohan will be on. So we'll be running that live and also we'll be bringing in pre-recorded interviews that we'll have prior to the show that we'll run post the live event. It's really a pilot virtual event. We want to do a physical event we're thinking, but the pilot is to bring our trusted friends together. They're credible, that have industry experience. To try to understand the scope of what we're talking about and open it up and help flesh out the definition, make it an open model where we can, it's not just our opinion, we're observing, identifying the structural changes, but bringing in smart people, our smart friends, and companies are saying, yeah, we get behind this because it has legs for a reason. So we want to zoom out and let people participate and let the conversation and the community drive the content. And that is super important to theCUBE, as you know, Dave, but I think that's what's going on, Lisa, is that it's a pilot. If it has legs, we'll do a physical event. Certainly we're getting phones and we're bringing out the hook for sponsors. So we don't want to gut and go all in on sponsorships right now because it's not about money making. It's about getting that super cloud clarity around to help companies. Yeah, we want to evolve the concept and bring in outside perspectives like John said. Well, the community is one of the best ways to do that. It's organic. It's an organic community where, I mean, people want to find out what's going on with the best practices of how to transform a business. And right now, digital transformation is not just getting digitized. It's taking advantage of the technology to leapfrog the competition. So all the successful people we talk to, Lisa, of the same company, I'm changing my game, but not changing my game to the customer. I'm just going to do it differently, better, faster, cheaper, more efficient, and have higher margins and beat the competition. That's the competition. Who doesn't want to beat the competition? Go to theCUBE.net. If you're not there already to register for theCUBE on SuperCloud August 9th, 9 a.m. Pacific, you won't want to miss it. For John Furrier and Dave Vellante, I'm Lisa Martin-Rogg. Coming at you from New York City at AWS Summit 22. We'll be right back with our next guest.


So I'm going to try if my webcam can work, but yes, it is. Apologies for the internet connection. Okay, so I want everyone to cross their arms, not because it's going to be a lecture or something, but it's an experiment that we want to try. So please cross your arms and this presentation is going to be very interactive. So I really want you guys to do what I'm going to ask you to do it. And before going to the next slide, I want you to tell me what do you think change means? I know everybody knows the definition, but if you can just write the definition in the chat, it will be perfect. So I really want everyone to write what do they think change means. Yes, with arms crossed. Okay, so there are very interesting definitions and opportunity for things to get either better or worse. So let's see what the next slide says. According to Oxford dictionary and accurate process through which something becomes different. So basically it's an accurate process. I am not trying to say that it's something that you guys don't know. Obviously, you know it, but it's just that we really want to redefine the definition of what change is. So now, again, I'm going to ask you to change your arms if you like to put your arms on your right hand on your left arm to do the opposite. So that we can see how do you feel to change the direction of your arms. I'm going to ask you in a while, how are you going to feel because then we're going to do another experiment. So before change management, I would like to ask you actually to recall when you were in school. In fact, I'm sure your parents must have shared these kind of stories that when you were in preschool, how did you feel when you were going to the school? Did you cry on your first day or were you happy? I am definitely sure that a lot of people were not happy and they were crying. That's the same scenario when you move from school to high school. Some people are really excited for the change. Some people are sad because they are going to lose their friends. And when you move from your college to professional life, how was it your first day in the office? Just think your first day. I'm sure a lot of people have not started their professional lives, but if anyone can just relate to it. Okay, so how about changing your phone? Have you guys changed your phone recently or in your life? What was the feeling? Were you excited? Of course, if you were moved to a little, I would say degraded one or a lower phone, then you must have felt awkward. But if you upgraded your phone, you must have felt really nice. Changing your house, changing your cities. If you would ask me right now, I've changed my house and my city, country, everything. So it's a very different change for me. So another change which I've felt right now is that I've moved to FOSS. And how did I feel about FOSS that was a topic, but just imagine that when you come to a new organization, it's very different, right? So if a new cover comes to KDE, try to imagine how that person feels, try to be me. How was the feeling to be part of FOSS community? Early when I joined, I heard about GitLab and GitLab, when it was migrating to GitLab, a lot of people loved fabricator and they really didn't want to move to GitLab. And I'm sure that it was an awkward feeling and it took really long for you to accept this fact. So why do we hate change? I would really want you to write that why do you hate change? So start typing, why do you hate change? A lot of people, these are not something which I am saying, but a lot of theories have said that people hate change because they believe that they are going to give up on their beliefs because they are really loyal to their beliefs. Do you remember your mother if she bought some brand and even your wife or yourself and all the females or all the gentlemen who have bought new brands of I would say food or clothes? You were a little nervous about it because you were used to your old brands because you were loyal to it. Sometimes you feel surrendered to someone, you really don't want to go for it. So there are mixed feelings, you feel feared, you feel guilty, you are in doubt.  So you really need to start thinking how can you actually change? Okay, right now I'm asking you guys, if you want to just don't want to cross your arms, it's fine, but I'm sure it must have been super awkward because change is here. Trust me, it's your mind, how you actually train it. So what are the benefits of change? Now we are going to move towards it. If we were talking about hate, now we are going to talk about change. So basically, if you think this is a very nice picture, if you see that change is basically a challenge. So it can help you promoting new skills. I'm sure a lot of people can relate here when we move from fabricator to GitLab to learn a new skill, you learn a new software, you learn a new environment. It helps innovation and it also allows you to progress. So when you are in such a situation, think about how do you feel when you are in such circumstances? Do you think that you are doing a right thing? According to this picture, these people are thinking that maybe something will happen and they don't have to change. But trust me, without change, you cannot move in life. This is a cycle of change. If something is constant and you will feel a dip and a transition and you will feel really bad about it. But then there's a new beginning always. And again, because change is not constant. Every time everything has to change and that's how the world is moving. So now we'll come back to the main point that how we are going to actually accept change. Accepting change is as I've just read the comments that somebody has written that you cannot actually think that changes are always better. I agree totally and I'm going to talk about that as well right now. So you need to acknowledge the change. It does not mean that you have to like, choose or support. Just try to understand what is the change? Why is it? And why do you need to change? Try to be flexible. Try to embrace it. As I said, change is constant.  You are going to change. You think that you are not changing. Trust me. You, as I told you that how your school life changed, how your professional life changed, everything is changed. So if you feel that you're not going to change, express it. Express your fears and the feelings. Communication is the key of success. So you really need to communicate. And I would say the best thing is to be optimistic about it. If from the beginning you're thinking that it's not going to work out, it will not work out. So you really, really need to have a positive feeling about it. You need to have a positive attitude. Also, you really need to understand that it's an active process. It's not something which we are going to just discuss right now in 20 minutes, and you will start doing it and you will learn change management, not at all, because it's actually a long, long process. It will go on and on. So you need to start changing your attitude towards experience, people, ideas. Okay. So that was a side where we talked about accepting the change. What if you are on the opposite side and you are implementing the change? So what are you going to do? First of all, you need to start with the end in mind. You need to think that, okay, this is something which we are going to do. Currently, we are talking about KDE. So if you are thinking to start a new project or if you have a new task, understand KDE's culture, understand the organization's culture where you're going to implement it, how people are going to react to it. Again, in this way, in this method also, you need to communicate, communicate, communicate. If you are not going to communicate the benefits to the people, they would never understand. I don't know if in your school it happened or not, but I remember my teacher, she appointed my most naughty, scared in the class as monitor because she thought that if he will be in control, the whole class will be in control. So if you think that somebody is there who's going to be the most resistant person, try to talk to him first so that he doesn't take the same attitude to others. So you need to take him in confidence, take him or her in confidence. And if you have some supporters, you need to understand their values as well and you need to, I would say, embrace them. Try to walk in their shoes, understand why they are getting changed. Create a win-win situation. If I'm implementing something in KDE and I'm just talking about KDE's progress, I need to talk about KDE community's progress as well. Just can't say that, okay, if you're going to bring this change, we will be shown over there or somewhere, but we need to understand how the community can also benefit from it. So the best thing, I'm sure the project managers with us right now would understand this, that any project is actually divided into small steps and it's measurable. So if you are implementing a change, you really need to do that. Now I'm going to share something really interesting with you. So what are you going to do right now is if you have a paper and pen, just start writing the changes in your life you have seen. If not now, then what you can do is that whenever you have time and you think someday or maybe in your life you're going to face a change and you don't know how to react. So you are going to use that candy jar and you're going to put all these happy moments in that jar and whenever you feel that you are not able to accept that change, you can just read it out. And trust me, this will help you and always remember that without accepting opportunities, slip away. So I don't know if you guys have heard about Kodak film case. Kodak was a top-notch company when we had film cameras but when there was an industry revolution, all the cameras moved to digital cameras and what happened, Kodak didn't react at that time and they said that maybe the film cameras will be the one in the world and it didn't happen. Completely gone from the market. They could have reacted in a different way. They could have launched memory cards. They could have launched anything else but they didn't. So you could see what has happened with Kodak. Similarly, same thing happened with Nokia. You have seen that Android has changed the world right now and Nokia didn't implement the needs and Nokia's market share has gone. So I think if you really want to understand why change management is important, you really need to understand I would say that you really need to understand the critical role of change management. So if you think that you really want to implement something, you can plan, you can control and adjust, do it. So create a stronger working relationship with newcomers. I know that including me, I would say Paul and Yopitas were really supportive and because of them, I was able to do it. Otherwise, initially when I joined as a newcomer in the FOSS community it weren't happening easier for me. So whenever a newcomer comes, try to understand they are coming from a different operating system environment. It will take time for them to adjust. It's easy for everyone to come to the FOSS environment because as I said, change is here and we have been using certain systems or certain processes for a very, very long time and moving, shifting to the process is not that easy. Secondly, the thing which is coming and is not good or beneficial for KDE or Community Express, it's okay. You really don't have to say that, okay, you don't have to implement this right now. Just try to understand that why this person is not reacting the way you wanted. So remember that the success factors of change, the person I would say is you and the person who is implementing. So the acceptor and the implementer both have to understand why change management is important. So in the end, I would say accept the things you cannot change and change the things you can because it's you, the one who would decide either you want to go for a new way or an old way. I think I have done my presentation pretty earlier. So if you have any questions, Allison, do you want to join? Absolutely. Thank you so much for that. That was really mind-opening. Thank you. Just trying to get my camera back on. Okay. All right. Okay. So we have a question and it says, as new to KDE, can you point one? Yeah. Can you point one thing you believe we should change in order to improve? Oh my God, that's a debatable topic. I think whatever changes I feel I have been sharing that now and then publicly, whatever I've felt, I have shared that in the promo group. I've shared that with everyone. So that's not something I can say one thing or something. I think as a community, KDE is impressed that we work all along together. So I really don't think that there's one thing I would say. I'd have to agree. And also, KDE. Well, I just said how diplomatic I know. We're just going to start calling Anika the diplomat. Yeah, it's okay. That's who I am. Well, if there's no more questions, maybe there's some in the public chat. Yeah. We get lots of great comments though. Yes, because I really wanted to keep it interactive because change management is not something which I can teach as a lecture. What change would you make to KDE? Yeah, that's a question in the comments from Jonathan. I see. Yeah. So I think right now we are working on KDE and I really want that to work out. And that's for you as well, Alison. Go ahead. Oh, put me on the spot. It's not my talk. Paul just said that. I didn't say anything. He's just written good questions for Alison too. So we have another question. Maybe some quick poll about the GitLab change. That we do. Up to you if you would like to host. Yes. Yes. So how are you excited or not excited? Let's see. Okay. So how do you change when it affects a lot of people like your community? Okay. So as I said that you really can't change something overnight. You really need to understand the dynamics of the community and you need to show them how beneficial it is for them. Not the way you perceive it, right? If you think that your perception is the same way it's not because trust me. The other person who's going to receive the change will not take it. So you really need to do it in a way that the whole community. And if you think that whole community can be happy, it cannot be. You really need to go with authority and you have to try to show them the positivity. I hope I've answered Adam's question. I think so. He can always answer or follow up. He says, yes. Okay. And if it does has a question for you too. He says, would you say KDE is accepting to change based on your experience so far? And the suggestions you made. What was your experience? Okay. That's a long question. So I would say that yes, I have seen a lot of changes. Like for Instagram, I've started posting a lot. There was I think the first change which I tried to implement. Yes. And I said that always you cannot be right. Like in my case as well. If I am saying that, okay, this is something which should be changed. Maybe I'm wrong. So I need to even understand that whether I'm right or wrong. So the other thing which I said is about KDE network and I was very happy that everybody was really receptive and supportive about it. So I would say my experience has been really good up till now. And trust me, it shows on my face. Even though I'm diplomatic, it shows on my face if I'm not happy. Alright, Adam asks, Anika, what is your hardest change? How did you handle it? Okay. So right now is my hardest change to be honest because I have, I'm living here all alone. My family's in Pakistan and I've changed my country. I moved from my family. So yes, it's the hardest change right now for me. And there was Corona. So I was all alone in this house. I feel you pain. Neha Kedav says, as a follow-up, I think, so we should be accepting to proposals for change as well. And Adam is sending virtual hugs. And so is Paul. Thank you so much. We do have time or are we done? We have a couple more minutes so we can answer more questions. I think that's like a really interactive session, trust me, because I really didn't think that it will end so soon. Although I had an internet glitch as well. Well, I think that's okay because everyone more time to interact with you. What do you miss from Windows? I never work for Windows. So yes, Windows operating system. I miss it of course because as I said, change is your right. So it's very difficult for me. I am in the transition phase right now from Windows to Plasma. So the only thing which I miss, Paul, you know, is that the mic thing because whenever I turn the mic on my plasma, it just disturbs me. So that's the only thing which I miss in the Windows. We have a comment that says you've been doing great on promo and that is something I absolutely agree a thousand percent. Thank you so much. Another question, maybe our last question. How do you gather quality feedback from those who are being asked to undergo a change, i.e. polls, focus groups, etc. Okay, so it totally depends on the community. If you think that your community is to be honest, receptive or intellectual enough to go for a focus group, you can go for a focus group. And if you think that polls will be much easier for them, so you can go for polls because see it depends. If you are from a technical side or a non-technical side. And if you're going to ask a non-technical person about technical in the focus group, it will not be easy. So you really need to understand. I wouldn't say that there'll be one exact measure for one community. You need to have, you have to see what are the limits of it. I hope that answers. I don't know. Let's see if Hudson sends anything. Yes, maybe. Does it believe so? And thank you. Thank you.


What is going on guys welcome back to the channel critical overlord here So we have an update on what we can expect regarding the release of Jeepers Creepers 4 and how it'll be released Into the public later this year in the fall sometime Jeepers Creepers reborn. We know it's being directed by Timo Viren Swola Whoever you pronounce that last name still probably pronouncing it wrong and we know that we have a new writer writing this script We know that Victor Salva's Identity of what he wanted to do for the fourth film is being scrapped and we're not gonna get that Even though those flashbacks of Trish would have been nice to see what she's been up to over the last 23 years But Timo Viren Swola while he's very tight-lipped. He does talk about things I guess he can talk about he can't release any spoilers of course and those of you who continue to reach out to him and send him messages Keep doing that But if they're watching this video most likely he'll he'll get even more tight-lipped at the fact that if they're watching this because I'm I'm sure someone in production with that film watches my videos I'm sure they do just because of the fact that I've reached out to a lot of them I have and I have the YouTube channel link in my bio. So Timo did talk to one of you guys Shout out to Jonathan who reached out to Timo to ask him a couple questions Asked him when of course could we expect a trailer for the film? He responded? I don't know yet, but hopefully soonish they asked again Is Jeepers Creepers reborn in the same universe with the first three films? he stated no spoilers and then the last question is it going to be in theaters or on demand his answer both So Jeepers Creepers reborn Jeepers Creepers 4 it seems like the intent the plan is to have the film released Simultaneously in theaters or on demand now. That's not what they said in there That's not what he said in his exact words He just said is it going to be in theaters or on demand he's saying both that could mean it could go to theaters first And then get released on demand shortly afterward or yes, like I said before it could have a simultaneous release in theaters and on-demand Now could this film being announced as a theatrical release put be a detriment to it? I think so what I think they're gonna do is they're not even gonna announce this until probably Short if they're real intent is to have this in theaters I think what they'll do is they'll make this a last-minute announcement I could see it happening. I could see Jeepers Creepers reborn going to theaters being the last-minute announcement They'll announce when it's coming out and say it's going to VOD, but they might hold off on that theatrical thing because then what that could do is Open up a can of worms potentially for again for those that want to still be upset about the franchise and its history and The tarnished reputation it has because of the creator. I get all of that But you know just announcing certain things that have to do with this franchise and a lot of other things that put people in a bad Mood or just upset people and get them all emotional It's probably not gonna be in their best interest to just flat out announce a theatrical release so early on because then that could lead to Unwanted protesting on their end because screen media getting in bed with this franchise They're not looking to of course have it protested. I don't think that's what their in-game is here They know they don't want to and spend their time Investing in this only for it to backfire But I think they're also well aware of what they're getting into giving how like I said before the marketing so far has been Kind of meh, they're not really giving us much. We don't know who the cast is We don't know any confirmation narrative wise from anyone involved in the film itself Just what I'm digging up and what you guys are digging up and sitting out to me Which again, we need to keep doing that because who knows when we'll get something official But the fact that they're saying or that Timo is saying that it's going to theaters makes me kind of excited because I do want To see this film in theaters. Hopefully it's a step up from what happened with Jeepers Creepers 3 again I'm not expecting anything overly good. I'm not expecting anything to be overly bad either I'm expecting this to be at least something. I can sit down and watch and not have too many criticisms about it Other than the the common things that I might have an issue with such as character development being rushed in many ways Maybe there's some odd Moments in the film, but nothing that would be overly illogical for me to complain about or something That's overly just mishandled with the production. I don't want to see anything like that I don't want this movie to be overly bad, but I'm not expecting it to be overly good I'm just expecting it to be a movie that will make up for the failures of three because three in my opinion is Yes, a overly bad film for countless reasons I don't want this out of this film Jeepers Creepers 2 like I've stated before I love both of those films Jeepers Creepers 1 and 2 I tolerate 3 I watch it when I want to sometimes when I watch this franchise, I don't even watch 3 but with the Jeepers Creepers 2 film that movie got a Well, none of none of these movies are rated fresh Iran tomatoes. I'm not mistaken I think the first one was but then that got dropped But the second film was a step in was a step down for of course what we got in Jeepers Creepers 2 But it wasn't an overly bad film. There was just some things Narrative wise words like okay. Well, why is this movie so confined to this tight space like this? We have all these kids none of them are getting really enough time to be fleshed out Whereas with the original we had this simple concept with two kids two young adults in college going home for spring break Got to spend time with them grow and develop a relationship and a connection to them want to see them Get out of this situation alive. Whereas with Jeepers Creepers 2 You had so many more things that were added in that it kind of took away from what what was working in that original film It's just the more you try to the bigger you try to go Usually with a movie such as what that first film was and you're trying to now do something bigger than that You're gonna lose out on what made the original so good and that's 10. That's typically what happens usually when people do sequels That's just what happens with films Usually sometimes you have films where they have sequels that outdo the original But I'm excited for it to go to theaters can't wait to see what happens with that can't wait to see if this theatrical release is a Success that's the biggest thing. I'm curious about if it's an actual success because if it's an actual success then the creeper really is back and Again, I'm just not expecting this movie to be something that's gonna blow blow the first movie out of the water or even the second I'm hoping that when I sit down at night, I can say I have a decent trilogy on my hands I have a phenomenal first installment and even that might be a little bit over praising that film. I have a Decent second entry and I have a now watchable fourth entry and I'll skip over the third film until the day I die That's obviously a joke. I'll watch Jeepers Creepers 3 when I feel like it But most likely after this fourth movie is out if it's decent enough I'm not gonna watch Jeepers Creepers 3 for quite some time But let me know what you guys think about Jeepers Creepers 4 apparently being released in theaters Are you looking forward to that? Will you see it in theaters? Do you think this will turn out bad for screen media and those involved with the film? If you haven't already make sure you subscribe turn on post notification in this video in the description I have links to my social media accounts on my Facebook Twitter and Instagram you can message me there Of course there isn't any movies news or reviews you'd like me to cover in the future right in my guys I will see you in the next video


Who says you can't have it all? Not Appalachian Wireless, we know what you want! Appalachian Wireless offers the hottest smartphones and unlimited data plans, all on the region's number one network. The fate of the Martin County Sheriff's Office is uncertain at this time. In the Martin County Fiscal Court's latest budget, the Sheriff's Office is not listed. According to Sheriff John Kirk's Facebook page, the Sheriff's Office has turned over all of its fees to the fiscal court, and it won't have any money to start out with in July. Judge Executive Kelly Callahan told EKB News Wednesday the court is repealing the fee-pulling ordinance because the court no longer has the cash flow to do so. He will be in full control of his office. Sheriff Kirk's post also states, unless the department is able to get an advancement from the state, the Sheriff's Office will have to come up with $80,000 on its own. He says if there's no money, there will have to be cuts to the department. Judge Callahan says the court has offered to give money allocated for upcoming HUD projects to the Sheriff's Office. Callahan says much of the budget is mandated by state law. He says the court has also made cuts in the past in order to keep the Sheriff's Office up and running. Law enforcement is very important for this county. We got a lot of drugs and stuff. He's the elected sheriff, and that's what his elected duty is, other than clack taxes and bail of court. It's law enforcement, and if he fails to do law enforcement, the county will have to take other measures. Beyond eight Kentucky state police troopers stationed in Martin McGuffin and Johnson Counties, the Sheriff's Office is the only law enforcement offered in Martin County. Sheriff John Kirk declined an interview. In Martin County, Shelby Porter, EKB News.