These are unedited transcripts and may contain errors.
Plenary session
Tuesday, 13th of May, 2014, at 11 a.m.:
JOB SNIJDERS: Welcome to our second session on Tuesday morning. The focus of these sessions will be mostly IPv6 and first of all, Chris Grundemann, if I pronounce that correctly, will present about debunking IPv6 security myths. He claims to have some knowledge about this novel protocol so I am looking forward to any insights you can offer. The floor is yours.
CHRIS GRUNDEMANN: Thank you. Good morning. I am going to talk about some IPv6 security myths, some things that maybe within this room and definitely outside of this room hold as common knowledge that just simply aren't true.
And this is a little bit about me, I am going to skip over this. The one thing I do want to point out is that I have never been accused of being a security expert, I am a network engineer and these are security things that I have picked up along the way. So I am looking to the security experts in the room to nod in agreement or disagreement and give me some feedback here.
And the talk itself, obviously we only have 30 minutes here so this is into the comprehensive IPv6 security tutorial or talk, it's simply a look at some of the most commonly held myths as I have encountered them over the last ten years or so in talking to people about IPv6.
Let's bust some myths here. The first one I think is one of the most important ones, which is the belief that I am not running IPv6, so I don't have to worry about IPv6 security. And the reality is that is not quite true and the reason is, that your applications, the OSes on the devices you are running are already using IPv6 in most cases. Linux, Mac OS, Microsoft, the new versions, virtually all the major OSes out there today are running IPv6, they have IPv6 capability and in most cases it's turned on by default. On your network today likely if you have paid no attention to IPv6 whatsoever you likely have IPv6 traffic on your network already. Someone, perhaps you, has probably spent a lot of time building IPv4 filters that match your security policy, and so if if you haven't paid any attention to IPv6 you have now kind of ruined that and allowed this massive hole in your security system.
Another thing is that in the new age of cooperate IT and bring your own device and mobile devices and phones and tablets, a lot are operating outside your direct control, if you say I can turn IPv6 off which probably isn't a good idea but a potential solution to this problem, if you didn't want to roll out, could you just say that, but then the bring your own device thing brings problems into that, it's very likely that these devices you don't have direct control over, perhaps not on your network but other networks and open themselves up to security flaws.
Beyond that, your users are also using IPv6 perhaps unbeknownst to them, a lot of very newer stuff doesn't have it turned on necessarily and doesn't prefer it but there is a lot of versions in between that do and so again you have built up this great IPv4 firewall that matches your security policies and comes along 6to4, Teredo, ISATAP, that is just going to shove IPv6 packets of any type through an IPv4 tunnel that you may or may not be able to see and recognise and again, your security policies are just gone out the window as you have allowed traffic to be tunnelled directly through your firewalls.
The next myth that comes up very, very often, I think it's one of the most frequent is that IPv6 has security designed in. And this is true for a couple of reasons, IPsec is required in IPv6, which is a good thing. But it's not new, right, it's already been back port IPv4 so it's available to us today and the fact that many people aren't using it has nothing to do with whether it's required in the protocol stack or not it's whether you are using it in your application. So granted IPv6 may give us some Ben fate because the stack requires it but the application still have to use it so it's no guarantee of security.
The other thing to consider when people say IPv6 has security designed in or that IPv6 is more secure than IPv4 is that in general, the development of IPv6 happened 15 to 20 years ago. RS C 2460 became an RFC in December of 1998 I believe. If you think back to the Internet of the late 90s it's drastically different and the security threats we are dealing with are vastly different, if you are relying on protocol designers 15, 20 years ago to protect you today, you are probably making a mistake.
One example of that is extension headers so they are actually I think fairly brilliant, they make the protocol extremely extensible in you can continue to add on as a predictable way to add features to the protocol as we move forward. But they also introduce some security issues. One of the first ones is routing header type zero which allows source routing and a node to determine or to pre determine the path that the packet takes as it leaves its interfaces, you can set up loops pretty easily there by bouncing pact around. Luckily it's been deprecated but there is still a lot of gear in the wild that supports it that isn't turning it off so these packets still exist and can affect your network potentially so filtering it is definitely a good idea.
The next specific extension header that could be a potential problem is the hop by hop options header, and that is an extension header that is required to be evaluated by every hop, node along the path. It also has unlimited number of sub TLDs that are not pre defined, and so the ?? and so the combination there allows for a very low bandwidth but highly effective denial of service attack where you can create these extension headers full of all kinds of nonsense, sub TLDs that have to be processed in order and therefore, you can consume CPU resource on remote routers fairly easily by sending these crazy extension headers on to packets in IPv6. Kind of describes the threat and some possible mitigations.
And beyond those specific examples, extension headers in general are fairly vulnerable to these type of attacks. You can stuff a bunch of bits and tonnes of extension headers on to a packet and all these things have thank have to be validated by routers along the way, potentially cause problems in the ability to knock things over, right?
Another piece of this of the idea that IPv6 is inherently more secure that it's not quite true is neighbour discovery and that is inherently trusting protocol. And one of the most impactable piece is router advertisements which is how you get default routes and prefix information into the network so there is a lot of important information and so of course if you are able to inject rogue router advertisements into a LAN you can perform man in the middle attacks and a do a lot of really interesting things on a LAN by doing had. The problem is documented in RFC 6104 and this kind of breaks down in my mind to almost a physical security issue because you have to have a node on the local network in order to do this so if you have to exploit a device on your network or add one, so this becomes less of an issue so once someone has access to your network this is definitely a possibility. And neighbour discovery message in general can be forged, router advertisement probably the most powerful as far as causing havoc but other messages as well, you can at least glean information if not cause effects and redirects work just like in IPv4. So there is a lot of things there that can go on, once you are on the local LAN that are things to watch out for.
And then the final thing that I can maybe even the most important part, when people tell you IPv6 is more secure than IPv4, is that a loot of the attacks we deal with don't have anything to do with IP at all. So buffer overflows, database type attacks, scripting, spam, even denial of service attacks, whether you are using NTP or just high bandwidth it's at the IP layer but it's version agnostic, it works just the same in IPv4 as IPv6 so changing protocols may have less of an effect, it doesn't increase security by changing to IPv6, you still need to pay attention to these things.
The next myth is that not having NAT in IPv6 makes IPv6 inherently less secure. And the fact is that the only ?? other than maybe some obfuscation of being able to hide some addresses, other than that, the reason that NAT may be perceived to provide security is network address translation requires state on a device and that means that incoming packets aren't accepted without outgoing state already established which means that NAT devices aren't inherently stable firewall and that is where the security comes from. And worse than NAT not providing extra security, it actually can be an attack surface itself, you can use application gateway functions and basically created a surface that can be attacked that is a single point of failure on your network, it blocks IPsec, DNSSEC, geolocation, it gets in the way of that reduces your security overall on your network.
This is a fun one. IPv6 networks are too big to scan. This is one that I hear propagated by even some folks who understand IPv6 quite well and the idea is that your typical IPv4 subnet has maybe you are using /24s, you have got 256 possible addresses, if you want to scan for devices, you run a ping sweep across 256 addresses doesn't take very long. The smallest subnet you are likely to find in IPv6 is a /64 which is about 18 quintillion addresses so, how many nodes can you fit in /64? My friend Jan is a favourite of asking, all of them. So how long does it take to ping sweep 18 quintillion addresses and there is stats on how many days and years and months and weeks that this takes, but the reason that is a myth is that you don't actually need to scan all of the addresses in most cases. So stateless address auto configuration is using your MAC address, patted out to E I 64 address and by using the MAC address and padding it out you have included the OUI from the manufacturer and there is only so many manufacturers, only so many OUI and many of them are popular and if you want to attack a Del device or Apple device or specific brand of router you can look for that OUI and scan the addresses that include that, so you have got a much smaller subset of addresses that you really need to scan.
DHCP 6 is often configured to start at address one or so or 100 and sequentially go from there, if you scan the low numbers you are likely to find the host. All of the auto tunneling mechanisms, you have got another subset you can man for. How many are randomising the addresses that they manually configure on LINX or do you use :1 and :2, I don't have to scan the whole range, I can scan the low numbers and look for that. Even worse if you are able to exploit a local node you can use neighbour discovery to find everything else. I only have to find one and I am able to exploit it then I can find all the other hosts.
And then one of the outside of IP layer effects here is things like e?mail sometimes leaking IP addresses out into the world so I don't have to scan at all, I find your addresses in other ways. So social engineering is another way to do this, right?
Another thing that comes up then when you are talking about addresses themselves, not so much on the scanning side but privacy addresses are pretty cool because there is the fear that because you are using your EUI 64 that you travel from network to network you can be tracked, so privacy addresses combat that by using MD 5 hash on the EUI 64 we gives you not be tracked by the websites and things that you are accessing over the Internet. These are often temporary, they rotate based on your operating system and flows or specific amounts of time. But the reason I see this as a security risk is it makes forensics a lot harder. If the clients on your network are jumping around from address to address establishing that trace back, that fingerprinting, that forensic pathway back to finding out exactly who is doing what is very hard to do. There is an alternative, you can use randomising DHCPv6 serve he is, rerandomise assignments, also on the host side use randomised IIDs and inside of your network you can still tell what is going on whereas outside the network there is randomised addresses and people can't track your users, so a potential solution there.
Another myth is that IPv6 is too new to be attracted. This one is start to go fade away a little bit, but somehow by moving from IPv4 to IPv6 you are going to hide under the radar, and the fact is we are already at script level of attack tools in IPv6. There is a link here to the THC, if you want to look a look at it, there is port scan tools, denial of service tools, they are all already out there. So all the tools are available and the newness is definitely ?? has definitely worn off at this point. There is bugs and vulnerabilities to get published and if you are not paying attention to those you will run into problems as well. Which security focus.com it has a cool list of all of these, the kernel bugs and all these things, all the errors in IPv6. There is a search string there that you can use and pull up basically a list of, as many and you as you want to read all of all these problems and most have been patched but if you are not running new software potentially issues in your network.
This is another fun one, so 96 bits ?? more bits no magic. So kind of just like IPv4, from my engineering network background this is true. When I turned on IPv6 on backbone networks routing in IPv6 is not that much different than IPv4, it kind of is just 96 more bits with no magic. When you are talking about security and you are thinking about things like logging, gripping your logs, filtering things out, 128 bit addresses versus 32 bit is drastically different as far as what you are scripting for and looking for. Hexadecimal versus decimals, colons V periods, so the same address can be represented in multiple ways based on zero suppression and compression and if you are trying to do forensics, definitely the filters and scripts and things you have written for IPv4 absolutely won't work because the addresses are completely different and there is some different mind sets you need to go into when doing these things.
And then of course also in IPv6 it's fairly common ?? it's basically across the board, every host is going to have multiple addresses which of course if it shows up in your logs with different addresses it's harder to identify that that actually is the same host, where in IPv4 we really don't have that problem, typically just one address used for communication. It's very simple.
The final bit of this is syntax changes, in many cases they kind of rewrote everything, which is in some cases is good because a loot of times there is IPv6 implementations that are better because they learned some lessons, the syntax has changed in a lot of cases, so different commands, all the things you have learned shorthand to be able to do, quickly run through and do your work have changed so you need training and people who don't understand the syntax, that is opens you up to potentially security issues, all just fat?fingering issues and those kind of things.
This is one that I have actually been guilty of propagating, which is just to say oh, configure IPv6 filters the same as IPv4, so the higher level statement of make your IPv6 policy match your IPv4 policy from a security perspective is probably true. But as far as making the filters the same, not quite. One of the reasons is DHCP 6, you are using link local addresses, you are using ICMP, in a lot of cases people have just blocked ICMP in IPv4. If you do that if IPv6 you have broken your LAN, you have killed neighbour discovery and things just don't work.
Here is a quick example. Rules one and two there are the stateful issues. Rules zero is what is required to allow a neighbour discovery to work, and rule 3 is one we stuck in there to to actually allow the device to see the reply for DHCP advertisements.
Another myth, that this is one that your suppliers, your vendors, people like that may tell you, it supports IPv6. And in a lot of cases it doesn't. There is still a gap, a feature gap, especially in security appliances, a lot of IPs don't dig into tunnel protocols, and don't support IPv6 fully not in the same way they do IPv4. Kind of across the board. Host based anti?virus is catching up but a lot of it still blocks IMC P and doesn't support IPv6. Firewalls, which is kind I have a cross the board. You need to make sure you have detailed requirements and don't say it doesn't support IPv6 because there is still people answering, if I can put an IPv6 address tonne it supports IPv6 and obviously that is not the the case. RIPE 554 is a great document that describes the whole list of supposed security and non?security features that you are going to need in IPv6. And then you are examining to want to do lab testing and independent verification to, meaning feature party with
Another myth there is no IPv6 security best current practices, and there are. There is also ?? put out some guidelines. There are some gaps, a lot of security documentation hasn't been updated to include IPv6 yet but from a high level security policy is probably the same between IPv4 and IPv6. I am mot going to read through all of these but there are some general best current practices you can use in IPv6 and in many of them are the same, at least from a policy level as IPv4.
And finally there are no IPv6 security security resources which isn't through. A great book is IPv6 security. There is also a list put out some guidelines for the secure deployment of IPv6, the deploy 360 has a section specifically on IPv6 security that is currently growing. Search engine is your friend, no reason not educate yourself on IPv6 security and protect your networks on an IPv6 world.
So, kind of the take away here is you really are dealing with two separate protocols, just like on the wire they are incompatible, you need to look at that time as two sets of filters and bugs and and they need to be treated with that weight, right. Understanding that it's not just incremental change, it's a whole new protocol you deployed.
With that, I would be happy to take any questions in the last couple of minutes.
BENEDIKT STOCKEBRAND: A couple of things. IPsec by now is optional again because it's kind of tricky to implement in imbedded devices. That was the reason about it. But you should actually have it in most implementations except of course, these import/export use, whatever laws on crypto and various countries so that can be a problem. When it comes to rogue routers they are generally easier to detect and deal with than rogue DHCP servers which produce pretty much the same problem with IPv4 because except in cases like ?? there is ?? which can actually help you figure out what is going on there if if you are on wi?fi network where you can't do this at port level. When it comes to link security, if you put machines that are supposed or allowed to do different things in the same subnet you already make a mistake and these pretty much nothing you can do at that point because tackle just your Layer 2 and IPv6 doesn't have to do anything with it any more, and when you said the link ?? link local multi?cast to use for scanning the network, Microsoft, depending on if you say trusted network or not will sometimes not respond to pings on that address which can be a major pain the ass if you are on the ?? not the attacker size. When it comes to tracking addresses through DHCP you might also be able to do at the router level if you track IP address, MAC address associations there, might actually work in some cases but I don't even have any reliable implementation on that.
CHRIS GRUNDEMANN: Thank you.
AUDIENCE SPEAKER: Christian Russell, free university Amsterdam. I have actually, reluctant to say these are all myths, actually I would just defend two of these, one being that IPv6 is easy to scan. So this may be true right now where you have like most really addresses assigned like no numbers and all this stuff but depending on the defender model this may change in the future, especially with privacy extensions and randomised THCP, I think then it becomes tricky to scan IPv6.
The second is that I do think that NATTing actually secures hosts, so we do see that there was this ?? back then that many systems were not NATTed. There is amplification hosts like all this Windows based systems that you can also abuse because they are not NATTted. I agree that it's mainly a firewall issue that you can also rebuild again IPv6 but if you just deploy IPv6 without thinking about it, without NATTing, then I think it's really security critical.
CHRIS GRUNDEMANN: I think that is fair. Yes. Thank you.
AUDIENCE SPEAKER: Jen Linkova. I think you have scared people enough. I wonder how many people have changed their mind about deploying IPv6 after your presentation. And actually most of my comments have been said already, one thing I'd like to mention is actually, yes, most of new possible attacks, I again related to Layer 2 so if you have someone next to you you are already in trouble and just because IPv6 introduce some new functionality, you might get some new attack then but it does not mean IPv6 is less secure. You mention DHCP 6 as way to track what you are doing. It's not actually true because if you have malicious machine in the network you can give 6 address, it doesn't mean they are going to use it. They can still do whatever they want. And it just might give people false sense of security.
AUDIENCE SPEAKER: Philip, RIPE NCC. To scare away people even more from IPv6, there is one thing that you didn't mention, and that is now because we don't have 256 potential nodes on a subnet but the ?? if you just start scanning them then you can easily overload neighbours' caches and unless the router happens to have the protection against that it might be worth pointing out to people to look for that, otherwise they provide a very nice DOS opportunity.
BENEDIKT STOCKEBRAND: Just follow up on the problem with remote scannings, you can sort out these problems if you put some work in there but it's painful, OK that is problem we have with IPv6 because large address space but pretty much all other problems you could ask what is the equivalent problem we have with IPv4 and pretty much every time except for this one case it's decidedly worse. It's just something to keep in mind. Especially if you have to deal with people who are not that familiar with the way IP works, because those are the people scared off I don't think it would scare off people here in this crowd but I see that with my customers a lot.
JOB SNIJDERS: One last question.
AUDIENCE SPEAKER: In the slide about IPv6 is too new to be attacked you mentioned several tools like the S.I. 6 excellence tool kit that already exist, yes there are tools but from my experience there are very few attacks today, not because there is one fundamental reason in IPv6 sort of for it to be safe, but because in practice, most of the customers today are still using mostly IPv4 which is my first spam over IPv6 less than one year ago, I believe, and it's a typical example if you put SS D server with logging passport route on the Internet of IPv4 it will be ? in five minutes. One over one for IPv6 for two years without even one attempt so it's a good example the difference between the theory and the reality. Attackers are pragmatic, they are conservative, they reach for the low hanging fruit so there is no fundamental reason why there would be ?? why IPv6 would be safe, IPv6 ?? but in practice today it's true that the people, the good guys are not used to IPv6 which can be seen as vulnerability but the opposite is true also so you also need to train the bad guys to use more IPv6.
JOB SNIJDERS: Thank you all for the questions. Thank you, Chris, for raising IPv6 security awareness.
(Applause)
There is one important task for you as an audience, which is to rate talks, which provides feedback to the Programme Committee which we then can use in successors of this meeting.
Rating talks you can acomp accomplish by going to RIPE 68.ripe.net. You have to log in with your RIPE access account and if you click the second block on the Tuesday morning you will see some rate buttons next to the presentations. Please rate talks.
SHANE KERR: So our next talk is Dave Wilson and he is going to be talking about something near and dear to my heart which is what went wrong with IPv6. So...
DAVE WILSON: No pressure. I have a problem. And to describe this problem, and try and get your help with solving it, I am going to give three lightning talks, five minutes each, I hope we can solve it, and the first lightning talk is: What went wrong with IPv6?
A couple of years ago, my boss asked me the question, why do we keep IPv6 turned on? Why not turn it off? Now, let me explain. My boss is not an IPv6 sceptic and I am not, I've been up here enough times and you have seen me with all the talk before. You know where I stand on this. And my company is definitely not an IPv6 sceptic. But I had no answer. And the reason I had no answer is, we have been working on it and I personally have been working on it for over ten years, it was ten years a couple of years ago and at that point the numbers should show something you can point to and say here is a trend. I went to look at the numbers, RIPE does a lot analysis and routing table shows you things on an ISP level, let me show you what is going on inside ours. I took a look at how many assignments we have made to our clients, this is third level institutions and other institutions, it doesn't count the schools, second and first level schools.
We have about 60 or so of those clients, all told, and we had a burst of activity at the beginning of the century, which is fair, and then it levels off but that is OK because our client base is very stable and it looks fine but how many of those are actually being used? Now that can be quite tough to tell because in some cases you might have a very large deployment and other cases two students somewhere and it can be tough to tell the difference, one easy way is how many of those are in our internal routing table and at the end of last year it was in around half.
And it gets even worse because if you look at how many of these were tunnelled or when they were tunnelled we introduced tunnels in 2001 as a service as a transition mechanism and the people who had still using it had gotten hair assignments then and if that is meant to a transition mechanism it maybe helped in the past but wasn't doing it now.
It also became clear to me because I looked at numbers from other networks and these numbers aren't good but they are not atypical. And after ten years, this was all I had to show for it. And I realised that the problem I had and the difficulty I was having answering the question was, I have stopped understanding the problem that we are trying to solve. I mean, I understand of course we have the good Internet and the bad Internet and we want the good Internet and we can't do this with the IPv4 addresses that remain, which don't any more. And if we end up with NAT all over the place, which we already have, then it's going to be tedious and difficult and it will be like dealing with spam and something you will eventually outsource and distracts you from real work. But that is is a justification for the entire Internet being dual stacked. None of that is a reason for any individual site to put the work in. The reasons for people to put the work in are so to solve their existing problems and they have existing problems like I have clients perhaps who want IPv4 PI space and I am sure you do too. Some of yours may already be exhausted, mine will be one day and what do you way to new clients? Do I go great I am glad you are joining us, did you bring your own addresses? You didn't. What do you say? Do I say this: Yeah, you know, this doesn't solve the problem, does it?
And I was looking at all this and going this isn't a case for continuing to work on IPv6, there ?? I don't see the way to get from here to there, this is a case for turning IPv6 off. And part of the problem, I thought, yeah you think the last girl was frightening the people away from deploying IPv6 ?? part of the problem I realised the arguments that I was using over time kind of breakdown into two arguments and the first: If you don't support IPv6 the Internet is going to stagnate, it's like the ozone layer, we need to do something about it. That is fair enough and true but it doesn't convince everyone. People who aren't convinced, I will go if you don't deploy IPv6 you will be left behind.
Do you see the problem? They are contradictory. They are both justifiable in certain ways and as far as they go they are both true but they are both kind of extremist positions and I think they have stopped convincing anyone remaining to be convinced.
And while I was ?? I kind of stopped talking about this for a while and went into my shell and I was going, what are we going to do here, because I don't want to stop here and say the right answer is to drop all this because the results are too horrible to contemplate and I saw this quote and it was on a completely different subject but by an editor of books who gets submissions from authors and authors are very fond of the books and sometimes they react quite badly when they are rejected, and they said this: She said "it all becomes clear why they react about this if you think about it with your reader mind instead of your author mind." Authors with books are like mothers with infants. This has its good aspects because books like infants need someone to unconditionally love them to and to champion all their causes but there can be a form of blindness. I realised, of course, I have become so convinced of the necessity of v6 that I was ignoring all the faults in our strategy to get it deployed and I tried to step back and think with my reader mind of someone who is using IPv6 to try and get a job done and as I was reaching this conclusion, without me doing anything at all, what went wrong with IPv6 started to go right, World IPv6 Day happened, Facebook deployed it, Akamai deployed it, and then some of my own customers turned around and managed to justify it and started making real meaningful deployments that we could measure and see. But I am still left to wonder if that is sustainable or just another plateau. I have seen ?? I felt that burst of enthusiasm before aye wonder if we have something that is very self sustaining.
That is the first lightning talk.
The second lightning talk is about disruption. Disruption is a word that is unbelievably abused in our industry, almost as badly abused as cloud. It turns out it actually is an academic term with a very specific meaning. It comes from a researcher called Clayton Christian, that is page turner. And what he was trying to do was he noticed that there are certain types ?? certain businesses and it was not clear what types, that are by any decent management theory very well?run and listening to their customers and doing everything right and they fail. And why do they fail? And he wanted to try and expand our knowledge about this and he started researching. And he decided to study of all things, the hard errs strive Friday. Why did he pick that. He had a friend who was a geneticist and this friend said if you are going to study genetics, you don't study them, they live too long. If you are going to study, you study fruit flies because they die quickly and if you are looking for a sector in technology where the companies die quickly look at hard drive manufacturers. And what he discovered is that there is two types of innovation, and this sounds all kind of weird and out there and cloudy, but there is a very simple distinction between them. He drew a graph like this and said time on one axis and quality on the other, let's say capacity of a hard disc and he looked at the 8 inch hard drive manufacturers and what he saw was, they started with a certain capacity and over time, for the same price and for the same ?? same device you could buy, the capacity increased. And the reason they are increasing was the manufacturers were ?? the vendors were continuing to innovate, making changes to their processes and technology and getting better and they had to do this. People were sustaining innovations and the they are called sustaining because every one of these is unambiguously is better than what came before. They had to do this because the customers were also demanding improvements over time and the customers are digital equipment corporation, they are the makers of mini computers. And along comes a new technology which is five and a quarter inch drive and it looks like that in the graph. It's worse. It's more expensive, it's slower, it's got less capacity, it's got less capacity in a drive, the only thing going for it is it's smaller form factor. And these guys didn't want that. Why would they ever be interested in it?
And that is the definition of the disruptive innovations, it's worse than what came before. Why on earth would anyone want that? Well it turns out that is very important because what was going on with the 8 inch drive manufacturers was they were listening to the customers but their whole organisations were built around these things up here: Whole organisations were built around the things that they knew how to do and the things that they knew worked and the engineers who might have been working five and a quarter inch drives kept getting pulled away to fit fires for their big customers and the salespeople were the rolodexes full of customers, we are not interested in these slower drives, keep doing what you are doing, why would we ever want to get into this industry, the whole organisation was physically unable to change to do these things. Everything they had that made them a well?run company was telling them don't touch it, which meant it was left to new entrants to come in and find a completely different market for that technology. And so they did, and that market was the personal computer market.
Now, it becomes pretty clear what is going on because we know this market becomes far, far bigger than the mini computers. It's even worse than that because it's even worse than that because these guys also developed their own sustaining innovations and that means that the five and a quarter inch drive gets not better than the 8 inch drive but good enough. And as soon as we hit this point here, it's too late, within a year the bottom falls out of the 8 inch drive market and this has happened over and over again and it's far too late for the incumbents to adapt. The only guys are making five and a quarter inch drives packaging 8 inch.
And this is ?? this applies to an awful lot more than just hard dis, it applies outside what we know as traditionally technology. This JCB, the mechical diggers are disruptive innovation because they used hydraulic pulled buckets instead of cable and at first they were worse. If you look at it, that kind of tells you why Microsoft is winning to annoy all its existing customers with Windows 8, because there are existing customers, that is us, are misleading them into what is going to be needed in the future.
That is the second lightning talk.
The third lightning talk is about how we can use the second lightning talk to solve the problems in the first lightning talk. We have got two inch nets right now, one is good enough and one is not. We have this general Internet use. What is this? Is it something there that we can use to make the IPv6 Internet self sustaining and self growing?
This comparison only works if certain conditions hold true. If these things aren't true it's not disruption, it's something else. And this is where I want to be specific about the definition. If your new technology is not in some way worse than what came before, cheaper, faster more convenient, then it's not disruption. So to try and kind of solve this equation, I go: Where are the areas where IPv6 meets these conditions? Are there any, and if there are, that tells us where to focus. What that really comes down to is, what can IPv6 do that IPv4 can't? Don't panic, I don't mean on a technical level, we also know v6 is a packet header on a wire and does the same thing, it's just the flavour of the heard. I don't mean either things like some of the theoretical advantages and myths we heard about in the last talk. If only IP Sec. I mean what is there out there that a user might want or a developer might find convenient that is easier for them to manage or would be easier for them to do what they need to do? To solve this problem.
And I think then the question sort of boils up like this and this is what I want to spend the rest of the session discussing, is these kind of questions: Why are we try to dual stack the entire Internet as we know it when it actually works. Not very well, but it does work. Is it because that is what we know? Is it because that is what we measure? What else should we be measuring? And what should our success criteria be that would tell us whether we should be working on what we are working on today or if there is something else we can grow from.
I don't know the answers, and that is why I have a problem. But I have one example of how we might be able to get out of this without initially trying to dual stack the entire Internet which is of course a very difficult problem. There is a home screen on my phone. How many of these could run on IPv6 only.
The thing about iOS development as an example, and this is just an example, is developers don't care about the network, they don't care about v4 or v6. I know, I have checked, I have asked them. I was at a conference just two weeks ago of about 200?odd iOS developers, I got a slot, I gave a talk and gave them the whole IPv6 you might want to look at this and I was doing you guys are renting your IP addresses off Amazon now, you are renting them by the hour, you do know what happens to rents in a time of scarcity, they were listening and very polite. What is their alternative? This isn't what they do, they are working towards API, the OS provides certain and the services they use to deploy the back ends provide certain APIs and they are just buying a product. So I am looking at this and going OK that thing maybe uses v6, I am not sure, it's quite possible. This one probably doesn't but almost certainly it could be because it's only interacting with one website. This is just interacting with a back end service. That one weather app is interacting with a back end, that one with a bit more of the Internet, but again podcasts are concentrated in many ways. You could hit quite a lot of that with just v6. These are things where if someone went in to sell the right kind of product and if the end users were provided with the right kind of product and connectivity we could get a quite serious deployment without actually having to dual stack the entire Internet at once. And we would get the tools in place and the business model in place that might actually begin to grow.
And that is why I want to raise it here. I think we have been spending a lot of time looking at the existing Internet as our success criteria and I think it might be the wrong success criteria, I think there are others we are look at and maybe it's to do with buying things from Microsoft on line or Amazon or whatever, I would love to hear what you think. Thank you very much.
(Applause)
SHANE KERR: All right. I am on the Programme Committee obviously, and when we got this presentation I was a bit nervous. But also really happy to see some kind of honest doubt about where we are at and it wasn't until Dave walked me through this yesterday or the day before yesterday, where it actually, really clicked in my head and I think it's really interesting approach to say let's find a sustaining, would provide sustaining innovation. I don't know who was first.
George Michaelson: That was a lovely pack, sneaking up on us with a nice graph about something we can relate to and sliding the new labels under the lines. Very clever. As you know at APNIC we do a lot of v6 measurement and we have seen two or three different classes of 6 deployment emerge. There is the ones ones we just can't measure properly, two small samples or very wiggly because they are behind the great Wall of China. We have got the 6 RD people in France and Romania and grease and other economies and they get amazing rapid deployment and it flat lines, 15 or 25% and there is something going on about transition technologies, it may have an aspect that relates to something you said about tunnels, some of the things we thought were a good idea seem to have limited life. But there is a third kind, the LTEs, the legacy frees and they are going gang busters, they are surging up, it is an amazing rate of uptake, they are heading for the blue sky and they don't have a concern. And it occurs to me that there is somewhat overlap between the sense that the LTE legacy free space is going where it wants to be and the slide that is standing behind you on the screen. Because LTE space is not about people hitting key boards, it's about small devices. So when you talk with the AP developers you may be need to be saying to them you are in an interesting place. Yes you are all CGN agile and living with NAT, your target device is legacy free and you could be doing amazing things. Anyway, lovely talk.
DAVE WILSON: Thank you. On the desktop this is far and away the single most application, the browser, everyone using the browser all the time. On mobile, here is where it is at, that may be a simpler problem to solve.
MARTIN LEVY: I am a recovering ?? never mind. George basically took part of what I was about to say, but I am going to readjust your premise slightly. On the screen behind you, and I am going to pick on one particular icon next to your nice green circle is the Facebook circle. Exactly what you just said, the ?? thank you ?? I wish I could do that with other presentations ?? edit on the fly ?? so Facebook took API.facebook as a URL and made it v6 enabled very early on. It's not a URL that you ever type into a browser. You use it behind an app, and that, by being v6 enabled, was able to give the carriers, and that is where my focus is going to be, the ability to move bits on a v6 path which should be more efficient than a v4 path and as we go forward, should absolutely become more efficient than a v4 path. That, to the carrier, is where the pitch should be. To the developers, there is no doubt about it, use the right tools and right libraries, we have all now learned that if you write your code right it's just v4, v6 agnostic and it's very hard to talk to developers about this but it's much easier to talk to the back end cloud providers and to the carriers, especially in the mobile space and say this is has a value to you. The end user, the consumer, you are a smart user, you know when you are hitting a button but to the near billions of end users they shouldn't know about v6, and most of the developers delivering them stuff should just be doing the right thing and it shouldn't bother them and that is where we are seeing this uptake that George can measure on new networks with new apps where the browser butt son just inconsequential. So the pitch is good, it's just slightly the wrong ?? slightly the wrong people.
My other second comment is, if you took the v6 out of this talk, it makes for really good tech talk ??
DAVE WILSON: 80 minutes long, yeah?
MARTIN LEVY: You have got to work on that part, but yes. That is my pitch, just change who you pitch to and go after the middle land.
DAVE WILSON: One really important thing what you say about developers and applications, applications it's now clear to me are not bundles of code, the bundles of code in the back end service and both of those are not looking at CA PIs any more, you are looking at certain interfaces and all those have to be ready and someone else other than developer can worry about that.
OLAF KOLKMAN: I think this is in line with previous two comments, excellent presentation by the way, I am stunned. The two lines that you showed of new worst technology, so to speak, building up and that being a driver for something new, micro computers and the PC, the personal platform, is it that case that what we see here is a move from ?? away from the general purpose computer to this very verticalised type of service that we offer through the app, that is causing this particular, it might be at the root of a particular disruption?
DAVE WILSON: OK, part of the problem with disruption, you don't know what is happening until it's too late. You are kind of taking guesses. A part of me is almost sorry I put this slide up because it's as example and I think it's almost certainly the wrong one but there is something going on with mobiles, it seems clear to me whatever ?? what you see with PCs and tablets and mobiles looks like disruption to me, it clearly looks like disruption to Microsoft because that is why they did the whole business of windows 8 and they are trying to make that shift and that if we keep aiming for the Internet that we know and love and see through our browsers, then it's almost certainly the wrong target. This is probably a better target, maybe it's the right target. I don't know. Maybe it's too late already. I think a lot of servers around these are already bound in. Maybe we immediate to look for another.
NIALL O'REILLY: That is kind of fuzzy question that I haven't ?? University College Dublin ?? my employer is a customer of Dave's employer. This is a kind of a fuzzy question that I haven't really thought proper how to formulate but I will give it anyway in case it prompts any ideas from you, Dave. It's this: I am wondering if, underneath what you are saying, there is the message that if it's not disruptive, it's not a transition, and that if we are aiming at continuity of service with sliding into v6, we are probably not going to see the transition that we think we are aiming at.
DAVE WILSON: I think I agree with the second half but not the first half. I think that ?? I am kind of very sensitive to all those ambiguous and clouding and incorrect uses of the word "disruption". I think there is something to be learned from it but only if you can show that it's really what is going on or if it has those characteristics and if it does, there is lessons you can learn. I could rabbit here for about an hour if the speaker wasn't going to yank me off stage. The reason I characterise it in that way is because dual stacking on the Internet is very hard. And it's clearly a transition and it's not a disruptive transition if we do it like that because as you say, you are trying to keep everything at least as good as it was before, or better. But we can probably use some of the lessons from disruption if we take another tack and the transition doesn't have to be like that but if we can make it like that or if it turns out like that, there is something we can do there. The buzz word I am trying to use here is, the phrase I love is competing with non?consumption. If we try to dual stack the entire Internet as we know it right now, which by the way is something that is eventually necessary but not sufficient, and I don't want to chase people /TPRAUF existing their ?? how to make that sustainable. But if we ?? if we dual stack what we have, then we are competing with IPv4, and that is really tough because IPv4 has been very, very, very successful. What we want to do is compete with an area which isn't served by IPv4, and that is some way we can kick?start something that becomes self sustaining. That is what the theory is getting at. Does that answer your question?
NIALL O'REILLY: I am not sure, I need to think about it and I will catch you over lunch or coffee or beer.
SANDER STEFFANN: A great talk. You were talking about disruption and like you said, disruption could be like the kick?starter to actually make it widely deployed. If your known is connected over 3 E, L T G wireless and you are competeing with v4 in that area, I am wondering the mobile market might not be usable for disruption any more, I am really wondering what might really be disruptive and it would be something that you could do in a smaller environment where you don't need the whole Internet to be dual stacked because that is not there yet so that is going to be difficult. So I was thinking about like, in?house solutions for inside the business or inside the house or whatever but something that where you can quickly start using v6 without being hindered by v6 not being available by your access provider and go on from there. So what would be a real place where you can start this disruption, if you want to use it?
DAVE WILSON: It's a really tough question and if I knew the answer it would have been a topic of the talk. The reason I am here at this time, there is 500 very smart people in this room, I am hoping to talk about this over the rest of the week.
BENEDIKT STOCKEBRAND: We already have sort of problem like this or situation like this, but two or three weeks ago we had a discussion in a general mailing list where somebody pointed out that a company called Zipgate who is building 8 inch hard disks, basically they are doing zip on IPv4 and IPv4 only, and they had a block post telling people that, well, if you are with a cable carrier and/or ISP and you get ?? our service doesn't work it's because they screw up because the IPv4 doesn't work and it's their problem and not ours. You might try so?and?so but obviously you couldn't possibly work but, which is kind of like what Martin says to the end customer it doesn't matter, if it's IPv4 or IPv6, the question is does my phone work? So we already are at that point where we have companies who are just about to kill themselves with this sort of attitude and way of doing business. We will see a lot of this happen in a very short time, very soon now, because there are the cable ?? cable TV ISPs who have no longer an option to do proper IPv4. They have to do CGN and whatnot, and the numbers there will be increasing and then things will sort of tip over. It's a bit like chaotic system where all of a system things go drastically wrong. We are heading exactly that way.
DAVE WILSON: I agree.
SHANE KERR: On that depressing note, I'd like to thank Dave once again.
DAVE WILSON: Thank you.
SHANE KERR: Very good.
(Applause)
JOB SNIJDERS: Next up is Andra Lutu if that is the proper pronunciation. Shell talk about IPv6 visibility in terms of prefix visibility and whether data arrives or not. Don't forget to rate talks. Go to the website. Log in with your access account and press the "rate" button.
ANDRA LUTU: Thank you for having me here. Thank you to RIPE RASSy for the initiative which made it possible for me to be here as well. Today's talk is mainly concerned on the correlation between IPv6 prefix visibility in the Internet and reachability.
This is actually joint work with my advisor from university Carlos of Madrid, Cristel Pelsser from IIJ and Olaf Maennel from Loughborough University.
So the main task of the Internet is to provide connectivity to every node attached to it and to make sure that traffic flows from every point A to point B. The way that traffic flows is usually influenced and manipulated by the routing policies that routing network implement and tweaking their BGP configurations.
Now, the implementation and configuration is not an easy process and you probably know it much better than I do. So, it's error prone and sometimes misconfigurations happen that impact efficiency and efficacy. Not only that, where they are correctly defined and deployed, the complex interactions between all the entities playing this game in the Internet may lead to cases where the routing ?? preferences of some networks are not respected.
So, what we have seen and what we have found is that these type of backfired routing policies or misconfigured routing policies can impact the visibility of prefixes in the Internet and to further define prefixes visibility, what we did is analyse BGP routing tables, global BGP routing tables. So by checking and by cross?checking the content of global routing tables over the ASes in the Internet we further defined limited visibility prefixes which are basically prefixes that are not contained in all the global tables.
The question that we ask today and trying to answer is how does this limited visibility of IPv6 prefixes impact the reachability of the addresses contained there. And mostly we are concerned about this in the last years there have been several complaints of global ?? on the global connectivity or better said, on the lack of global connectivity in the IPv6 Internet. How do we go about answering this question?
Well, we first built a tool which is the BGP visibility scanner for IPv6 that helps us monitor the prefixes visibility at the inter?domain level. We get on a daily basis of all the set of limited visibility prefixes. We then propose a methodology and put forward an idea of how to measure the reachability of a prefix in IPv6. We take this methodology and we actually test the reachability of the identified limited visibility prefixes. We do so both locally from only one single machine and also globally using the RIPE Atlas platform.
Now, the BGP visibility scanner is a tool that we have created. We are currently maintaining and it's available to you all. I strongly encourage you to use it. It's available that link there. I am not going to go through all the details of the methodology behind this particular tool, if you have any questions, doubts, please feel free to look me up in coffee break, I am going to be more than happy to answer any of your questions. However the main idea to take away from here is we analyse a massive amount of BGP routing information so we take all the BGP routing snapshots from RIPE RIS, we clean up the data and we take only the global routing tables. And then we apply what we call visibility scanner algorithm. What this does is basically apply 95% minimum visibility threshold rule so we label all the prefixes that are visible in more than 95% of all the global tables we have in our satchel as high visibility and contrary?wise, we label the rest as limited visibility. We cross?check to see how these two sets overlap and we further identify a subset of limited visibility prefixes that do not have a covering less specific high visibility prefix. We call these prefixes dark prefixes.
Now just to get an idea of how expanded this phenomenon is in the Internet. We currently this makes about 16,000 IPv6 prefixes which we break down in high visibility and limited visibility. We see about 20 are limited visibility. However, 14% of all the IPv6 limited visibility prefixes are actually dark, do not have a covering less specific prefix with high visibility. This is five times more than what we see in IPv4, where only 3% of the limited are dark prefixes. And in terms of who are the ASes that are actually generating this, we find about 1,000 v6 active ASes that are injecting the v6 limited visibility prefixes and out of this 40% are suffering from having dark prefixes.
Now, probably by this time you are wondering why do these limited visibility prefixes emerge. And probably you know it much better than I do so feedback is more than welcome. Now, the tool as I said, it's been out there, mostly running for IPv4 since probably one year?and?a?half now. So we made it available in November 2012. We have invited operators to give us feedback using the web page, and tell us about what was the actual expected visibility state of these prefixes. Which we then cross?checked, compared what we saw in the BGP visibility scanner. Also, by coming to these type of places, to NANOG or SNOG or UK?NOG, publishing articles in RIPE lab and so on we can establish an interaction with operators, helping them to kind of debug their routing policies and us finding out what went wrong. So we kind of got the ground truth on about 20,000 limited visibility prefixes, again these are IPv4, so what we are looking for here today is insights for IPv6, and stories about IPv6 limited visibility prefixes.
So a few examples: We have identified a class of limited visibility prefixes which we call intended, basically these are limited visibility prefixes which are genuine expressions so the original is intended for this prefix to have limited visible. So for example, we saw the case of a content provide erring during geographical scoping using BGP communities, we saw prefixes injected only to some peers and not to providers, so in that case obviously the visibility was restricted. And second class of prefixes that we have identified where the unintended so where the expected visibility start to ?? was not the one that BGP visibility scanner was showing. So in this case IS operators were suffering from back fire routing policies, misconfigurations and so on. So in had this kind we found a staggering number of 18,000 prefixes, which we dealt with, eliminated and so on. We have learned about the case of a large ISP accidentally announcing 40,000 of routes to direct peers due to misconfiguration. One very surprising case was the case of an ISP who was surprised to find out his prefixes were dark because of a misconfiguration in the routing policies of his provider. And also, we have learned about a few prefixes that do not have an object defined in the routing registry database and got filtered by other ISes so these are just a few examples.
Now, let's go back to the question that I asked before. Now what is the correlation between the visibility of prefixes and their reachability. So the idea we put forward in order to test the reachability of these prefixes, is doing trace routes. So what we do is take a random address within a prefix, an IPv6 prefix, which is massive and we ran an ICMP trace route. We analysed the results and extrapolated these results to the entire prefix. What we see is that the target IPv6 prefix is reachable if the trace route probe made it to the IS to which the prefix has been allocated originally. Also, we consider ?? also the target prefixes reachable if the trace route probe traverses second last IS along the BGP IS path so if we look at this picture, we are sampling the routing table of IS one which is our source from where we run the trace route and then we look ?? we try to reach the destination, the IS4 which is there in blue. So if the trace route probe makes it to the red IS, then the conclusion is that the target prefix is actually reachable. So this captures the cases where already replying to the trace route actually using the IP address space of its provider.
So, what we did is run first local reachability measurements. What does this mean? We had a machine running in a Japanese ISP. We were running ICMP trace routes from there and the important thing is that we had the BGP information for the moment when the trace routes were running. So, what we tested from the point of view of the, of this particular source of measurements, the high visibility prefixes are going to be the prefixes contained in its global routing table. The limited visibility prefixes are going to be that was we have learned from our routing tables and are not contained in the Japanese ISP routing table. And the dark prefixes are going to be limited without the covering high visibility prefix so. By using our reachability methodology we have learned that the high visibility prefixes are in average 92% reachable. The limited visibility have a covering high visible prefix are 95%, so even if the traffic doesn't flow the way that the original IS was expecting, traffic still flows due to the covering high visibility prefix. However, this is not the case of the dark prefixes, which were highly unreachable, less than 5%.
So we asked the question: Is this valid on a global scale? And we tested the reachability of globally defined v6 dark prefixes, we focused only on dark and we used 100 active probes within the RIPE Atlas platform and you can see where they are located there.
Now, in order to understand what we tested, the target prefixes were the 473 IPv6 dark prefixes, which we gathered from analysing 110 global routing tables and we used as a benchmark the results for testing the reachability of 3200 IPv4 dark prefixes which we got from analysing 154 global routing tables. We perfermed one of the trace route measurements from each the probes. However the problem here is that we did not have the BGP probing information from all these sources at the moment when the trace routes were ran so we approximate our second hypothesis and we said that instead of looking at the BGP routing table of the source we look at the BGP routing tables of all the ISs we have from RIFs and routes and we build a second of ?? set of second last which could be traversed bay trace route towards the target prefix and we said that the IPv6 prefix is reachable if the trace route probe traverses any of these probable second last hops towards the target prefix.
And the results in order to understand them better we plugged on the X Axis and Y axis. On the right?hand side side you have IPv4. And you see here that the correlation is pretty weak. Why? Because we have 72% of all the prefixes gathered there in the left corner. These are prefixes that we are ?? from our stories that we have heard and from the lessons that we have learned from operators, are basically misconfigurations, prefixes that should not be visible. However there are 8% of these prefixes that are very little visible that have visibility degree lower than 0.2% that are still highly reachable and this we explain it with the full routing.
Now, in the IPv4 case, all these prefixes can be explained as misconfigurations, all these dark prefixes, should not be seen in the Internet. This is not the case for IPv6. Where we see a much stronger correlation between reachability and visibility. So even if the average reachability degree for IPv6 is 46%, almost twice it's higher than IPv4 we believe that this particular dark prefixes are not expressions of misconfigurations, and we are looking to you and we are reaching out to you in order to understand what is going on there. Is it just an artifact or stages of deployment of IPv6?
So to conclude, we have seen that IPv6 prefixes suffer from dark ?? from limited visibility and are also dark, they do not have a high visibility less specific prefix to cover and to make sure that traffic flows.
Now, we have some ?? strong correlation between visibility and reachability for IPv6 dark prefixes and we are trying to find out why do these IPv6 prefixes appear; is it as opposed to the case of v4 prefixes where you have a lot of misconfigurations and a lot of people using the network, is it a side effect of early stages of IPv6 deployment. So I strongly encourage you to go to the website, input the IS number, check for the visibility of your prefixes and get back to us. You can either fill in the form at the end of the query that you are performing, you can e?mail me, you can e?mail us, by us I mean me, and I am looking forward to hearing back from you. So, thank you, and if you have any questions?
JEN LINKOVA: A few questions. Do you see any ?? what was the prefix land for most of dark visible, the prefixes with limited ability?
ANDRA LUTU: So I have some backup slides. This is how visibility pans out on prefix length for IPv4 ?? for IPv6, sorry. So, going back to the talk from Geoff Huston yesterday you can see the high visibility stopped at /48 there. You have like the heat map here, the number of global routing tables that we analyse, limited visibility, dark blue towards red hot, almost visible in all the global routing tables. And then we break it down per prefix length. So, this is this.
JEN LINKOVA: Honestly I would not expect any really long prefixes being visible and my question is: Have you tried to exclude prefixes, let's say, longer than/56 or 48 from your data set, because apparently like prefixes, 127, you should not consider them yet, most like not something would you expect in global BGP table, yeah?
ANDRA LUTU: We have worked with the full data set at this point because we didn't know what caused them and we do not know the why behind why we see these prefixes out there, we did not exclude them.
JEN LINKOVA: And the second question about, how many private ISs did you see because I am actually seeing a lot of them.
ANDRA LUTU: We saw quite a few and we have discarded those ones. We have seen, yeah, we see quite a few of private ISs appearing in the IS paths. Universe number but I can look it up and get back to you.
JEN LINKOVA: My last question: You have a slide with percentage for your local visibility ?? no, I think it was initial ?? basically it was saying that ?? basically, you say that your limited visible prefixes were better visible than ??
ANDRA LUTU: Yeah, actually, what I haven't put in into this presentation due to the time constraints, we actually tested the, how valid or methodology was so what we did was take a batch of 70,000 addresses that were known ?? IPv6 addresses that were known to be reachable. We took the covering prefix and then we tested the reachability of those prefixes known to have ?? to have at least one reachable IPv6 address within. We took a random address and we tested with our methodology and got a 95% success rate. So we think that those numbers are actually due to the covering prefixes which are being used for the limited visibility addresses. So it's just an artifact of how we test and our two hypotheses.
JEN LINKOVA: And the very, very last question: I promise. When you have done it once so did you see a time lines, I mean any trends and how visibility changed over time. Because I did something like, I was looking in how many prefixes I am seeing from single point
ANDRA LUTU: That is a very good question. I can answer that question from IPv4. The cases we are actually able to solve were visible out there for like six months, at least six months before we actually made the tool available and what we see also in IPv6 is that the limited visibility of prefixes is quite constant over time. So, the lis own in IPv4 told us that this type of backfire routing policies or misconfigurations that can lead to limited visibility prefixes are quite constant in time so they they persist, people pass them as legitimate prefixes. That was in IPv4. In IPv6, we don't have any clear examples, so I don't have any clear example to give you but we have checked the visibility, how stable it is over time and it's pretty ?? so prefixes that are labelled as limited, they kind of remain limited in time.
JEN LINKOVA: Thank you.
ANDRA LUTU: Thank you.
ROBERT KISTELEKI: Very interesting talk, thank you. We see an increased interest in having Atlas probes in networks where either RIS or route use or other monitoring stations actually peer so one of our next steps is going to approach people who are peering with us or whatever else to put Atlas probes there because correlating the BGP path with the actual path useful for practical purposes every now and then. So if you happen to peer with us, by all means come and back up a probe.
ANDRA LUTU: Thank you. Yes, has actually a very valid point because one of the efforts we have looked for probes hosted by ISs that give their BGP routing tables in RIS or ? and since we haven't been much successful we only found about 50 of these ISs, we have just took a random sample of 100 probes and approximated the way you have seen before.
JOB SNIJDERS: I have a question myself. So you collect the data from a bunch of ASes and those ASes propagate to you what they see so those might be dropping a lot of smaller than/56 on their border but did you correlate how many of those ASes had a default gateway pointed somewhere to ?? so you could reach the prefix but you don't see it in your table? Is there a correlation, do you think?
ANDRA LUTU: So you are asking about prefixes that are very limited visibility, they have a very limited degree of visibility within our sample but are still reachable?
JOB SNIJDERS: Because of default
ANDRA LUTU: That we saw pretty much ?? we saw it in a lot ?? I am look for the slide right now ?? we saw it a lot in IPv4 which is the upper corner there, 8% of the v4 dark prefixes we tested were in that particular situation. However, in v6 we do not see too many of these cases. So why, I am waiting for answers for feedback?
JOB SNIJDERS: That is your job. Any other questions?
ANDRA LUTU: Thank you so much and don't forget to visit the website. Thanks.
(Applause)
JOB SNIJDERS: I'd like to elaborate on the huge advantage of rating talks. Monika Kdanova from Casablanca, you have won a prize, you were the millionth ?? that is not true ?? you rated a talk and you can pick up your prize at the registration desk. Congratulations.
(Applause)
The second announcement that I would like to make is regarding lunch. There are three lunch areas for RIPE meeting attendees: There is the kitchen gallery in that general direction to the left where you can sit down and enjoy lunch; you can also enjoy lunch in the opera room, wherever that is; and if you enjoy standing up, please go to the foyer outside this meeting room. So there are three locations, distribute yourselves and enjoy lunch. I will see you guys in an hour or so. Thank you.
(Applause)
