Archives

Closing Plenary session
Friday, 27 May 2016
11 a.m.

CHAIR: Good morning, welcome to the Closing Plenary. Before we start with the Closing Plenary, we have a number of announcements. For the PC election, we had actually already two candidates, two nominees and elected candidates on Tuesday. So, I want here to thank Filiz Yilmaz and Jan Zorz, they are outgoing PC members. There will be some other announcements by the PC Chair. There are two incoming of course. Welcome, Peter Hessler, Ondrej Sury, and something which was not on stage, but, something which was not on stage, but it's also a regional‑appointed PC member. So, for the east Europe ENOG appointed member, Sergei is outgoing, thank you Sergei. And incoming PC, appointed PC member from the ENOG region is Alexander Semenyaka.

Another announcement. They had a very tight schedule and they are just finished their final about the football contest.

SPEAKER: I want to show you the finalist, and the winners of the table kicker tournament for this RIPE meeting, and I want to congratulate everyone who has joined and especially the winners from Denmark.

CHAIR: Thank you. Any other announcements? I don't think so. Hans Petter will come with a number of announcements and closing part. I want to invite the next speaker, Geoff Huston, very happy to have you here on stage. Seeking desperately ‑‑ or desperately seeking default.

GEOFF HUSTON: Thank you very much. And it's good to see a few of you survived last night's social and are back here. I have been to many RIR socials in my life, many of them from classical oriental loot playing or something that I have thought. I have never been to a social quite like it. I had a great time. I hope everyone else did too, so thank you to the folk who organised it.

So, today, this is kind of a geeky talk, and I'm sorry about that. It wasn't sort of meant to be this serious. But I wanted to talk a bit about what a lot of you guys do when you peer and transit and so on. Because, all of these interconnection resource all really about one thing: You are trying to connect to everybody. And I'm not sure any of you have ever looked hard at how successful you are.

So, all of this are desperately seeking default. There was a movie, it was in the 1970s, desperately seeking ‑‑ somebody ‑‑ Susan ‑‑ thank you. I'm going through movie tight else in these talks, it will take sometime.

So, anyway, yes, we come from a telephone legacy, a rich legacy. Some of it was inspired lunacy, but some of it was a social contract that we always assumed but never wrote down. And one of the strange bits about this, particularly when we started to extend the dialling plans from regional to national to international, was as longs you were patient enough and kept banging the numbers, you could ring anyone. Anyone. Because the telephone didn't care. And the theory was that your telephone operator was speaking to all the other telephone operators in various ways that were secrets to them but the end result was you could call anyone. It might not be cheap, you might need to save your pennies for a few years, but you could call everyone. And that was part of the contract. Everyone was reachable by everyone else.

So, have we continued with that social contract? Is it really the case that you, your machine, can send an arbitrary person, my machine, a packet? And can I reply? And you kind of think, well, the Internet seems to work, doesn't it? This kind of works, doesn't it? You kind of okay, you are all professionals aren't you, you have actually made all this work right? But you and I know that's bull shit. You and I know that's complete crap because most of you can't reach my machine. Why? Because I'm running a NAT. So I can see you and if I open the door, you can see me but normally the door is slammed shut in your face because I am not a nice person. And a lot of you aren't nice people. And in actual fact, there are very few open things out there, the aperture is amazingly small. Even if I open my machine through the NAT, you can only see me on two ports: Port 80 and port 443. Why the hell the folk who are doing DNS over TLS decided to do port 853, bad idea. There's openly two ports that work. 80 and 443. It's an amazingly small aperture we have go to cram the Internet in. The theory is now, that everyone can see everyone else sort of. Well, maybe everyone can see the servers on port 80 and 443 and that's as good as it gets. Which seems a bit crappy as a social contract but there we are.

Is even that true? Does even that work? If I stand up a server, can you see me? So, I'm getting interested in this, and I'm kind of thinking to myself, is it really the case that all of these peerings, all of these IX meetings, all this idea that connectivity is a market not a regulated outcome, there's no guarantees in the Internet like there were in the telephone world. So, when you connect to someone, you don't get default. You get their routes. And we have this implicit faith in a market and a faith in the players in the market that that's the same thing. But is your faith misplaced? Are you really getting what you thought you were getting?

So, there's a very kind of simple way to think about this. Because normally, it's not that you can't see me and I can't see you. Nothing is so easy. Normally, you can see someone who can't see you back. So, for example, the client can send the server a packet. Fine, the server gets the packet. The server goes well, this is really great, but you probably need me to answer you. And the answer never makes it. The server can't see you. So, a whole bunch of the Internet is probably working, you know, with only one eye, one bit of it works. What the server sees is part of a connection, but the handshake never completes. Because, the return paths are sometimes broken.

Now, you can start to measure this. And one of the ways of measuring this is actually doing a large scale end user measurement, it's like what you are doing in Atlas only in a much bigger scale. This is around 8 to 10 million individual experiments a day. And what it shows is the connection failure in v6, now, admittedly, this is like shooting ducks in a barrel, v6 is not the most reliable of protocols these days and so when I say there is a 2% failure rate, 1 in 50 die, you know, it's a bad situation, we haven't done a very good job.

You can break it out a little bit and go that there are two classes of users out there in v6. There is the poor hopeless bastard sitting behind tunnels who literally what they have got is worse than no v6 at all. And everyone else. If you are on a tunnel your failure rate is one in ten. Turn it off. Just turn it off. You are not doing anyone a favour. One in ten is crap. If you are not using a tunnel, your failure rate is just a little under 2%. That's still pretty shocking, isn't it? Like, when we first trying doing IP over mobility and had a 2% failure rate it didn't bloody work. So this is not very good. And you kind of go, why? Why is this failure rate in v6 so bad? You are professionals, you get paid for what you do, I assume. Maybe some of you do it for kicks, but you are doing this as a job, you are buying equipment that's meant to work. You are design be a system to work, otherwise why bother coming to work? Why is your outcome so shocking? Why are you doing such a bad job?

And I think that's worth asking. So, some of this is, as I said, tunnels are bad. Tunnels are really bad. And secondly, really cheap CPE, Consumer Premises Equipment, is not a bargain. It may cost you very little from Belkin, but it's worth what you paid for it. Totally. And so sometimes what you have in your house is not worth having. You know, under normal consumer protection laws it should be actually crisped, fired and thrown out. And the folk who set up firewall filters are not humanoid. I don't know what planet they come from, I don't know why they do this shit, but a firewall rule that says accept nothing is unhelpful and there are a lot of firewall rules that say accept nothing. Why bother connecting?

So, there is a whole bunch of local failure, but is that all the problem? Is that all of the problem?

Now, in theory, v6 is toy, v4 is money. V4 is money. And in theory, if you can't get v4 packets through a network, you are not going to get paid because if your network isn't working in 4, there is no Internet whatsoever. So, I looked at the equivalent failure rate in v4, firstly there is one. And that kind of surprised me because I reckon all of you believe there isn't. That all of you actually believe all my packets make it through most of the time. There's no structural reason why they shouldn't. And these aren't big packets. They are little packets.

But the failure rate is one in 500. And it's really consistent. And I don't think it's me. Wherever I look from, I see structural failure in v4, so again you are getting paid to do this. This is not something you designed. It's something that resulted.

So, you don't auto tunnel in v4 unless ‑‑ well you just don't and if you think you are doing it, stop it, it's a really bad idea.

The lousy CPE normally lets four packets through or you wouldn't buy the thing in the first place and strange firewall filters exist but they always let through port 80 and port 443, otherwise again there would be no Internet. I can't blame the v6 culprits. There's something else there that's kind of niggling. And I am wondering if it's the routing system.

So, there are a few ways that you can look at a lot of the Internet in one phenomenal snapshot. Get the rocket ship up and look back at the earth. One of those massive points is the route views routing table, the route views archives done by the project in the university of origin, a fantastic job, huge archive goes back for years. And you can build this phenomenal story of the Internet just by looking at the data in that archive. This is every single peer of route views since 1994 looking at the number of routes they advertise to route views. And one of these is a pointer ‑‑ that was the Internet boom for those, you know, old farts who were alive at the time. For you kiddies, this was the 1930s of the Internet, we stuffed it up completely, all the money went out and some of us were out of a job for two or three years. It will happen again. Just wait...

It's a little harder to see but that was the financial crash that happened. And the former impetus kind of cooled off a bit as the money ran out but where the Internet, hope breeds eternal and as we ran out of v4 we decided that we'd give it an extra kick so the v4 routing table started to explode again and now as we run on empty, we have never run so fast. I don't know how you guys do it. It's amazing. There is nothing underneath you. You have got off the edge of the cliff. If you look down you will fall, but suspend all disbelief, we're out there. That's amazing. So there is the history of the Internet. But why isn't that one line? Why do each of the peers of route views actually have a subtly different number of routes? It's not that everyone sees 623220; they see different numbers. So, you blow it up for just this year. And you look at again. That's what I'm interested in. Some folk see more Internet than others. Are these folk missing out? Are these folk sort of not seeing things that these folks see? Well, I assume that everyone sees Google. But do you see me, or you, or you? Are the bits that are missing down here our 1 in 500. Now, this isn't the best way of looking at the Internet. This is the number of routes, right. But, it's start to go get interesting because everybody says to route views, my Internet is different from your Internet. We don't agree on what default is. We also use subtly different view. So let's really look hard. And let's not talk about the number of routes. Let's talk about the span of addresses you believe you can reach.

Now, if the only thing is route prefix filtering, again, you should all see the same address span. You don't. And that's a lot of different addresses out there. So, route views, not everyone sees the same address span. We actually differ by an entire /8. Around 15 million addresses. So some folk will see, we'll see who later, see a lot let of the Internet ‑‑ SURFnet, than others ‑‑ SURFnet ‑‑ and do they know? Do they worry about this? Do they try and fix it up? Does it even matter? But certainly, there are folk who see more than others. And it's kind of this is weird. The other thing to note about this is that the folk who see more always see more. The folk who see less, don't try and fix it up. They have seen less for years. They don't think it's a problem they need to fix or they can't fix it. So it's not as if the lines are jumping. They're not at this level.

So, again, I'm kind of interested in this. This is stable. These are your peering and transit relationships and they are not giving you what other folk see. I have no idea why. So, you know, that was v4, and that was your parents, right. Your problem is v6, you young children out there. So, are you doing a better job? Have you learned?

Well, you know, from the look of the route views table itself, things look pretty crap. I always love World v6 Day, it made such an impact. There's that very slight blip that lasted for a couple of months and then we're back on a different trajectory. There's hope there, but we all see a different v6 network, don't we? If you blow it up again there comes that variance and if you look again, the thing about v6 is, big is big. And the variance is really quite large. So again, what we see in v6 on the address span and here I have actually managed to pull not only all the data from route views, but I have taken every single peer from RIS just for the hell of it. And so what you see is, that there's no default. There's no definition of that.

So, I invented one. And my invention was pretty easy. It's an election. If more than two thirds of the peers of RIS or route views see an address, let's put it in default. If less than two thirds of the peers see it, let's say it's not really a default. So, now each individual peers, some have extras and some things that are missing. That's a way of looking at this.

Here is a view of v4 for each peer of RIS and route views together, looking at how much is above the line and how much is below the line. And again that's really interesting. What you are seeing is, there are folk who consistently see more than their peers and folk who consistently see less than their peers, and they never bother correcting it. They never bother. Either they don't know, or they don't know how to fix it. I'm a little bit impressed about this.

So you magnify it up, and again, that stability is still there, that even if we look at here it's 4 by 10 to the fourth, 10,000 addresses. Folk above the line, folk below the line and by and large nothing changes. Apart from there was a meeting early this year when a number of folk got some routes that no one else got. Weird, weird.

V6, exactly the same problem. That when you look at that deviation you can see there are some above the line, some below the line. You can zoom in on v6 and you start to see again that stability, right. And whatever that meeting was sometime early this year, a bunch of peers in RIS I think it was, got some extra addresses and you didn't share with the Americans, because you know, they are our addresses aren't they and you know default is all relative anyway.

I am impressed with this. You can zoom in and start to look at the really fine level of v6 and at that point, beneath it all is Jason Pollok, because that's what the data says.

But I said I'd name names. And so, what I did now is rank them by what they're missing. So, at the top of the list here APAN, the missing 92 million addresses from the peer set. They are a research network and maybe that's okay. Telianet does this for a living. They are professionals. They are down 50 million addresses in route views. You need to find them and fix this.
Sprintlink is kind of good. But others, even Hurricane Electric appears to be missing around 1.9 million addresses and it's begin as an extra 5.3 million over the quorum. So none of you can agree on what default is. You all have this kind of relative view of bits in and bits out.

But those are the Americans. These are the folk who peer with RIS. And again if you can see yourself here, SURFnet, inity 7 and so on and so forth, here is where you differ from everyone else. Here is where your peering and transits are not giving you what you thought they were meant to give you.

V6, exactly the same sort of analysis, and again, winners and losers, go and look at the slides online, go and find yourself, and then ask what happened? Why did you do this?

So it's not I had a slip‑up last Thursday, I had too good at the social last night I'll fix it up this afternoon. This is what you do for a living. If you're shot you're always short. And the assumption is that a tier 1 is a commodity. I can buy from you, I can buy from you, I can buy from you and you are all offering me exactly the same goods, you are offering me a default. You're not. Yours is different to yours is different to yours. They are not the same. And it's very, very hard to actually analyse the quality of the route set you get from your upstreams. It's even harder when individual as networks actually announce different route success to RIS and route views. Because they can. Or because their internal network is so well connected. I have no idea why. But they are doing a great job, they are getting paid for this.

Now, you have seen presentations, and I have too, and that's the paper that came from it, Internet optometry, but actually it doesn't really matter, default fixes it all up. And to some extent, default does, as long as where you're going is in a tier 1, is at the top of the food train. So it doesn't really matter as long as you go to Google. Because basically paths to Google work. But when the breakage is further down, you can't see me, because you'll go and follow a default but coming down the other side to find me, you may not see me. And so that's where these subtle bits of breakage actually occur.

Can I see it? Well I can see it in the stats. Around 1 in 500 connection attempts actually fail and when you think how can I tell if that's the case, if I go back to this model, you send me a packet. I try and send you back a packet. At some point the router, along the path says, can't get there, that route isn't to me and the packet will get dropped. Now if I'm lucky and trace route depends on this for example, and ICMP destination unreachable comes back to me, I can see a failure. So, what I should be seeing is a bunch of control messages saying can't get there from here. And so, despite fact that most was you firewall filter out ICMP, naughty, don't do this, we love ICMP, the sewage of the Internet controls valuable protein, just ask the vegetable growers, I can see and should see an ICMP that says so and this is what I see. That I get back a packet that says that SYN attempt, the reply failed, and here is where it failed. You can't get this from here. And there is a lot of those. Now it's the Internet, everything happens. If you can think it's stupid, you'll see it. And so here is a better one which I really love. The destination address is telling me you can't get there. You have made it, but you haven't. Think about this for a second. This is a remarkably confused machine. You have got to me but you haven't really got to me.

What's actually going on, and there's more and more of it by the way, is that you guys are hiding behind Carrier‑Grade NATs and the NAT bindings are erratic and they keep on disappearing and this is a particularly stupid NAT that found a binding, allowed packet to go out. Shut down the binding, so in the synac return tried to make it it failed. We are building all these Carrier‑Grade NATs, nothing goes wrong with the NAT, except that.

So, you know, this 1 in 500 failure rate, some it have is that default isn't what you think it is. Some of it is just NATs. Some of it is just junk but some of it truly is that default and the market that creates connectivity is flawed. And at the fine level of granularity, there will always be somebody you can't get to some of the time. So, what does that say about the Internet?

Well, unlike the telephone, you have got to qualify this an awful lot. Because almost anyone can reach almost everyone else for you know almost most of the time on a good wind flying downhill when it's sunny outside. For the rest of the time you're screwed.

Thank you very much.
(Applause)

CHAIR: Thank you, Geoff, for your interesting presentation. Randy.

RANDY BUSH: Geoff, looking at route views in RIS is an art, which you're good at and I think you actually know that there is a serious problem, is that people do not give route views in RIS. What they give to customers. They give ‑‑ sometimes they give a peering feed to route views or RIS. Sometimes they give a customer feed. Sometimes they also leak all their internal /99s. Okay. So, that's really when you dig into it, the difference in what you see and if instead you take even the address converge span, you see the differences, because they give peering or customer to out views and RIS. I think the packet level that you're looking at and the issues of CGNs, etc., are really real. And I understand and agree and think there's some real fun to be had there if you have a strong stomach, but looking at route views and RIS and trying to think that's 2914, actually gives to their customers does not paint a really accurate picture.

GEOFF HUSTON: I'd agree with you. The route views view is kind of illustrative not only of the fact that there are private nets and so on, it's illustrative there are differences. The ICMP message‑flow coming out of this data says some of the time those differences really mean something. Some of the time I do see hard and solid evidence of asymmetric connectivity where the TCP handshake comes in and doesn't get back. It's not common, because otherwise we'd all be out of a job. But it happens.

RANDY BUSH: I very much agree on the data plane level. But I think inferring it's because there was nothing in the control plane, the routing table to cover it is a leap I'm not willing to take.

GEOFF HUSTON: Okay. I don't share your faith in the market for default. I think that market is a flawed market. And that folk actually do offer subtly different views.

RANDY BUSH: I'm not saying they don't. I'm saying measuring it by looking at the differences in what they announce to route views is not a clear view.

GEOFF HUSTON: Thank you.

AUDIENCE SPEAKER: Jen Linkova. A question, if it's CJN, right, you should see a kind of spike in this stuff.

GEOFF HUSTON: If it's CGN, and it's an aggressive CGN, I should get back a message saying, the customer end did a FIN, I destroyed the binding and my FIN, ACK died, ICMP FIN, ACK, that's the way a normally well‑behaved CGN, if there is such a thing, should work. The thing that I showed you was that the ICMP message came back from the handshake, kind of you extend your hand out to me, I try and reach back and get my hand chopped off. That's a bad CGN. You know, it's not going to work and that was the bit I was illustrating that sometimes those binding tables are way too aggressive. But I do see evidence of better behaved CGNs in the same data stream.

JEN LINKOVA: Do you see that it started happening until recently?

GEOFF HUSTON: No, no, people have been doing this for years.

JEN LINKOVA: The second question, talking about this contra plain routing, do you see ‑‑ have you looked in the prefix lengths? Is it likes if you live in PI which is /24, some people feel there is a Cloud or is it just for all types of routes?

GEOFF HUSTON: I have not looked. The data is there, all the RIS archives are there. Throw the awesome power of Google machinery on to this problem and you too will see what I saw and you too can go look. It's not a difficult question to answer. But, I didn't do it for this particular exercise. But the fact that the RIS archives are there and the route views archives, let's you go and track down those issues in a little more detail.

CHAIR: So three people on the mike. And closing the mike.

AUDIENCE SPEAKER: Joe Provo, Google. Speaking for myself. I agree with Randy in terms of scepticism and, I was going to raise the covering prefixes point but that's been touched. So...
Two other items. High on your list of folks with missing prefixes were folks known to perform some filtering, some of it automated and especially filtering on their customers. Is there any evidence for trash being some of these prefixes that are supposedly missing? And the second is, perhaps we're seeing, well it may not be marketed, perhaps what we're seeing is not so much an origin of a commodity but differentiation of product.

GEOFF HUSTON: If diversity of a product says you can reach me and I can't reach you, whereas the same happens with ‑‑ a different thing happens with someone else, so that everyone has a demented version of default is market differentiation, we have reach a really really sad spot in the history of the Internet and I for one would like to see the exit door. If you are missing and low it's not junk filtering. Two thirds of your colleagues advertised that address, and I also note that what I was showing you differences of was the span of addresses without respect to covering prefixes. I got rid of all that junk. So these were folk who could not reach a set of addresses that two thirds of the other folk that peered with route views or RIS, saw reachability to that address. So I think it's a little bit more serious than just a bit of junk in one or two peers. There is something in there, there is something there and if you die that with ICMP and broadband measurement you'll see to some extent this is this tiny problem. One in five hundred, something like that, but there's something down there.

CHAIR: Each one, one question. Peter.

AUDIENCE SPEAKER: Petter Hessler from Hostserver. I wonder you were able to take a look at the originating AS force those routes and if there was any correlation between the v4 and the v6? Like, was it just one provider being not distributed, or anything like that?

GEOFF HUSTON: Don't forget the definition is you're in default if two thirds of the peers of that route collector says it's advertised and you are out if less than that. There is an amount of common voting going on. The differences are differences from your peers not differences in one address. When you start to say can I see this and that, I refer to the answer I gave to Jen: it's public data. Amazon gives you really cheap compute power, knock yourself out.

AUDIENCE SPEAKER: First of all, I appreciate your trust in international telephoning because based on my experience is it's also, almost, almost and most of the time.

Secondly, is it really relevant because working and residential ISP was analysing statistics and traffic of my customers, so at least half of table I see on my board routers have nothing that can attempt, so I can dump half of my routing table without any effect to customers. So, I think that it may be a traffic engineering, or ‑‑ well, for actual customers they will not see this.

GEOFF HUSTON: You know, I don't know about you, but, I didn't build an Internet just to reach Facebook LinkedIn and Google. The true dream that I had was actually an any‑to‑any dream. I must admit the way it's been built, sucko, Geoff, you lose. It doesn't have to be like that. In my book, it shouldn't be like that. I should be able to be seen, if I want to, by everybody from my house, if that's my choice. And once we start to build a network that's Google's network, Facebook's network, Apple's network that we just see tier 1s and we can't see each other. I don't think I want to be there. I don't think actually we want to be there. I'm not sure that's going to carry us forward into understanding where we can push communication models. Because, quite frankly, reaching a few big servers is kind a banal and dull and the challenge is, keeping everyone in the same connectivity realm all of the time and that to my mind is not just a challenge, it's what we should be doing. It's why we get paid.
(Applause)

SHANE KERR: Thank you very much. So now we're going to start first of our series of lightning talks this morning. So, we're going to have a quick presentation by RIPE NCC. Marco Schmidt, introducing their brand new forum. I have been using this myself so I'm looking forward to seeing the formal introduction.

MARCO SCHMIDT: Good morning, my name is Marco Schmidt, policy development officer of the RIPE NCC and together with my colleague, Mihnea, team leader of services, we want to tell you something about the new service that we have just activated a couple of minutes ago. It's called the RIPE Forum. So, what is the RIPE Forum? Well, here it says, it's a new way to participate with the RIPE community mailing lists. And before going more in a detail, I want to give you a little hit of history. Over the last couple of years, we have received several times feedback and surveys in one to one talks and there was also a discussion on the mailing list that people says, there's so many mailing lists, my inbox is always floating over. Is there not something else that can be done, something maybe a bit more easy to manage via my web browser, for example. And also what we noticed in many mailing lists discussions, we are lacking a little bit of participation from certain parts of the community, from certain regions, for example, the eastern Europe, the Middle East. And why this might have several reasons, cultural and so on, it also was indicated that it might be in these regions the subscription to an English speaking class account mailing list is not so much liked.

And then we thought what can we do? And our solution this the RIPE Forum. This is how it looks. It's basically nothing more and nothing less than a web based interface that connects to all the RIPE community mailing lists, so you can see them here listed. And you can go there and then you can see the different threads that are ongoing in each of those mailing lists, and even can reply to it and each post will create an e‑mail to that mailing list. And vice versa, any e‑mail that the sent in a classical way, creates a post in that forum view.

And, of course, probably some of you will say, oh, my God, I am subscribed to the mailing list, I like my mailing list as it is, I want nothing to be changed. And I can assure you nothing will change. It's a very lightweight solution that sits on top of Mailman, on top of the mailing list, so, every normal subscriber will not notice any difference. It's just ‑‑ the discussion resource still at the same place how they are, and you don't ‑‑ this web interface is just an option. But of course we also hope that maybe some of you might like to try it out because it might have some features that you, even as a classical user, might like. There is a nice search function that you can use for each Working Group mailing list for example, and that it might be easier to find a certain discussion that was a long time ago than going through the mailings archives. And I think having said that, I will give now the mike to my colleague and he will tell you a bit more about the technical details.

MIHNEA‑COSTIN GRIGORE: Thank you, Marco. And I am glad to be here in front of you today introducing this. It's something we have been working on for the past few months, and I'm very happy to finally be able to launch it and hopefully get some usage from the attendees here before we announce it to the whole community next week.

A few technical details because I'm sure there's a lot of techies here who are curious about how it works. It's a web application written in Python in the period web framework, which has only read only access to the archives. Floss direct writing to any database or any complicated stuff putting on in the background. It's basically strictly a web interface. Of course, people need to be able to post to the mailing lists and they need to be able to subscribe to a new mailing list that they have never posted to before. And that is all handled through RIPE NCC access, our single sign‑on system, you are probably familiar with. So if you want to test it out, make sure you have a RIPE NCC access account in order to post.

As Marco mentioned, we have been testing this for the past couple of months and users of the RIPE Atlas mailing lists have been graceful to allow us use their lists for this and, so far, the feedback we have received was quite positive. We actually had people asking us for the code to use, on their own websites, which is something we may consider in the future. But a few statistics, maybe. About 17% of all the messages that were sent in this couple of months came through the forum. And there were hundreds of page views, this is a list of a few hundred people. So we're quite happy to see people go to it. The visits averaged a few minutes so people were actually reading and there is a very low bounce rate. A lot of people going to the forum actually found what they wanted there.

That being said, this is the link you can use to access the forum. Please mind there's an 'S' there, it's a short link to get directly to the forum address if you have want to test it out directly. If you want to send a message and see how it works, please use the testing list. This is mailing list created specifically for testing the forum functionality. So if you go there directly, you can do any tests you like and all the people on that list are subscribed only for this purpose, so, don't worry you're not going to bother anyone. There is also going to be ‑‑ you are going to see a little button on the bottom of the website, "Report a bug" and we'd be happy to see any feedback you have through that button, if you see a bug or something that doesn't work, please keep in mind this is still a new service, we call it a bet a, and please let us know and also if you have any ideas for improvements, please do let us know as well. Thank you very much and if you have any of questions, please let me know.
(Applause)

SHANE KERR: And of course it's no burden for anyone here to sign up and start using it because you already have an access account so you can rate all the presentations, so please do that as well.

Are there any questions? We have...

AUDIENCE SPEAKER: Wilfried Woeber. Maybe a suggestion to think about the capabilities of the mailing list. I am wondering if this actually becomes a success, and I hope it will, I think we might consider removing the digest function from the mailing list interface, because from my point of view it's just a nuisance.

MIHNEA‑COSTIN GRIGORE: Okay. Thank you for the feedback.

WILFRIED WOEBER: Nuisance on the receiver end, not on the people who are using it.

SHANE KERR: It looks like we have a comment from the chat.

AUDIENCE SPEAKER: Nathalie Trenaman, the Jabber monitor. I have a question from Bank Gordon from Resilience AB, is it possible to have the same identity on the forum as on the list?

MIHNEA‑COSTIN GRIGORE: Yes, that's definitely possible as long as you use the same e‑mail address as subscribed to RIPE NCC access is the one that's used to subscribe to the list.

AUDIENCE SPEAKER: Jelte Jansen. I have seen several different communities struggle with the problem of attracting new users that don't want to use the old mailing list. And they had separate instances and in all those cases either the old mailing list died and we lost them or the new forum didn't take off and they didn't get any new people. And I have not used this yet, but it looks like you have actually managed to combine both the ancient and the radical and I just want to say thank you, this looks awesome and I'm looking very much forward to using it.
(Applause)

SHANE KERR: Up next we have a short talk by Daniel Karrenberg talking about the RIPE Atlas streams.

DANIEL KARRENBERG: Hello. I'm not going to switch through the slides; they are available if you want them. My purpose here is just to interest you in the data sets that we actually produce through RIPE Atlas and maybe entice you to actually look at them or have grad students or some other resources look at them or just forward ideas on what could be done with them.

So, I think by now everybody has heard about RIPE Atlas. It's a collaborative active measurement platform. It has about 10 K probes all over the Internet. And basically everybody can use all these vantage points to do some measurements, measure whether Google is still there, or Facebook is still there, which seems to be very popular. And that's all great and you get your results and you're happy and you can use them.

What this does is create a very, very big stream of measurements. All these taken together. For traceroutes alone and that's just one type of measurement, it's 26 thousand traceroutes per minute. Think about this. This is almost 500 every second that come in here. In other words, it's also 10 megabits a second and it's about 7.5 gigabytes a day. So it's a very wide stream.

It's also a short stream because you get the results on that stream on average, on median, 75 seconds after they've been taken. So it's not quite immediate, but it's certainly near realtime. And if you wait for three minutes you actually get 99% of all those results.

And even better, it's available to anyone. So you can actually go and use it.

So, there is enormous potential, I think, for reusing the results of measurements other people did. And the main use I see for it is a nominal detection in near realtime. All this stuff comes along and you can actually see how does it change over time, and there is lots of potential to look at what does that mean? Did something in the Internet change? Did something significant change? And since the topology of the Internet is not flat, everybody's measurement goes through some common set of routers and you get some common set of interfaces. So, I looked at that and I took this whole stream for the 1st May 2016, the whole UTC day from midnight to midnight, and I actually found 500 thousand unique IP addresses in that stream the so those are the only globally unique ones, not the private ones, we got answers from 500 thousand different devices, and, for 25,000 of them, actually we saw them on average at least once a minute. So you could find very quickly if one of these 25,000 that seemed to be more frequently appearing, so maybe more central to the Internet topology, and you could see whether they go away by just counting how often they appear. And I did that, by the way, for instance, for the AMS‑IX outage we had and it was quite clearly visible only a couple of tense of seconds after it actually happened.

Furthermore, you see like about more than 300,000 different ‑‑ 300 million adjacencies that day, if you just look, on two addresses that appear next to each other in that trace route, there's 347 million data points over that day. There is a lot of topology information over time here.

So, basically ‑‑ and important to notice that this is real packet layer topology. It's not the routing stuff. It's not the metadata where traffic should flow, but you actual see where traffic flowed.

All this is available to anyone, so if you want to drink from the fire hose, as some put it, you can do that. You can also, in my little lab I basically store this data, so if you just want to look at it for a particular hour or day, you can find it. All the resources are in actually the slide pack that's uploaded and there is a RIPE Labs article from about a week ago that spells out the story. So, what I'd like to see personally is this potential of RIPE Atlas being realised by novel ideas in actually looking at this big stream of data and finding the gold in it to make ‑‑ give us all a better situation and awareness about what's going on, not in our own networks but in the networks around us.

And that's the end of it. Thank you.
(Applause)

SHANE KERR: Great, so I don't see anyone at the microphones. Is there any effort ‑‑ I have a question. Is there any effort by the RIPE NCC to kind of monitor and get a feel for how many people are using these kind of streams, do we know that?

DANIEL KARRENBERG: We are monitoring the Atlas usage, I'm quite sure. And also, I'm personally also looking for some just ideas that the NCC might implement, if you don't have grad students handy. There is actually already some work going on and we saw some during the hack‑a‑thon earlier this week, but I think this has enormous potential and I think it's worth looking at specifically for situational awareness for the stuff around us, we all monitor our own networks pretty well but sometimes things that we see and customers that may complain are not, you know, things are not caused in our own network. If we have something that gives us a near realtime handle on what's going on everywhere, that would be really, really good.

RANDY BUSH: 100‑odd years ago in America there was a bank robber whose name was Willie Sutton. Somebody asked him why he robbed banks. He said, "that's where the money is." Well, this is where the data are.

DANIEL KARRENBERG: Thank you, Randy.

SHANE KERR: I look forward to the RIPE Labs article that the person in the audience who heard this and was inspired is going to write. Thank you.
(Applause)

And now we have our final lightning talk by Jen, and this is ‑‑ I'm happy with this because, of course, it involved my two favourite subjects: IPv6 and DNS.

JEN LINKOVA: I'm just the messager, don't shoot me but I'm actually very excited. So, those of you who have been attending v6 Working Group sessions could go back to your e‑mails while I am talking on this slide because you probably have seen it. How many people using v6 only NAT 4 network here? Everyone else is asleep by now. So, I assume other people just do not know how to use it. It's simple. You have v6 only network and your client need to talk to v4, only destination and instead of doing this before translation which we all hate, we now translate it from 6to4. The trick is indeed how to get v6 address for v4 only destination and here is Shane's favourite technology comes into play called DNS, not just DNS, but DNS 64. The DNS is lying to you, it's telling you v6 address, well it actually doesn't exist in the zone, for example. The interesting thing is, in just dual stack network you already have this NAT 64 box most likely. It's the same box which is already, which is doing NAT 44 translation. Most of network equipment out there which could do NAT 44 translation, vendor box could say also do NAT 64. But DNS 64 is kind of tricky because it's a totally new element.

So, a year ago in Amsterdam we had a discussion, what can we do to help people doing v6 and how can we help people doing v6 only. And some people stay, I am a network person, I am a network person, I have no control over DNS. It's run somewhere magically, it magically happens. But I control over this router so I can do NAT 64 but I could not do DNS 64. Some people say I didn't know my DNS could do that, I had no idea. Some people say we don't run DNS, you run DNS, Google has public DNS server. I was, oh, can we do something about it? Can we help people?

So, five, six, a long time ago, we made our public DNS server available over v6 before the v6 ‑‑ so what we're doing now is the next step. Now we have, we just released Google public DNS 64. Please play with it. It's better. It's just been rolled out last week, we tried to do it before the RIPE meeting. There is only one currently; there will be more to follow. It is using well‑known prefix. And, again, it's DNS 64. I can believe you can do 64 yourself, you need a box which will be doing NAT translation but we can provide you DNS for this. Indeed we only translate publicly accessible names. If you have some tricky internal corporate stuff I'm pretty sure you can control your DNS.

So, there is more details about how to use it on our website already published. RIPE NCC was kind enough to set up a tasting SSID, which I think is going to work till after lunch. So you have time during your lunch‑break to play with it. It's been working for me quite well for the whole week. So, please try it.

And happy IPv6 transitioning!
Questions?

AUDIENCE SPEAKER: Blake [Witzeo], thanks.

SHANE KERR: All right. Short and sweet. You are dismissed, yes. Okay. That was our last lightning talk. Do you want to introduce our... the technology section?

So now we're going to have our normal RIPE NCC technical report which is always excellent so we have high expectations here. Let's see how it goes.

SJOERD OOSTDIJCK: Hi everybody. I'll be giving you the technical update for today.

There's been a pretty interesting week really. We started off a bit rough around the edges. We had some issues with the presentation remotes. And we tried the remote from the hotel people, which turns out that it only worked on one of the MAC‑minis, so to get things working we sort of got it together and we ended up with that mess, but it's working all week so we can't complain much.

And what do you know, before the actual sessions started, the new matrix switch that we bought for this meeting started to malfunction and we had to replace it as well.

On the spot, we had to sort of take it out and we put it on top of the flight case because it was probably a heat issue that was causing it to melt down. You can have a look at it at our tech desk, but the brand that we're using now, I guess I'm not going to recommend it.

The rest of the week was also quite interesting. One of the Terminal Room laptops died. Several Wi‑Fi access points started acting up. I guess they're getting a bit old, and we should start looking at something new. And as far as I know, last time I looked, Google still thinks we're in Romania.

On to some network statistics. You have been doing some IPv6 this week. The green line is the IPv6 and the orange is IPv4, and the black line here is added the v6 to the v4. So you have only been doing about 120 M bits on average, so that's not very much on the gig line, so I'm not sure where that went wrong and no nobody is doing any data but I suppose we're going to have to make do with our 1 gig line. It's not going to hit the 10 gig line any time soon.

5 gigahertz and 2.4 gigahertz clients. There's quite a few on 2.4 gigahertz and I'm not sure why. I'm thinking people maybe should change the ordering in their preferences, in their laptops so that they prefer the RIPE MPG SSID over the RIPE MPG 2.4 one. You will get a better service than you will on 2.4. And last but not least, this is what you have been doing with it.

I'm not sure what Apple update is. If anybody can tell me what it is. BitTorrent is less than I would have thought. But people are definitely encrypting their stuff by now, so that's good news, I guess.

This is the map like we usually show. We rolled out, I think 46 access points or so this time. And I hope everybody has been getting good service, we haven't had many complaints, so...

Then there is the webcasting, the remote participation. It's been less than previous times. I mean, normally we're getting around 150 viewers and now it's only gone up to 100 or so, so I'm not sure what's happening there. Last time we got some complaints about you know, stuttering on the video stream so we bought a licence to do variable bit rate you stuff, and hopefully it's been better for people. If you have a bad connection, you should be getting a lower resolution, and you know, things should have been smoother.

That's the team that's been doing it all the whole week. Of course, also, the lovely stenographers who have been doing a great job. And the people from the hotel, they have been really been great, they have been technically excellent and they have been a good help.

That's all.

SHANE KERR: Thank you.

AUDIENCE SPEAKER: About SSID with 5 gigahertz and 2.4 gigahertz. For me, 2.4 gigahertz works very bad with a lot of packet loss. So, that's why I use 5 gigahertz. Maybe for someone it's true, maybe not.

SJOERD OOSTDIJCK: 5 gigahertz should be better than 2.4, and the remote control that we have is also 2.4 gigahertz and there's some serious interference here in this area for some reason.

AUDIENCE SPEAKER: Ruediger Volk. You mentioned that Google did locate the network as being in Bucharest. Well okay, that's more confusing than the NSA perhaps. The interesting question might be the. What the Europol people thought the network is located in. And that's only partially a funny question.

SJOERD OOSTDIJCK: Do you know any of them? Could we ask them?

RUDIGER VOLK: We had people here and if any of those affiliated are still here, I really would like to have a feedback what they figure out of our databases about this network actually an interesting nice little exercise.

SHANE KERR: Anyone not from Europol, raise your hand. So the rest of you ‑‑ anyway...

AUDIENCE SPEAKER: I totally agree that people need to change the preferences any laptop and put performably NAT 64 on the top of the list.

SJOERD OOSTDIJCK: Yeah, why not?

ELVIS VELEA: I see you guys running headless chickens on Monday. Very good job. I just couldn't say anything that went wrong, although I know write a few things did, nothing was visible. So very good job guys.

SHANE KERR: Thank you for the presentation and thank you for the network.
(Applause)

This ends the portion of our meeting that has been organised by the Programme Committee and now we will hand it over to the Chair of RIPE.

HANS PETTER HOLEN: Thank you very much. So, the week has come to an end. And everything good comes to an end, right.

So, anybody know how many has been here?
676. It's actually not quite a record. We're missing two to be 70.

I have some prizes because it's important you register, and the earlier you register the easier it is to plan the meeting. As usual we draw the first three registrations after me who is sort of programmed into the system to be number 1, to it's number 2 is Will Hargrave. And then it's Brian, Brian Nisbet. And the third one is Sergey Myasoedov. So that's a small goodie bag from the Tivoli.

SHANE KERR: The PC would like to ask if the winners could put their code on GitHub so all of us could try next time.

HANS PETTER HOLEN: Okay. So, we're doing something write. 75% of you have actually come back and it's really good to see that we have good new recruitment in 25% newcomers. That's great.

We really want your feedback, so please go to the feedback forum and tell us what you think of the meeting. So that's something that we always look at, both meeting staff and me and also PC looks at your rating of the talks so that's also very important.

Right now, there is also the 2016 RIPE NCC survey coming out. So it was just launched now, so, that's something you can do on the airport on your way home or when you get home so you have time to think about this. Please give feedback to the RIPE NCC on their services and what you think we should be doing in the future.

So, looking at where you come from. You have actually come from 47 countries. For some reason, or it's actually good to see that not America is still strong in our region. If we zoom in on this part of the region, we see that we have 97 attendees from this region. From Denmark, Sweden, Finland and Norway. So, I'll have to work a bit on why it's so difficult to travel from Norway but I guess that's the way it is. And actually some from Iceland as well. I can't really see whether anyone from the Faroe Islands here, I don't think there is.

So type of organisation: Well, not quite half of you are commercial. 10% is from associations and education. 5% from Government. A chunk from our Stakeholder RIRs. And 14 percent who don't fit in any of these categories, so we can just speculate on what you are doing.

So, Sander, where are you? Sander approached me to make a statement from the BCOP Task Force.

SANDER STEFFANN: I'm speaking for the BCOP Task Force. You as a Chair made a nice statement during the opening ceremony about how to use v4 addresses and what the only sustainable way forward is. And, we realised that we all know this, but I don't think we have ever made a real statement about it. So, taking your words, I changed them a little bit to change them into a nice statement and I would actually like to ask the community if we can, as a community, stand behind the words of our Chairman and say, yes, this is the message we should send out there. This can help the NCC in communicating. This can help other people understanding what the situation is, because success spite what we all know a lot of people look at the graphs and think the NCC has address space, we're not really run out there is nothing going on here. I think this is an important message as a community we should step up and support.

HANS PETTER HOLEN: Thank you, Sander. I see the queues are lining up

RUDIGER VOLK: I suspect that actually a little bit more work on the language would be useful to actually convey even more clear message. I don't want to go into the wordsmithing right now but really phrasing the things so that it is absolutely clear that the start up first has to consider IPv6 and needs the support of a little bit of v4. That really should go into the wording because parties that are not intimate with the issues probably will read things different.

HANS PETTER HOLEN: I think that's an excellent addition, Ruediger, so I mean it will all be in the transcript what I said, here is the draft proposal. I don't hear any objections for this, but wordsmithing and getting the text even better is something that I guess the BCOP Task Force can work on further and then we can publish it. That's the advice from the RIPE community. Hearing no objections. Great. Thank you.

AUDIENCE SPEAKER: Hans Petter, there is a bit of a delay with the web stream of course, so, if a comment comes in from Jabber, would you still accept that?

HANS PETTER HOLEN: Sure. But the meeting is soon over. I can move onto the next item and then if you have anything, then okay.

So, how to replace the Chair? I described to you in the opening some thoughts I had on how to develop a procedure or what the procedure could look like. That's been posted in an article on RIPE Labs. I discussed a bit with the Working Group Chairs on how to organisation a discussion on this and we thought it's good to set up a dedicated mailing list for this, then it will ab separate archive and it's ease easy to separate the discussion from everything wells we're doing. We will set up a web page and mailing list for this and we will announce that widely. So I will sort of do a couple of announcements before we start the discussion to grasp as many of you who are interested in that discussion.

I sketched the timeline for you. I guess that timeline is probably a bit aggressive. It's been suggested to me that maybe we should not rush it but get it right, and I fully agree with that. So, this is probably something that we will actually discuss at the next meeting as well. But it's really good if we could get it rolling, establish the criteria for how the process should look like, like open, transparent participation, and then get the role description of the Chair right, so we know what we are selecting and get the selection procedure right. That's my sort of remarks on that. But this means that that balance is now rolling.

And it's not that I plan to run away, but this is sort of a procedure to make sure that you can select me if you want or somebody else if you want. I offered to stay on but it's actually getting this formalised for the future.

So. Thank you so our hosts. I think it's appropriate at this point to call Benjamin, Mike and Henrik to the stage for a small thank you and appreciation for the work you have done. There is a small gift for you as well.
(Applause)

AUDIENCE SPEAKER: May I add, as a hack‑a‑thon organiser, we had more help from DK‑NOG, Christian was on the jury of the hack‑a‑thon, he was working the whole weekend very hard to choose the best hack‑a‑thon contribution, to more thanks to DKNOG.

HANS PETTER HOLEN: There has been some changes on Working Group Chairs. Rob Evans has stepped down from the Routing Working Group, and we thank him for his many years of work.
(Applause)
And then I would like to welcome Paolo Moroni and Chairman of the Routing Working Group. So, this means that the Working Group collection now looks like this. There is an ongoing process in the Cooperation Working Group so if you are interested in making sure that the Cooperation Working Group gets the best POP co‑chairs because Meredith says she really would appreciate to have a couple of co‑chairs helping her out with that Working Group. That discussion is going on in the Cooperation Working Group list.

And then, the PC. And I think here there is appropriate thanks again, so if the PC members present here could actually come up. I would say that this has been an excellent programme, I have been really personally engaged by a lot of these talks and I think that it's really deserves some thanks to the PC for putting in a lot of work to not only pick the talks, but also to work with the presenters in order to get the talks as good as possible. So I would really like to thank you all, and there is a present for each of you as well.
(Applause)

And while you're up here I can also say a special thanks to Filiz for serving on the PC, there's now been a PC election and you have stepped down for now. Maybe we'll see you back sometime in the future. You are still on the Address Council, so you are still with the community. So we won't lose you. That's very good.

And then Jan Zorz has also stepped down. And we have two new PC members. Peter Hessler and Ondrej Sury, and Alexander has been appointed as an ENOG representative.

I mentioned that Jan has stepped down. But if we look at the composition of the PC in RIPE 600, there is, in addition to the members that you actually elect here at the meeting, there is a representative from MENOG and ENOG and one from the local host but we didn't have one from SEE. So the PC has proposed to add to the PC also a representative from SEE. So, unless there are any objections from the room, I hear none, so I see consensus from changing RIPE 600. So then I guess we can ask the Chair of the SEE to appoint a representative to the PC.

JAN ZORZ: So, thank you for making this fair. I think the representation of the regions in the RIPE PC is really important because it goes both ways, right. We will have a discussion at the SEE PC, but I presume for now, I will be the one that will take this role, but I need to go back to my PC and see how it goes. Thank you.

HANS PETTER HOLEN: Thank you very much. And thanks very much once again to the PCs.

Now, this meeting would not be what it is without the stenographers. So, a big thank you to the stenographers.


HANS PETTER HOLEN: I would also like to extend a thanks to the RIPE NCC staff, this meeting would have been possible at all, but without the excellent job from the meeting people and also from the technical people, as you already heard. But also a great thanks to all of you for making this meeting the experience it has been. And by that I think we have come to the ‑‑ oops ‑‑ not quite the end yet!

Secret Working Group.

HANS PETTER HOLEN: So thank you very much. That was the final words from the Secret Working Group. And I have nothing else on my agenda unless I have forgotten something, nobody is rush to go tell me. Would I like extend the final thanks to our new chief of meetings, I mean this is her first meeting, so, please come up.
(Applause)
And see you all at our next meeting in Spain. Thank you very much.