Plenary session
Tuesday, 9.8 May 2017
At 4 p.m.:
CHAIR: We are going to start the last session today, and we are going to start with the Programme Committee nominees because we have two seats available for election, and the form for voting is up, and here we have Benno aiming for re‑election, Seán and Franziska should be here. So you have a few minutes.
BENNO OVEREINDER: Thank you. I might be familiar face, I am running for my third term, another two years. I really enjoyed the last four years with, well, making plenary programme and interacting with the community. A little bit of background: I am working with NLnet Labs, small research not for profit research and development company, mostly known for the DNS and as such we attend RIPE meetings, IETF for the standardisation process, and sometimes ICANN for reaching out. And we do also some applied research, and that is also what I want to bring back to the RIPE meetings on stage. Infrastructure, DNS routing, everything is also ‑‑ has my interest. And I want to contribute that to the plenary programme for another two years.
SEÁN STUART: Seán Stuart, I am a less familiar face than Benno, I am working at Verisign, currently running peering coordination and finding homes for additional route servers. I have been doing networking both enterprise and service provider for most of the last 20 years, was on Programme Committee for the DNS operations and research council for three years. Enjoy doing the networking side of things, the DNS side of things and am getting sucked more into the Address Policy now as well. So a little of everything and I look forward to helping shape the plenary for the next two years.
FRANZISKA LICHTBLAU: Hi, I am probably the newest face as I am only around in this community since 2013 but I have been active for more than last ten years in the free and OpenSource software community and we are also collaborating with a lot of people do conference organisations and content selection. On the other hand I am a researcher and my focus is on network measurement particularly on the interconnection and inter‑domain world and why am I running? Because some people actually suggested that I should do that but more importantly is I got a lot of very valuable feedback from my personal and professional background over the last year and I would love to give something back. With the background I have from the research world I think I can bring some things together and apply some of the things that are done in the research world on the operational perspective and maybe we can all learn something of it.
CHAIR: Thank you. And now remember to vote 1 or 2 or 3 of these lovely people. We are beginning with a session with seekers, and Joao Taveira Araujo is going to speak about addressing IPv6. Thank you.
JOAO TAVEIRA ARAUJO: So, this talk is actually only incidentally about IPv6. I hadn't really come to the RIPE community but I figured out that putting IPv6 on the title was actually the best way to get your talk selected. So, what this talk is about is addressing an architecture as applied to a CDN. So really it's like a deambulation as to how you design a CDN, I am not going to pretend what I am going to talk about is the best way of designing a CDN because that will ultimately fend on your use cases, I believe that many, many different ways of designing a CDN and I am pretty sure they are all absolutely terrible.
So, I work at CDN called fastly. Only thing you need to know about that is it was started many years ago by some Swedish dude who thought it would be easy to build a CDN because, you know, what is a CDN? It's just like an http reverse proxy, a TLS terminator and some BGP routing software, not really hard. So he booked the flight from SFO to LHR to set up the first fastly POP and because all the initial customers were based in Europe and he checked in the equipment as luggage, so this goes to show that building a CDN is easy. It may be borderline illegal but it's certainly easy and when we started out, we started with a very traditional model of a CDN, we started by using a Unicast model, most of you when you think about CDNs you think this is how it works so you have clients, you have points of presence, each point of presence will announce an individual prefix, and DNS will hand you out an IP carved out of one of these prefixes and the network will to the rest, right? So when you are starting out, you want to be IPv4 conservative because it costs money so the least you can get away with is a /24 which is what we did. How a /24 is 256 addresses, you will want to assign some to the equipment you actually have, the rest you can kind of assign to VIPs, what is what we did and these are ECMP across caches, the upper/25, right. It turns out this is a terrible idea because if you are ever attacked on one of those VIPs, effectively as an operator you are reduced in what you can do to respond to the situation, because if you were to withdraw the /24 all of a sudden your host just dropped off the face of the Internet. So 2013 or early 2013, things weren't too bad, we had fate sharing and we were kind of damage with the poor fallback properties of Unicast, and then we had this kind of time bomb in the background, /24 will not be enough but that wasn't a given so all good. At this point we need an Anycast network and the primary product reason and CDN needs an Anycast network is to support apex domains, and also to eventually at some point do in‑house DNS thing right? So, early 2014 we started doing Anycast, and this is easy enough, right, you announce the same prefixes, DNS for some records will return an Anycast IP network does kind of the right thing, maybe, except every now and then it decides there is a much better route somewhere in the completely opposite direction. And you end up somewhere horrible like Sydney. And fundamentally by 2014 it was clear that Anycast is kind of impossible to get right. With a lot of fine‑tuning you can get close, but always somewhere in the network which you don't really control. And if you are an Anycast operator and you deeply care about your customers' traffic you are kind of depressed or deluded, and so the fundamental problem is inbound path control in general is really hard, even if you happen to get the right POP it might come through some really long weird, long winding path, so and at the same time all of a sudden there is a CDN, we have this operational overhead of having to run both Anycast and Unicast models concurrently and think about the burden of having to reason about what the fallback properties of each is. At the same time as all this was happening we were growing so we had 16 caches at some point, we had enough customers that we had to assign another/26 in this block. By 2015, we had 32 caches per POP and space was getting tight and the time bomb was becoming an issue by 2015. At which point our product team helpfully points out we should think of doing IPv6, which given all the other problems, was great help. Now, the good news at this point is we didn't really have any first mover advantage, at least two of our competitors already offered IPv6. There was also like incredibly limited demand for IPv6. I know it might come to a shock but outside this room no one cares. And in the CDN context in particular the things customers care about is stuff like cache hit ratio, instant cache invalidation, realtime logging stats, the ability to manipulation requests at the edge, the very few customers who care about address family were already on other CDNs and it turns out it represents such a niche market it was neither affecting our attention rate or our growth, effectively. And so we had a luxury which is we didn't need to rush it, so instead of developing a product of sorts we actually went about trying to fix all the problems we had, right? And the first problem was very easy to fix, because it was a problem of our own making, so fundamentally in our context we have two types of addresses, and therefore it makes sense to allocate these from completely different prefixes. Effectively we have VIPs which provide a one to many mapping, it doesn't matter what host you end up in, all you really care about is that you get a reply. And so effectively these are service distractions. On the other hand we have infrastructure IPs, you know, which is just traditional host addressing which is a one‑to‑one mapping to an actual physical end point. The fallback properties of these are different because you always want to end up in the place same place. By allocating VIPs from a completely separate prefix set than the infrastructure IPs we at least get raid of the fate sharing between address types. The next one is a bit more complicated because effectively there are good and bad things for both Unicast and Anycast models, really Unicast is the only problem is the fallback properties especially if you drain Unicast prefix and you have to wait for DNS TTLs to expire and some resolver is going to hang on to it because it was told to do so, on the other hand Anycast is just complicated, control and in a study state environment but it has nice for giving fall back properties. And ideally you want a combination of both but you want the control of Unicast with the fallback properties of Anycast. So early 2015 we started implementing a backing Anycast strategy and this is simple, you have an Anycast prefix which you announce from every POP and you subnet a Unicast‑like prefix from this Anycast prefix. Now, this isn't Unicast, you know it's only announced from a single location in the network but we can actually reannounce it from elsewhere. And so same thing happens, DNS, DNS, like, routes to Sydney, I guess. Now, the nice thing about this is if you get DDoS or have a problem you have options as an operator, the obvious one being you can just remove the more specific route, and the nice thing about this is that once you are falling back on to Anycast, local traffic will probably still end up in the local POP, whereas obviously DDoS traffic might actually go to a closer route and get pulled into a different POP, because no DDoS traffic has ever been started in Australia. You can kind of get the nice properties of both addressing models, which is nice. Still doesn't really fix the inbound path control because the backing Anycast solution I just presented pings you to a specific POP, it doesn't really tell you what the ingress is going to be. And so here we have to break things down by effectively address type, and I am going to present the VIP case first. And what I am going to present is just an extension of the backing Anycast model I just presented. So imagine an extremely large address space, right, con and conceptually you can think of it as geometrical space, in practice think of it in IPv6, a /32, which is what we use. This space is just the global backing Anycast of all the things. And you can start subneting this. You can start subneting it by /36, which is what we happen to do, but and so the first /36 you hand to everyone, the next /36 you hand to only a single provider, so this might be cogent, then to say Level 3 or Telia, from here you keep subdividing further. And so you start having these groups like a group notionally associated with Frankfurt and Sydney and LAX and say Asia, so this is prefixes that would be announced from every POP in Asia. So notionally they are associated to POPs but really more generally these are just arbitrarily constrained Anycast groups.
Now, going back to the example, things back bit more complex from a management, pure management perspective, in the sense instead of the two prefixes from the backing Anycast example you now have a lot more to deal with because you have to contend to which prefixes you announce to which providers. But the nice thing is, from a DNS perspective, we can actually pin to you a Frankfurt via a specific ingress. And the beauty of this model is that it actually handles most of the failure scenarios we normally run into, if the Frankfurt POP fails that IP is still valid, it's just ending up somewhere slightly different. Likewise if a specific provider has an outage you would fall back on to the global Anycast so it's just rerouting.
Now, when do you fancy addressing stuff in v6 you have to think about the global routing table, otherwise one of you will march up to the microphone. And naively you could think of this as being the multiplication of the number of IP groups by the number of provider planes, so to speak. But in practice, only one of those planes is actually provider‑independent, so those actually have to make it into the global routing table. The rest you can actually set no export to, at least on the more specifics because they are only going to be consistent within a single provider, and so the view from the global routing table is that you will get a single plane where you have the more specific announcements and everything else is a /36, so if you look in BGP routing table you will see that fastly appears to be I think if he will homed behind some providers for some of these /36s. And so the actual impact on the global routing table is the number of VIP groups plus the number of provider planes. Which is actually a very compact representation of something that provides you an immense amount of flexibility. So just to complete the formation of the v6 address, if you are a CDN you can think of our services being domains, this gets kind of hashed or mapped into a 64 bit service identifier, so an alternative way of thinking of our addressing scheme, it's just the projection of a 64 bit identifier on all these concurrent parallel addressing planes, right? So, that kind of explains how you might have ingress path control on the VIP side. On the infrastructure side things aren't quite as easy. So, infrastructure ‑‑ from a CDN perspective, once you have handled the front end part which is client traffic you fundamentally have the most brittle part of the entire architecture which is origin pull because you have pull content from customer servers effectively over which they have no control over routing, right. Lots of these ‑‑ lots of content is going to be hosted either on AWS or GC P or just managed by people who can't Internet. And the way you can deal with this is a similar premise to the VIP model, except you have to be careful because your fall back strategy here is you must always end up on the same physical location. And if you have an outage of a provider you effectively have no control over what route traffic is actually taking towards your POPs as you are pulling content down. So, similarly though you can have a route infrastructure prefix for that particular POP, and then you can subnet it and just give it to individual providers and then you can actually use source address selection on the application side to pin traffic through a specific provider. Now, in terms of impact on the routable table this is not quite as nice as VIP case. Intuitively, it's going to scale with a number of POPs because every POP needs an infrastructure prefix. Fastly uses a /40, and then in each POP you can have up to 16 different/ ‑‑ 44s, and so the total number of announcements comes down to the sum of the number of providers across POPs so it scales kind of poorly. If you are a CDN which has a tremendous amount of POPs around the world, this is kind of not a great property. Fastly specialises in the opposite model: We have a smaller number of POPs with a lot of storage to control this sort of stuff provides us. Now, having fixed the inbound path control, you still have the overheard of running concurrent models, and the fact that we still haven't solved the IPv4 problem, we have just been talking theoretically here. So from an operational perspective one of the things we did is that every one of those prefixes or locateers that I showed you has a name so you can think about the global aggregate backing thing as just the VIP and for the provider you might have ntt.vip and for the provider independent prefix. And then all the infrastructure prefixes are routed on the infrastructure space, so you might have a frankfurt.inf or peering.frankfurt, which infrastructure prefix we only announce over settlement free links. And so if you look at our BIRD configuration examples, one of the ways you can actually manipulate policy is by matching against a locator name on the route, and this is nice because the name actually embeds a hierarchical model which maps to the subneting, the nice thing is you can do globaling to match the subnets downstream from a particular prefix so effectively as an operator you don't have to think about the prefixes or even the address family; you just express policies as derivations of the address plane. And in general, our approach is kind of weird because we started with this completely ideaised addressing space which just happens to be ‑‑ in IPv6, and we then just back ported functionality to v4, basically because every prefix or locator has a name, you can then map names to prefixes, so it doesn't really matter ‑‑ you don't have the mental burden of having to think of what IPv4 prefixes match to anything. And this is kind of important because had we worked in the opposite direction IPv4 space is so fragmented you can't even reason about it. And going from that point to v6 we would have just carried on with all the constraints we currently have.
So, in summary, we kind of went through the process of decoupling address types, for each of those address types for the VIPs and infrastructure, you have completely graceful fall back. For the VIPs we also gain like prefix mobility so we can reinject prefixes from other locations in our network on demand. The really nice property we have which I think is kind of unique right now is that we do have fine‑grained inbound path control in v6. And perhaps more importantly, we ended up with a unified model based on naming, but which reduced our network basically to a very small set of fundamental statements from which like a massive amount of consequential ones can be systematically derived. Disadvantages: It takes a hell of a long time so I am not sure I would recommend this to anyone but we will see.
Now, if any of these ideas sound cool, none of them are mine, I just cribbed them from somewhere else, so I have to give credit to a few research works in the past, one of them is the identifier locator network protocol, multipath TCP, and finally there is some stuff called reEC N, and obviously fastly did not implement any of these protocols because that would be crazy. But we do grapple with a lot of the fundamental questions they raised. You know, how do you support mobility, multi‑homing and inbound traffic engineering in a scaleable manner in a routing architecture, a well layer of the networking stack, do you support resource pooling efficiently. And more subtly, how do you avert the economic effects of information asymmetry in connectivity markets. And obviously we haven't solved any of these problems. But they do kind of form the guiding statement for most of our network architecture, namely the locators exposed path diversity which is what I briefly touched in this talk. Fundamentally you are ‑‑ pulling in transport and application layers. And ultimately, the end goal is to use end‑to‑end metrics to drive path selection. And when I was composing this talk I realised because it's RIPE, I should point out that all three of these are EU research from about ten years ago, and it blows my mind that fastly, despite using EU research, despite the fact that all the consumer demand was in Europe, despite the fact we used a Norwegian reverse proxy and French TLS terminator and Czech ‑‑ the founder is Swedish and all our lead engineers or most of them are working from home based out of Europe, somehow fastly is very much an American company, it's astounding to me. And I can't for the life of me figure out what it is about this place that makes it so unconducive to materialising its own ideas. What I do know is many of you are actually industry partners in some of these projects and honestly, I don't know how much of the ideas you actually make, you make use of. And that tells me two things, right: Either the questions simply do not matter to you, in which case we are better off haggling over peering in the corridors; or you fundamentally believe the ideas do not work or that they are not worth the risk they entail. In which case, I guess we will find out. Thank you.
(Applause)
ONDREJ SURY: We have a couple of minutes for for questions.
AUDIENCE SPEAKER: Charlie from yell.. do you find you have been able to more smoothly architecture your path selection with v6 that your v6 platform laugh smoother operating history, for instance, when large providers go down?
JOAO TAVEIRA ARAUJO: Eventually, yes. Eventually.
AUDIENCE SPEAKER: Maybe that is a case for the customers to start giving a shit.
JOAO TAVEIRA ARAUJO: Yes, that is good enough.
ONDREJ SURY: So no more questions?
LESLIE CARR: Leslie car, SFMIX. Do you use your v6 routing for ‑‑ what is the reason, latency, cost?
JOAO TAVEIRA ARAUJO: I would say control and everything else derives from that. So, how can you control ‑‑ how can you have good performance on something you don't actually control?
ONDREJ SURY: Any more questions? Then, I will have one. IPv6 only, was the plan, I know there is a glitch in DNS.
JOAO TAVEIRA ARAUJO: Yes, yes. I think that is a /TKAO*UR ticket somewhere and it's not sent to me so I am fine. It's actually have close. We have some issues just passing things on to DNS Anycast right now, but, yeah, that should be resolved within a month, probably.
ONDREJ SURY: Cool. So thank you.
(Applause)
So next one should be Friso Feenstra, if he is here.
FRISO FEENSTRA: Thank you. Very first I would like to appreciate ‑‑ express my thankfulness for you having me here. It's my first RIPE conference, and I am feeling very honoured that I am given the opportunity to speak here to you. I was very enthusiastic when I got ‑‑ when my presentation was indeed approved, and when I got this ‑‑ when I told this at home to my wife and my kids, unfortunately my eldest son gave a comment saying, wait second, dad, what ‑‑ when is your presentation coming on? And I said, well, I am on the second day. Oh oh, and when on the second day are you? Well I am at the end of the second day. Oh oh. And then he said where on the end? Well I am the second presentation at the end of the second day. He said, well, don't worry too much, everybody will be asleep. But that gave me a good idea, I thought, well, let's do something about that, that is why I brought from Netherlands some mints, and I form have got my good friend Sander Steffan and I will put them in a bowl and ask him to hand them out, so at least you will have something fresh to keep you awake again.
(Applause)
Now are the presentation, Rabobank, that is where I work. It's a commercial bank, we are for money. And we did implement IPv6 partially, we have implemented IPv6 from our external facing websites, you can start ‑‑ they are passing it around, good ‑‑ and this is, my presentation is why did we do it. In 2014, already some time ago, there was an investigation asked for me to investigate, is IPv6 necessary for our corporate websites? And is it needed for our internal websites? Two elements distinguished. My expectation of my investigation, the answer would be no. Why? We have got internal private IP space, we have got 70 million private IP addresses, we have got 8,000 ‑‑ 12,000 employees, that should be enough. Internet for office, going to the Internet, we are doing NAT, migrations cost time, we have got enough external IP space, we have got a /16, so no problems there. And let's face it, migrations are risky, so should we do this? Still, it was given to me a project, are the reasons for IPv6 for the Rabobank? So I put myself these questions: What is going to happen in the near future with websites, third parties, customers, and if we stay on IPv4 for, say, the coming five, six, set, ten years, will we miss anything? Can we postpone the whole migration stuff so that other parties can get the experience, that bugs can be solved, that we at least have more time, time is precious, we are a bank and specifically that that best practices can be developed. The first thing, websites.
Currently, no problem. At this moment there are no websites relevant for Rabobank banking that will be reachable ‑‑ all websites are reachable for IPv4 for the coming years. But then I had the question what about financial websites in countries with little IPv4 space? So, for instance, in Uganda or Singapore or India, a rural bank, we like to start developing in those countries, what about that? Ah, well. Third party connections, no problem, we are doing a lot of NAT or we use a proxy in the DMZ and that is a little bit of IPv4 space, no problem. And the third one: Customers, well our customers are connected through our Dutch ISPs, KPN, Vodafone, all that. And those ISPs, they have enough IPv4 space for their existing customers, existing customers, right. But what about new customers? What about new networks? Well, Dutch ISPs, and I assume that counts for all countries, are expanding, G3, G4, maybe G5 networks, wi‑fi networks, new areas, mergers, you currently see that a lot of these ISPs, at least for the Netherlands, are using NAT, IPv4 NAT as a solution, which is an expensive solution, carrier grade NAT, not all customers like ‑‑ how are my mints doing, by the way? Gone? Good. Are there still enough? It's not enough mints. That is the same problem we have with IPv4. Come on. Bring out the IPv6 mints. And people, don't be afraid, there are enough IPv6 mints so you can have dual stack, you can use both mints. Have everybody doing dual stack with mints this time. You can see a lot of ISPs are now going dual stack as well in the sense they are giving IPv6 out and then IPv4 with NATTing because the alternative would be to buy a lot of IPv4 space and the ISPs don't like that, not at the current price. And for that IPv6 with IPv4 NAT that is very good option for them because most of the main content is available on IPv6, so if they do it, deploy it like this a lot of traffic will go IPv6 and they only need very limited amount of NATTing on IPv4. So, the expectation was, most providers will go for the bottom option. But for the Rabobank it means more and more customers of our customers will be behind NAT. The question, is that a problem? That is why I asked in the bank is it a problem for us if most of our customers are going to come behind a NAT constriction, an IPv4, if you don't go to IPv6 most customers will be behind an IPv4 NAT constriction, is that a problem? Security operations says yes, it's a problem. We very much depend on having an ‑‑ a traceability of IP addresses. The IP address is very clear for most of our security protection schemes, one of the things we were doing, if too much junk came out on one IP address they would block that IP address. Now, that is of course fine if there is just one customer behind that but when there is about 2000 customers through NAT construction behind it suddenly you are DDoSSing your own organisation.
Another department responsible for financial and economic crimes said yes, we need those IP addresses, the IP address where the traffic originates from is a crucial part of tracking customers. If you always do your banking from home and you always have one specific IP address and suddenly it's coming from all different IP address and big sums of money are transferred from that IP address then there might be something wrong there. The original IP address is something they very much use in terms of protecting against phishing and all that, and virtual channel monitoring, which is a department within FEC if more than 15% customer traffic is behind provider NAT that is not acceptable for us. Then I said ah, that is good, now I have a big reason because we are a bank and not going for IPv6 is now suddenly a security risk. And I have heard questions about how does it work. Banks are normally very conservative, yes, we are conservative with introducing new technologies but not if it comes to security. I can explain to my superiors in the bank that not going for IPv6 is a security risk and that is why we implemented the IPv6.
The next one: If we stay on IPv4 will we miss something? Oh, that is a good one. And my reasoning there was, there will be, in the coming years, features, applications, websites, that Rabobank needs that are IPv6 only, that we are sure about, the transition is going to happen. So there will be features in, for instance, oracle or in see ball or Microsoft share point, there will be features which will only run through IPv6 and the question is, when is this going to happen? When will we know? And how much lead time do we have? And will that be enough? That is my expectation, that these IPv6 features are relevant for the Rabobank will come in play somewhere between 2018 and 2025. That is a a nice over all indication, somewhere along that line. How much lead time will we have? How soon before that will, for instance, oracle say, well, we are going to have this feature but it's only in IPv6? Well, these type of feature announcements tend to happen something like six months or most optimistic, you would know it a year ahead, we are going to have this feature and I am sure you want to use it, by the way it's only running on IPv6. Is that enough? If is one in six month and a year, is that enough lead time for an organisation like Rabobank to start implementing IPv6? No, definitely not. I have done some investigations last year on how long will it take for Rabobank to start move over to dual stack and the expectation currently is around four years, so if it's four years before everything is dual stack and suddenly the business comes aalong and says we need this feature or have to access this website and it's only going to be IPv6 and I have to tell the business, well, very good, we are going to work on it, please come back in four years, then we will have it finished, that is not where I am going away with. So that is why we decided that Rabobank will have an IPv6 project programmes, actually we have two, the first one is external facing IPv6, started in 2015 with my friend Sander Steffan, IPv6, it is external only, so the whole internal stuff remains nicely on IPv4, don't have too much changes at the one time and it was at that moment a known technology for us. We had multiple departments involved, it was not a network problem, it was not a network thing. We had the security operations centre involved because suddenly there would not only get security problems on IPv4, they would have security attacks on IPv6 as well. We had VCM, virtual channel management, doing the analysis on incoming traffic. They were included. And of course, on the network side we had the whole tooling team, the whole tooling team had all the tooling done on IPv4, suddenly they would get a lot of messages, incoming messages on IPv6 as well. So all these departments had to be involved. Now, in a bank that is very normal to be very problem thing, only this time as I could explain that this is not a network project, but it's a security project and if you say security project in a bank, everybody has to agree and everybody has to cooperate, because it's a security risk. It's a nice one. Every project, every department had its own project and on top of that we had a governance project to check on communication and on time‑lines and we have finished this project, so if you now go to www.rabobankbank .nl you will see that it's available on your ‑‑ on IPv6 address and the whole banking ‑‑ sorry, if you happen to have a Rabobank bank account you can see that all the banking applications are now using IPv6 as well.
Next to that we have an IPv6 internal project designed, it's supposed to be starting this year. It's always tricky, projects that are supposed to be starting. I am optimistic, though, that it will it be starting, and it will have three levels, three plateaus, three levels: Networking, platform and application. First we will start getting the network to do dual stack, then platforms, hopefully in a controlled way we will go to dual stack where there is a problem with Microsoft because as soon as Microsoft servers sees IPv6 on network it will automatically go IPv6 so in the Windows side we have some challenges there, and then on the application level, and hopefully by the time the application start using IPv6 this is the way we can gradually migrate to dual stack. The target is network and platforms all dual stack and applications, IPv6 if possible. Now, here is a little bit about the topology we are using for our external facing websites. Here you have got the Internet IPv4 and IPv6, we have the Internet facing part of our network called A K, external connections in Dutch, doing IPv4 and IPv6. We have our DDoS mitigation control boxes and our IP DS boxes, capable of doing IPv6. There, all traffic is still encrypted because, it's all SSL towards the Rabobank. Traffic hits the external load balancer, which is doing IPv4 and IPv6, and it does SSL decryption, offloading, so after that we have unencrypted traffic for the rest of the network. Since it's unencrypted after that we can do content inspection ‑‑ sorry, it should be showing this. It's doing IPv6 deencryption but the intent is that the elements behind that will be able to use the original IP addresses, so behind that and specifically after the internal load balancer, we still have IPv4 so that all our internal websites would do IPv4 only. But to ensure that the original IP address which is very important for financial crime tracking is included, we include the original IP address in the http header using RFC 2739 for IPv6 and X forward for IPv4. Then, do the content inspection, internal load balancing and then the content processing. Now, this way, IPv4 and IPv6, the actual load balancer ‑‑ balancing and the cookie processing is done on the internal load balancer and the good thing about that is that if you have a session coming in from a customer, the Internet, he comes in, for instance, on IPv6, thank you, because his home network is on IPv6, he is working with his mobile doing his bank transactions, with his mobile he walks out to the garden because his wife asks him something, he loses his wi‑fi connection, he switches back to GPRS or G4 network, and switches back in that sense to IPv4, so it's switching from IPv6 to an IPv4, but since both are terminated on the same load balancer, through cookies, you can still track him, that is is still the same user so he can just go on banking with his banking application and he doesn't have to sign in again. So that is why we have the internal load balance where everything comes together. Clear text. And the inspection, if you can see there, that is something fishy is going on, the content inspection triggers the IP DS defence so that specific traffic can be blocked on the front.
Any questions?
JEN LINKOVA: Two questions: One standard question which I couldn't resist asking. What was your main, most biggest issue when you were doing this? What was the biggest challenge.
FRISO FEENSTRA: Getting all the departments lined out and working on the same project and in the same direction.
(Applause)
JEN LINKOVA: Thank you. I ‑‑ anyway, I for got my second one.
AUDIENCE SPEAKER:
JAN ZORZ: Internet Society. Jen stole my question but anyway. I would like to thank you for coming public with this presentation. I wish more enterprises that deploy v6 would come out to these meetings and share the experience, and especially now when the IPv6 boat is over the edge and rolling down and we cannot stop it any more, apparently, to actually share what were the issues and how you solved it so we need more of the enterprise deploying IPv6, here is the problem definition and here is exactly how we solved it. So, thank you very much.
FRISO FEENSTRA: You are welcome.
AUDIENCE SPEAKER: MAX, the question is quite practical because I am looking for new ‑‑ for one of my company. Do your Internet bank fully functional under Linux environment?
FRISO FEENSTRA: I don't completely understand the question.
AUDIENCE SPEAKER: The question is, if I use my Linux laptop for Internet bank, will it work?
FRISO FEENSTRA: Yes.
AUDIENCE SPEAKER: Thank you.
CHAIR: Wave question.
JIM REID: Speaking just for myself. I would like to amplify the comments that Jan just made, I think it's great and wonderful we have somebody coming from enterprise to come and explain his problems, it's great we get that. I think it's also very important we get the understanding not just about the problem statements and the issues that an enter prides has in deploying v6, I think it's also very good to get information about the business drivers, what was the business notification, the business case for actually going ahead with the v6 deployment and the migration issues, I think that is a very, very important, so thank you for doing that. My question is, though, did you try to get any kind of metrics on IPv6 usage from your end customers, I am thinking, say, for example, the people that had smartphone apps that were doing their on line banking that way, would you be able to Colette data to say if those cuss hers had IPv6 capability you could have had an end‑to‑end IPv6 connection with you if you had an IPv6 website or whatever?
FRISO FEENSTRA: So you mean before we started it all? Or do we have metrics before we started the migration or do we have metrics now.
JIM REID: Before or now. Obviously you have it now because you have got some v6 capability, I think it might have been useful before the project started to have some kind of indication that if we had v6 capability facing the public wave reasonable degree of confidence that X% of our customers will be able to reach us over v6.
FRISO FEENSTRA: We did have a query to both the major Dutch ISPs being KPN and Ziggo, part of liberty global, and both ISPs said that they had plans ‑‑ plans for the coming year of rolling out IPv6 with dual stack over their current networks. So, at the moment the project started the amount of IPv6 on the Dutch network was about 4 or 5%, but it was the expectation that by the end of the project that would have risen to something like 15 to 20% and I think that currently that is also around about the percentage of IPv6 traffic currently coming into the Rabobank.
JIM REID: Thank you and thank you very much again for coming here.
FRISO FEENSTRA: You are welcome.
AUDIENCE SPEAKER: Maxim, is it possible for your customer to limit access to Internet bank for one or several IPv6 address through the website, for example?
FRISO FEENSTRA: I am ‑‑ can you ‑‑ if ‑‑
AUDIENCE SPEAKER: If I am your customer can I log into Internet bank and set only access for this particular IPv6 address, is enabled or are there other IPv4 or IPv6 address also fail to login?
FRISO FEENSTRA: Whether you want to limit your own IP addresses for entering ‑‑ coming to Rabobank, is that ‑‑ you want to limit your source IP addresses or do you want to limit the Rabobank IP addresses?
AUDIENCE SPEAKER: So, I want to limit my IP addresses, I can log into Internet bank, for example, one IP address of my home, one of my office and that is all.
FRISO FEENSTRA: I think that is something you have to do on your own network.
AUDIENCE SPEAKER: No, no if somebody with my correct logged in and password tried to log from IP address, for example, from China, it will fail, is it possible?
FRISO FEENSTRA: That is not something currently in our standards, and not something we are doing. We are monitoring where login actually comes from and that is the financial economic crime department who is doing that. And unfortunately, these departments, although I have worked very closely with them, they are very hesitant on sharing information on how exactly they are doing this type of filtering which of course I can understand.
AUDIENCE SPEAKER: I understand. Thank you.
AUDIENCE SPEAKER: Lee Howard. You said in one of your early slides that you have /16 of public IPv4 address space. Did you look at the value of that address space and have you considered selling it, would that fund some of the effort of the transition?
FRISO FEENSTRA: We have looked at it and we anticipate that we will keep it for the coming years and so for the coming years we will not go to IPv6 only. There is still too many customers on IPv4 that we want to serve specifically in lot of areas in the Netherlands that don't go that easily to it IPv6.
AUDIENCE SPEAKER: I guess I had assumed would you only sell a portion of it and do the rest in translation, but I think you have answered my question, thanks.
CHAIR: That was the last question, sorry we don't have time for more. Thanks for your presentation.
(Applause)
And so our next speaker is Stephanie Wehner, she is going to talk about quantum Internet.
STEPHANIE WEHNER: Thanks for staying until the end of the afternoon, I am going to something which is rather more futuristic, namely the quantum Internet, and in particular it the efforts to realise one in not too long ago, in a very small prototype implementation, I would like to thank the organisers for being here because I am not from the RIPE community but I would very much to reach out to you because you can imagine that just like on the classical Internet a quantum Internet requires all kinds of control protocols so if you are worried about IPv4 V IPv6 this is the wild west, there is no Q IPv one, and as you might imagine those of you what care about these protocols maybe becoming involved early means that later one does not need to convince people to switch from v4 to v6.
So let me I guess give you actually some idea of what you should maybe think about where quantum Internet is right now. And I guess for this community it's probably quite obvious, but I want to ask you what happened on the 29th of October in 1969? Does anybody know? Yes, indeed, so back then, in fact I guess what was then called the Arpanet was extremely small, four nodes in package network and at this point in time these guys here made the first transmission over this kind of first Internet in, fact they were quite committed and stayed up in the middle of the evening, as you can see from the log file, at ‑‑ they tried catch each other on the phone to verify whether the transmission has succeeded. So, they phone each other and talked and they went on the phone say, well, did you see the L? And sure enough a question ‑‑ answer comes back, yes we see the L, this is exciting, the first letter being transmitted over the Internet.
Second thing on the phone is we typed the O and asked on the phone "did you see the O?" And we evidently making progress here. So they said "yes, we see the O". They typed the next letter, G, and the system ‑ shall unfortunately the system crashed. So you are all here today, so it's sort of I guess goes without saying that classical Internet has come a very long way since sending like or attempt to go send three letters over the Internet to see we have right now.
So in fact you should be thinking that kind of the quantum Internet today has very similar stage. So in fact we name 2020 to actually have this in the Netherlands, between Delft, the Hague andAmsterdam, over fibres from KPN, which is very small. But of course we are hoping to build technology that other people can take forward and actually kind of, I don't know, deploy much more broadly than we can do this in university context.
So these are some of my colleagues, Ronald and Tim and David, and we have what is called I guess the quantum Internet alliance in Europe, which also has a few other universities. To together we are aiming to build this quantum Internet, actually it's not too long in the future, 2020, and let me now maybe say a little bit about what a quantum Internet actually is. So, maybe to be perfectly clear, a quantum Internet is not to replace the classical Internet. So classical messages kind of bits, zeros and ones can be transmitted perfectly well over Internet, there is nothing extra to add. You should be thinking that a quantum Internet rather operates in parallel to the Internet that we have today. And crucially, it provides kind of the users with the ability to send Q bits, so quantum bits, instead of just classical bits. And Q bits are quite special unlike classical bit which are either zero and one. Qubits can be in some sense zero and one at the same time in something called the super position. The ultimate goal which is quite challenging to obtain is to communicate qubits between any two points on earth. In the future we might have computers that might kind of exchange qubits or create entanglement between them. If you have read the news about the quantum computer I would like to emphasise, so quantum computers need very many qubits, I guess many only means about 50 or 100 to do something a classical machine can not do and the reason why they need quite a lot of qubits or from our perspective, is because they need to be faster than your classical computer, most protocols we do know work with less than five of these quantum bits per quantum computer and the reason you can still do something more interesting is because you are not trying to simulate this classical ‑‑ Quantum Internet on kind of classical Internet but rather you are trying to add fundamental capability brought by quantum entanglement that is absent from the Internet.
So, why do we want to construct one? So I should say, I think it's very cool that we might be able to transmit qubits from any point on earth to the next. But there is actually some protocols known, so I should say of course we sort of expect that S, we realise this thing, maybe one of you guys will go out and programme more applications, currently there is already some known, probably most famous is quantum secure communications or quantum key distribution and I will say a bit more about this in a second. Maybe less well‑known to you is that quantum communication can be used to synchronise clocks, approval better than using classical communication. People have used it to combine the baseline of tell /STOEPS by tell porting a particle of light from one telescope to the other, to do an interference ex /PERPBLGTS I guess if people in physics like to learn something about nature. People have shown there is exponential savings in communication rather than computation meaning you need exponentially fewer bits to solve a problem. It's super hard to send qubits but exponential is quite significant. And if this does not convince people have come up with a way where in fact if two people who want to play bridge share quantum entanglement then even though they cannot talk to each other at all or communicate entanglement helps them to win the game much better than they could otherwise ever do. So there is some fun applications out there. Of course, also for quantum computation it's interesting so you might imagine that of course just like with classical communication you can link computers to form say one bigger computer. And of course I guess maybe for our friends who do more quantum computation you might imagine that S quantity you can computers get realised there is not so many of them. Maybe it's desirable but we don't expect everyone laugh quantum lap to be in front of them but rather will go back to the idea where this may be one very expensive mainframe in the basement at least for some foreseeable time and you want to have a simple quantum device at home that can send qubits to this mainframe in order to perform computations.
So, I want to say a little bit about what makes qubits different from classical bits, in particular I want to tell you two essential features of quantum entanglement. And in fact, it is sufficient to understand only these two elements of quantum entanglement in order to understand quite a lot of or get some intuition of where quantum communication can be useful. So the first one is in fact that entanglement even though you don't communicate, while you already have it, leads to maximal correlation, and let me explain what this means. So let's say we have Alice, maybe here in Budapest, we have Bob possibly back in Delft and let's say they actually share two entangled quantum bits, now entanglement has beautiful feature that no matter what measurement we make on these qubits or what question we ask, if you think about these boxes you can say no matter what door we open, we will always see exactly the same outcome. So this outcome is not prior determined, it could be red or green with some probability but whenever Alice sees red Bob also sees red. And in fact this is true for any measurement or question they would make, so if they make a different measurement or ask a different question, open top part of this, if Alice gets green Bob always gets green.
So why is this sort of useful? I guess I want to give you only intuition here. I mentioned protocols like clock synchronisation and cheating at bridge and the reason why people can use the entanglement to cheat bridge games they can use it to coordinate their strategies. So entanglement by these properties allows much more coordination and for this reason it's very interesting, there has been some distributed systems, protocols been propose that had use quantum rather than classical communication.
So another cool feature of entanglement is that it's inherently private, and this actually gives rise to the most famous application which is quantum key distribution. So what does it mean that entanglement is inherently private? So let's again imagine Alice and Bob, they have their entangled qubits and of course you might ask yourself now, can it be that there is a third party, for example, an eavesdropper who is trying to learn their conversations by listening to what is going across the wire, is it possible that this third party is just as entangled with Alice's qubits as Bob is with ‑‑ just as entangled as Alice's? The question is can entanglement be shared? Is it possible for three people to be just as entangled as two people? And the kind of cool feature of quantum mechanics is this is not the case. In fact if Alice and Bob are completely entangled then it is impossible in quantum mechanics for anything else in the universe, in particular also an eavesdropper, to have any share of that entanglement. So this means that if Alice and Bob know they are entangled then they know the qubits or the entanglement is private. Nothing else can have any share of that.
So the nice feature is now that we can test for entangment, so entanglement is generated for example by Alice kind of preparing two qubits, sending one of these to Bob over the Quantum Internet and the /KWU bit eventually arrives with Bob. So now of course if you are paranoid and think of someone listening in on this wire it might be it was intercepted so maybe these two qubits are no longer entangled once Bob receives a /KWU bit. So the nice thing it's possible to perform a statistical test to check whether they are entangled and you can understand the protocol of ‑‑ in a cartoon form it's just to go the following thing: First, we try and generate end‑to‑end entanglement, Alice prepares two qubits and sends one to Bob and they test are they entangled, yes or no, do this many times. So they test a random subset. So, if the test succeeds they know kind of the remaining qubits are maximum entangled. If the test succeeds, remember that they are also not inherently private but also maximally correlated that entanglement is private and if they measured they get the same outcome so they have the same key and can use that for encryption.
So the only thing to remember about entanglement really is that it gives maximum correlations and maximum privacy.
So this actually can be done, for example we have performed loophole free bell test in Delft over 1.3 kilometres, but maybe want to convince you this is not science fiction but it has already been done.
So let me now tell you a about what is the state‑of‑the‑art in quantum communication. Or you might ask yourself why is there no Quantum Internet yet. So it turns out that sort of quantum communication over short distances is actually reasonably mature, in fact you can go out and order some kind of box that performs this task of quantum key distribution over distances of around 100 kilometres, normal telecom fibres. So the grand challenge here is to go beyond 100 kilometres and transmit qubits over arbitrarily long distances. So have been implemented at short distances. If you Google on the Internet you will probably find some kind of quantum network in Tokyo or China and you may observe that of course Beijing and Shanghai are decently far apart. So, are these quantum networks or what is going on here? So these are networks which, right now, are only used for producing key, there is a single use application to generate encryption keys end‑to‑end and they are not, say, true quantum networks in the sense they don't allow toned end transmissions of queue bits. What do they networks do? These are called trusted repeater networks, if Alice is decently close to a middle station, let me call him Charlie, if Charlie is decently close to Bob, less than 100 kilometres, then Alice can make a key with Charlie, Charlie can make a key with Bob and of course they can use this to obtain an end‑to‑end key.
This is not particularly satisfying, because you might imagine we all know how the story ended, if Alice and Bob do not trust this kind of intermediary station then of course their end‑to‑end key is not secure. So this is sort of like, I don't know, obvious way I guess to extend the distance but is of course not what we want to achieve with Quantum Internet because there we want to have end‑to‑end quantum entanglement.
Let me give you an idea of how quantum Internet works, why this is sort of quite different than classical communication. So you might ask the question actually, why is long distance quantum communication difficult? So, it turns out that we cannot copy qubits so this also rules out repetition as a means to correct errors, so if some people in the back of the room cannot hear me properly I could repeat my message and maybe the next time they can hear me. So if I were to transmit qubits that is in fact not possible because I cannot make a copy, once it's lost it's completely gone. The other kind of restriction is actually a technological one, in the sense that we can only perform operations right now on very few of these qubits at the same time. And if I say few you should be thinking less than ten. So this also means that sort of like large scale error corrections, I take my qubit and perform adding redundancies into, I don't know, thousands of qubits it's not really possible technologically right now and not in the near foreseeable future. So thankfully, there is a way around that, which exploits a feature called quantum teleportation and I think it's useful to understand what it does, I am not going to explain thousand works. So note there is two ways to send qubits, first is by direct transmission, I take it and send it across a fibre, travelling down the fibre. The other way to send it is to actually first create entanglement, so again by kind of Alice prepares two qubits in entangled states and sends one over to Bob and then transmit a qubit by teleportation. So teleportation takes a state, I make a measurement here and this destroys the entanglement, I have to communicate some classical bits, and important to understand and Bob can perform a correction operation that retrieves the qubit. So why am I mentioning this to you? There is two nice features about this. So first, note that I can now again use repetition, because I can first try and produce this entanglement many many times, and once I succeed then I can transmit my precious qubit. The second reason is that we can now sort of also build a quantum repeater, which actually exploits ideas from teleportation. How does this work. So, imagine that these blue circles are my network stations, I create entanglement between say Alice in the centre, so these are two entangled qubits, between Bob in the centre again entangled and this I can do if these stations are sufficiently close. And then I can take this qubit here and again use teleportation to transfer it to the end node. So now two short distance entangled links to create entanglement over the twice the distance than I had before. So what this means now is that a quantum repeat Erik make entanglement, in a segment, and basically I can glue this entanglement together to have entanglement over very long distances and once I have entanglement I can send qubits over that distance.
So why am I mentioning this to you? I am mentioning this to to you highlight some of the protocol requirements or design features that will become relevant Thor fees networks because it's sort of clear given we will quite often not stoned bits directly down the wire, that protocol stack would have to keep track of these entangled links. A protocol stack would have to Mca matching between qubit and classical ‑‑ right now you send the data portion and the header in one packet, it's all very convenient, classical header is data, classical bits the data is classical bits pull it and pack at that stage nicely together. This is not working here so the ‑‑ we need new protocol here for example that maps qubits to classical headers. So like I said this is the wild west, there is no protocols for this yet. And I am actually here because I want to talk to you and I guess maybe some of you in fact can help us define these protocols which are necessary for quantum Internet in the future. So there is end nodes and we do long distances by exactly employing such repeater stations. So let me tell you about state‑of‑the‑art because I guess you might be wondering do what these look like. There is actually quite a few implementations of this, you can think about one of a repeater is a small quantum compute they are a operates on roughly 6 qubits, storage times are roughly a second so it's not very much. Entangling rates are also quite low. Our objective is currently to make this work, our objective is not to make it go /KWEUGy bits per second, someone will hopefully go out and do giga/KWU /PWEULTS per second. There is few groups around the world that uses similar system, this is the system we have in Delft, this is kind of what a Quantum Internet repeater looks like. So this is a chip, as you can see, and kind of captured in the middle is a diamond, and this diamond has a defect, called colour centre, it's what gives diamonds their beautiful spark he will and you can think in each of these we can trap some of these qubit. So you can see also in the hardware domain this looks a bit different than what is happening classically.
So what is QuTech? We are a research institute in the Netherlands, a national icon of the Netherlands with realise to ‑‑ if any of you should be so inclined we actually have programme for master students and they will also get in the near term few pure called quantum campus around QuTech where avenue with member like Microsoft and station Q and Delft. If you want to learn more about that, please come and talk to me here, I come here so we can talk, and communicate. We will also have an open day on 22nd of June, details will be announced on our website. So you are most welcome to come and visit. We will also in fact on this open day to a first better release to I a select number of people of a simulator of quantum network nodes or potentially stack on simulated qubits. We cannot give you our real qubits, they are expensive. But we will release a simulator that kind of allows protocol development. If you want to learn more details in fact how this really works, there is an on‑line course on E D X, which will run again this fall, so this is only about quantum crypto but teaches you about qubits and if you want to know more talk to me here. Thank you very much.
(Applause)
CHAIR: Thanks, are there any questions for her?
STEPHANIE WEHNER: I am waiting for the question why is it you not use IPv6?
AUDIENCE SPEAKER: Not as /AFP question as a /TAOEUPB owe word of caution, when you said we don't expect everybody to have a quantum computer on their lap, there once was a guy who thought 32 bits was enough, be careful.
STEPHANIE WEHNER: I hope, maybe that will happen before I have a lot of grey hair and very old.
WILFRIED WOEBER: Still in some relationship to Vienna University and I am completely illiterate when it comes to quantum physics so there are two little questions and the first one might actually be a dumb one, and it would be what is the physical implementation or the physical reality of a qubit, is it just the impurity in the letters of the diagram?
STEPHANIE WEHNER: There is certainly energy levels in this diamond and you can think every energy level, if I have only two I might labour them zero and one, so if the system is in the lowest energy state it's zero and if it's higher it's one. And it can be in super position in the quantum domain.
WILFRIED WOEBER: So you could relate that somehow to the energy levels the electrons around the atom core? And you pump it into the higher energy level?
STEPHANIE WEHNER: Exactly.
WILFRIED WOEBER: And the other one would be a more application‑orientated one. Did I get that right, that the primary application you are envisaging at the moment is the transfer of shared keys?
STEPHANIE WEHNER: Well, I should say ‑‑
WILFRIED WOEBER: The reason I am asking that we have already sort of the system and concept of private and public keys, so I am wondering what the other technical information, technical research, what the real beauty is sort of to focus on technology which allows the transfer of a shared symmetric key between two ‑‑
STEPHANIE WEHNER: Let me say something about that. Maybe two answers to that question. So the first one is my goal really is to realise a quantum Internet, that you can also exchange keys with it, it's a great protocol, but my objective is to get a qubit from A to B. So the second part maybe I would like to say is kind of related to the question, what does quantum key distribution add over public key crypto so I should say that /KWU ‑‑ has a different use case in the sense it really exchanges keys to be used in symmetric encryption and is secure even if the attacker has quantum computer, even if the attacker also has a quantum computer in the future so a lot of public key systems have been proposed can be broken on quantum computer and fending on how paranoid you are it might be concerning they are also broken on quantum computer which may only come about in five or ten years from now. So if this is of concern to you then maybe you should worry about this, yeah.
AUDIENCE SPEAKER: Speaking for myself. To the previous question about management /PHA*EUB many quantum key schemes they are using the ‑‑ that quite secure. My own question is, at what kind of ‑‑ em mitter you are using, which wavelengths?
STEPHANIE WEHNER: This is like an emission from diamond which is natively at 637 which is converted to telecom wavelength.
CHAIR: Thanks, Stephanie. Thanks for your talk.
(Applause)
CHAIR: And just a quick reminder before we finish the session and the whole day, please vote for the RIPE Programme Committee elections, go to the RIPE 74 website, programme, RIPE Programme Committee and then RIPE PC elections and vote there. Thank you and thanks for being so nice. See you tomorrow.
(Applause)
LIVE CAPTIONING BY AOIFE DOWNES RPR
DOYLE COURT REPORTERS LTD, DUBLIN IRELAND.
WWW.DCR.IE
