Plenary session
RIPE 81
3:00pm
27 October 2020
.
CHAIR: So. Hello everybody, and welcome to the 3 o'clock Plenary session. A few words of housekeeping first. I am Wolfgang Tremmel and I serve on the Programme Committee. If you are ‑‑ if you want to support this community and also want to be on the Programme Committee, there is half an hour left for you to self‑nominate yourself. So, have a look at the RIPE 81 website and check the Programme Committee part.
Also, very important: Please rate the talks because it makes our work so much easier if we know for the next RIPE meeting what you liked and what you did not like.
Another thing is about the questions, the written questions, keep in mind you can type in written questions to the speaker any time using the question panel, and I will read them out after the presentation to the speaker. Please do not queue up for the microphone unless the speaker is finished.
In that respect, I would like to introduce Jen Linkova. Jen, please make yourself visible and she is going to talk about the day she broke all the treadmills. Well, Jen, the floor is yours.
JEN LINKOVA: Let me share my screen. How about that now? Hello. For those ‑‑ if you don't know me, I am Jen Linkova, I am network engineer at Google Australia, and for the last, kind of, now seven years, I did mostly work on IPv6 in the corporate part of Google network. And today, let's talk about something impossible, unicorns, or, more specifically, taking IPv4 away from an enterprise network.
I am sure a lot of people do not believe that you can do IPv6‑only enterprises nowadays and I'd like to prove you wrong.
So, the question would be why any sane person would do that? Right. Why can we not all happily live behind private address space and NAT? So believe it or not, we managed to run out of IPv4 address space and as a result we have run out of private IPv4 address space. Honestly we didn't have much choice.
Also, I have been receiving more and more requests for IPv6‑only environments from developers because they'd like to test the environment, the product in IPv6‑only mode. And last but not least, I am involved for the duration and I realise that a created doorstep network is very hard, doorstep comes at a cost. You need , to support two protocols, you need to make sure both of them are working, you need to keep the polls consistent and so on, it's really hard.
So I took this opportunity to see if we actually can eliminate one of those protocols from the network and run just IPv6‑only.
So, we decided to do the could the down an the sky is not going to fall and we started with low‑hanging fruit. The low‑hanging fruit was a guest network, we had a number of reasons to do it for guest networks, mostly because of the network design, but actually, the guest network which we have in all or offices is our biggest network, more than 50% of all our devices we see in our network are actually come in the Google guest. If you ever visit any of the Google networks you probably notice that you have this Google guest wi‑fi, which is open in most of those, and you can connect to it.
Also we have wired guest network, which is mostly used for placing unknown unauthorised devices, so if you visit our office and you plug in your device, into wired, it will be automatically placed in the wired network for authentication.
So how we did that?
We obviously had to provide connectivity to IPv4 only Internet resources and for this we obviously needed NAT64 and DNS 64. For DNS 64, we are using Google public in DNS 64 which we launched back in 2015, I believe. And it was straightforward because normal guest network is using just normal public DNS, so all we had to do is change the IPv6 addresses provided via rDNSS. For NAT64 we provided the same devices which provide normal NAT for IPv4, so, for the dual stack network the same device would be translated in private address space in IPv4 space into public address space and in case of NAT64, those devices would be doing translation from IPv6 to IPv4. And every site, every office had their share of devices allocated.
And by the way, we do not have any form of DHCP6, so our network was just an internal network, slack only, so we were providing DNS 6 for information via our DNS so we were putting DNS addresses into router addresses.
So the goal of this project was actually to answer a number of questions; more specifically, what would be broken, how much of address space we can save, or, in other words, how ‑‑ what percentage of our users behave on IPv6‑only and what would be embarked on our support? Would they be overloaded with user complaints or maybe they weren't even noticing it. So, initially, we decided to do the pilot and for that we selected 12 pilot sites. Obviously, appearance may vary, but, for me, the main criteria was presence of network motivation team, user sites where we have large number of users which would make our data more reliable. So, we had to select sites with a high number of wired and wireless users and obviously I took into account the demand for IPv6‑only, so we included a number of sites where we had developers who requested IPv6‑only environment because those people are willing to try the IPv6‑only networks and report back to us.
So, pilot: We actually did pilot for environment part of the network slightly different and I'll explain why.
So, for wired network, we did about six months' pilot, where we made our wired network IPv6‑only. But obviously we found a number of cases where you just wanted to have IPv4 there. So what we did is, we developed a self‑service portal where the user can go and re‑enable IPv4 on the given wired port. However, users were encouraged to report why they need IPv4, because we wanted to investigate those cases and find out how we can fix them eventually.
So obviously, in any story, the most interesting part is what actually could probe. So the biggest outage caused by this pilot was treadmill. We have a gym and those exercise machines we have there are smart enough to be connected to our network, and apparently those devices are really unhappy if they do not have IPv4 connectivity. So, we got a number of unhappy users complaining they could not use the treadmills, obviously we had to enable IPv4 for those, and we are currently talking to equipment vendors to get that fixed and make those devices working on IPv6‑only environment.
What we discovered during the pilot was, first of all, the data, the results were very positive. We found that on most sites we do not need more than three or four or five IPv4‑enabled ports, with the exception of those locations with treadmills, where obviously wired to enable IPv4 for every treadmill. As a result, we did save a lot of address space, because our guest network was also used for fallback network in case of dot 1 authentication failed. So, for example, if you have an authentication system outage, we potentially can get every single device replaced in the guest segment which means we had to provide enough IPv4 address space initially to accommodate every single device on site. As a result, we were using a lot of address space, we were allocating it and they were never used and, as a result of this pilot, we were able to reclaim a lot of address space. And the most used case for IPv4 environment here was a kind of embedded systems, all the sensor, treadmills or similar device.
For wireless network, because as I mentioned it was a very big network, more than half of our corporate devices are sitting on wi‑fi or guest wi‑fi, so what we did, first we did a Phase 1, which was opt‑in phase. We created a dedicated IPv6‑only SSID without making any change to normal Google SSID and we asked users to try it. We sent an e‑mail to users and asked them to try the SSID and to report any issues.
We did it for about a year, and after that, we became reasonably confident that we can get more users on that IPv6‑only network so we moved to opt‑out phase. In that phase, we made our Google guest wi‑fi IPv6‑only, and we created a dedicated Google guest IPv4 SSID which users could use in IPv4. So, in this scenario, by default, all users were on IPv6‑only network and they had to take some steps to get IPv4 enabled.
So, what we found in case of Google guest IPv6‑only wi‑fi pilot:
When we did Phase 1 and we asked you just to move there, I didn't know ‑‑ expect many users to do that because, you know, people tend to ignore e‑mails, right. Surprisingly, we got about 10% of users moving from Google guest to that new Google guest IPv6‑only SSID. And we tried to give you some motivation to report back, so we kind of had a raffle, so users who reported back were entered into a draw and they were able to win $100 donated to the charity of their choice. As a result, we got 15 bugs reported and three of them were related to internal products and we got results back six in a very short time frame. And the low number of bugs gave us some confidence that we can move majority of the users into v6‑only mode.
When we moved to opt‑out phase and made Google guest IPv6‑only on those sites, we wanted to measure what percentage of users would actually fall back to the SSID. What we discovered, that, on those 12 sites, on every site, we saw less than 5% of users moving back to dedicated dual stack SSID. We got about 12 bugs reported. We got another 4 applications fixed. And actually we got significant number of users during the second stage of the pilot, the big device count during one day was 25K, unique devices connected to v6‑only network.
So, as I mentioned, we want to answer a number of questions. So what percentage of users need IPv4?
.
So what we discovered, that on wi‑fi network about 5% of users explicitly moved back to IPv4‑enabled SSID. There was about 10% of users on our legacy 2.4 gigahertz SSID which we did not want to make IPv6‑only because we assumed that if a device would not support 5 gigahertz, it probably wouldn't support IPv6‑only. So, about 15% of our users in total stayed dual stack.
And the wired network, as I mentioned there was a very little number of use cases for IPv4.
Address space utilisation. For those pilot sites, IPv4.DHCP utilisation dropped by 5‑8 times, which is actual matches 15% of users staying on dual stack network.
And for wired we were able to reclaim all our address space, and for wi‑fi that utilisation dropped by 8 times, which allowed a significant downsize in our wi‑fi IPv4 address space.
So, what did not work? As I mentioned, I broke all the treadmills right away. The second case, and there are orders here in the number of complaints I received, was actually Spotify applications. So, I have will ‑‑ I need community help here, so, please, if you ever use Spotify application, please go on this link and click on the feature request I opened and upload it, because it looks like they need a community feedback to get that feed.
Also, we knew that some systems, third‑party systems, would not work, and it looks like VPN as a protocol would not work on v6‑only, but unfortunately, there are many deployments of VPN systems, especially in enterprise, which do not work with IPv6‑only clients. In most of those cases, at least the clients just need to enable that for their server, and for some reason they don't do this; probably they just do not believe they are ever going to go to IPv6. Well, we got some complaints about Starcraft not working, which was quite a big issue. I mean, if you look at number of people complaining, and I also got some reports about Mac OS Internet recovery image not working but I was also told that this is going away.
So, do we really need dedicated network for fallback? Unfortunately, yes. We probably wouldn't be able to completely get rid of IPv4 dependency in the network any time soon. So, what we did for wired network in the pilot was that, currently, users could get an IPv4 on a wired network but we need to file a ticket to get this done and they need to explain why they need it and what the exit strategy. That exception is granted by default for 18 months and, after 18 months, you kind of reserve the right to take IPv4 away because we just do not want users to request IPv4 and relax and forget and never update it.
For wi‑fi, we have deployed a dedicated Google guest IPv4 SSID. However, we found that it's not the best strategy, and I'll explain in a second why.
So, did we find anything which would be a showstopper? Actually, no. I found that we provide some way, some workaround for users. It worked pretty well, right? The majority of users did not even notice anything. Those users who really need IPv4 were able to request it and got it. However, I was able, after the pilot, to go and do the global route for the rest of the network and make all our offices IPv6‑only on the network segment.
I know that a lot of people have concerns about being IPv6‑only because they are afraid the support line will melt because of users' complaints. That's not the case, fortunately, but we did plan ahead. First of all, we did let users know about the change, so users were notified. We explained to them how to request IPv4 if they needed and they also provided our support team with troubleshooting flow chart which explained what to do if anyone complains about something not working on the guest network, and we maintained a known issue page which we keep updated with every single new problem discovered, so our support team were able to quickly check if they did an assumption well known or they did some new issues.
What we have learned:
Just never, ever tell your ‑‑ allow your support team to tell you just disable IPv6. Because one of the problems we found was that, some time ago, we had some issues in the network and support team decided that it would be great workaround, just ask users, please go and disable IPv6 if you have this issue. And users did that and they walked away with IPv6 disabled from their laptops and they ever never came back to re‑enable, right, and, as soon as you started to take IPv4 away from the network, those users were deep in the water. They do not have IPv6 enabled, they do not have IPv4 any more, and the problem is you have no way to discover how many users followed this recommendation of disabling the IPv6. So, yeah, it might be a troubleshooting step but never use it as a workaround.
.
Also, I do not ‑‑ I have been thinking, oh, I have been operating in IPv6 for years. Actually, no. What you have been doing is operating in dual stack mode, and it's completely different from actually operating in IPv6, because dual stack is hiding a lot of issues and we, during that pilot and during that we discovered a number of interesting cases which we were not ever about until we turned off IPv4.
So, what kind of things? We discovered, for example, a neighbour discovered a state machine design flow when your device connects for IPv6‑only network the first time, we could experience packet loss for a few seconds. So we came back to IETF to see there is a drop currently in the IETF work co. We have found a number of vendor bugs in broken IPv6 implementations which were not obvious, and which were not known about until we disabled IPv4,
.
Also, there are a number of operations. A lot of people have IPv4 operations mindset. They say, okay, we can launch my product without IPv6 right now and then I will come back later and enable IPv6 on it. And they never come back, actually. and the product stays IPv4‑only.
People introduce some dependencies on IPv4 in the design so they might not even be aware of those dependencies until they take IPv4 away. For example, the product might be working perfectly fine over IPv6, but it needs IPv4 DNS and so on.
So another critical thing was, we needed early adopters because normally early adopters will volunteer, we recruited during the opt‑in phase, they were people who are technically capable and willing to do some troubleshooting and not just go back to dual stack network. So that allowed us to discover a number of issues proactively before moving the majority of users to v6 only and before we basically minimise the ‑‑ also what we have done is we really need to make IPv6 support requirement clear, much more clear, in RFPs and similar documents. Because if you ask a vendor, I need an IPv6‑only support product, they will tell you, yeah, our product supports IPv6, which is ‑‑ it might be you can configure IPv6 address and v6, right. You really need to be much more explicit than this and say, okay, I need support, I need management, like, and other protocol support over v6 and so on.
So, I mentioned that using dedicated SSID is not a good solution. Why? We actually spent a lot of time discussing the name for the fallback SSID, because we had kind of problems there. That names needs to be left, well attractive, so when users look at available SSID they will not pick up the first choice. On the other hand, it should be clear enough that you should try this SSID if the primary one doesn't work.
So shall we call it guest‑IPv4 or just IPv4 or just please don't use? What else? It's hard.
.
Also, quite often, users have no idea what SSID they are connected to. Your device might remember a number of SSIDs, and pick up one your device thinks it should be connected to. And sometimes users might be accidentally connected to a dual stack SSID while they really do not need IPv4.
And once your fallback SSID was remembered by a device, it's rather likely that your device will just connect to the SSID eventually. So we actually considered moving to fallback SSID to make it harder for users to get accidentally connected to it.
So also, for wi‑fi, you create a SSID that you want to be connected. For wired network, it's much harder because, for wired network, it means we need to roll out a dedicated dual stack VLAN, and for wired it was reasonably easy, but for the rest of the network it would be nightmare because I need to double number of VLANs. Now I need to have v6‑only and dual stack. So what we really need here is, allow IPv6‑only and dual stack host to co‑exist on the same network. Before we just published here, we described how this could be done using the HTTP 4.
So the current thing is, the vast majority of our offices now have the guest network segment in IPv6‑only mode. So next time you might be visiting our office, you will see that your device is connected to v6‑only, it doesn't have any v4, and I guess we have an a few minutes for questions now.
CHAIR: Thank you, Jen. We have questions. Let's start.
Andrei from the RIPE NCC is asking: Do you segment your guest network? How do you identify which IPv6 addresses belong to which wired port?
JEN LINKOVA: Well, I know that because I have access to router and I have access to MAC address table, so my switches. So there is no secret there, really.
CHAIR: Okay. Let's hope that answered that question.
JEN LINKOVA: Yeah, like, offline, if it did not answer, yeah, I could clarify it.
CHAIR: I think everyone will be around after the session and we can discuss that.
And the next question is by James Blessing: How are you doing the exception for IPv4? Is it Mac address space? If so, how are you handling things like privacy extensions?
JEN LINKOVA: Okay. So currently for the guest network, I agree ‑‑ for wi‑fi, we just tell users, okay, if you want IPv4, go and use this dedicated Google guest‑IPv4 SSID, right. We don't care what MAC address, the user can select dual stack. For wired network, it is ‑‑ we know the port. So if user is telling me I need IPv4 on this port, I'm just go in and move that port to a dedicated IPv4‑enabled VLAN. So that ‑‑ as I said, it's suboptimal. What I would like is, I would like to have one VLAN or one SSID where the devices do not need IPv4, would be IPv6‑only, and devices which need IPv4 will get address via HTTP, that's why I mentioned how we did into the our internal networks so hopefully I will get back to you in a year, maybe a time with some results of this.
CHAIR: Okay. We don't have any additional questions in line. So thank you, Jen.
JEN LINKOVA: Thank you, guys. I will be around for a while maybe tomorrow, so if you have any additional questions. Thanks.
(Visitor applause)
CHAIR: Our next speaker is our resident expert on geolocation, Massimo Candela.
MASSIMO CANDELA: Hello, everybody. Thank you for the introduction. So let me share the screen. So, yes, my name is Massimo Candela, I am a senior software engineer at NTT. The presentation I have today is a proposal that we did at the IETF which we hope is going to operators in publishing the geolocation data and making them easily discoverable.
It is, together with Randy, Warren and Ross, but let's go straight to the point.
IP geolocation, it's there, we need it in a lot of applications, but the main thing is, I think everybody of you already experienced this at some point, some of your customers, or one of your customers writes to you and says, well, I cannot access resource X because my geolocation is wrong. Now, you know, but the problem is that it's something that is difficult to solve. There is no real easy way to solve it. And the main reasons are because there is no central (something) there is no common strategy, there is no way to provide data, and so the, for example, geolocation providers, they provide the geolocation and there are many of them, and in addition to that, a lot of ‑‑ in particular, content provider that are in any way big companies, they solve in their own way the geolocation problem. So they start creating their own folk of the geolocation data, so instead of correcting the original source, they just enrich what is provided by geolocation provider. So this creates a big mess. Because you have a lot of folks, a lot of copies of geolocation data that they are all prone to get stale or any way you can create an issue and every time it's difficult to track back where that problem is. So the thing that you do is usually you send a lot of e‑mails.
I usually put this slide in the presentations that I do, where I list parties. These are the most important on the market of geolocation providers and there are some ‑‑ some involved where they offer APIs, the others you have to contact by e‑mail but that's not the point of this presentation anyway. Usually this is what you do. You contact them and so it's there if you need it.
.
But there is actually a better method. So, the method that is available described in RFC 8805, which is ‑‑ it's something that is already there, we didn't work on it except for Warren that was involved. It's a CSV file that allows you to do a common separated specification of geolocation which is currently adopted by Google and many geolocation providers. I am just going to go directly to how it is done, so if you see here at the top, it is composed of the IP prefix, the country, the region and the city. So it's each line is one entry like this. And you specify the country, region and city for the prefix that you want to provide this geolocation. It's something that you want to do, you don't have to do it. You create this file, you put it in your ‑‑ somewhere in your web server, you serve it over HTTPS, that's all. It's a file that somebody can download with all the geolocation information that you want to provide.
It uses standard country codes like, for example, the normal that you use, like IT for Italy and NL for the Netherlands, also for the regions which are less known but they are still standard and I provide here a link where you can type the country and find all the regions.
And for the city names, instead, there is this geo name datasets that you can use. And I want to show just an example. You create a file, you can put like this first example is /24 where you don't want to provide any geolocation, or you provide a /25 like in the second case only with the country, or you go and reach the regional level like in this case, for a /16, or you can even just say a specific IP to a specific city, so you can just say this is is in this region, but this IP is in this specific city of that region. Because the longest prefix match is what will work on this.
So, this is why this format is used, why this is great, because it allows a great flexibility compared to other solutions, so you can decide what to crowdsource, what information to provide, to which prefix you want to provide, you can provide all the more specific if you want and you can decide if city level or country level or whatever you want.
So it's flexible and easy to use.
So the great part is also that, as I said, it's supported by all, or almost all, the major geolocation providers. This is an experience that I personally have in some colleagues, and I received this great e‑mail after my last webinar which I did, this guy said that he was already providing geofeed file to Google, which is one of the content providers supporting that, and the IP, which is a geolocation provider, but after the presentation he was able to set up automatic updates with pretty much all of them, and he lists also the names of them. So, this is actually a pretty great information that confirms that what that means, that geolocation provider, if you provide such files somewhere, accessible over an URL, they are good and you send this URL to them, they are going to periodically download that and update their geolocation. So, it's great, we have a format, a list, we have a possible technical solution, we know that this works. The only problem is, there is no central repo, and to do that, like in this example, you have to send e‑mails and things, and these are all the geolocation provider. You also want to include the content provider. This becomes, soon, annoying for each prefix and maybe you want to geolocate.
In addition to that, like, there are a lot of new geolocation providers, there may be less important in the market but still they provide geolocation to somebody.
So, we opted for ‑‑ we tried to come out with a solution for that, and we evaluated various options and we came up with something that works in RPSL and I will tell you why now.
We proposed this draft, which you'll find the link here, is, we asked for adoption in the Ops Working Group. It is pretty simple. We just wanted a simple solution. Something that works. The solution is you have inetnums or also INET(6)NUMS, they have remarks. You can have as many remarks as you like, you just dedicate one remark to a point your URL to geography. In a way that system, the format becomes discoverable in an automatic way, and so we say like geofeed space, URL and you put in the remarks. If you use ARIN, it's net range and comments. At some point maybe we will have a geofeed attribute in the inetnum itself but anyway what you just need an URL for now. They work pretty well.
The good news is that if you do it in this way, a geolocation provider already have access to, which they already are ‑‑ they have experience with WHOIS data, they already use it for their APIs and things like this, so we are not introducing anything disruptive for them. And what you have to do is to keep up to date your CSV file. That's the idea behind it.
So if you publish, if you want to provide a correct geolocation of your addresses, you have to remember that the geofeed file can have a higher granularity than inetnum, which is a great thing because you can just say okay, from this /16 inetnum link to this geofeed file and IP side the geofeed file you just manage whatever sub‑prefix, whatever more specific you want.
And the geofeed file should be served offer HTTPS. I saw people that they don't even bother to have their own server, they just host it in GitHub, whatever you want. Once you link them, you don't need to access the RIR portal any more, this is one of the feature I like because I personally don't have access to NTT RIR portal to what I ask somebody link it and I will take care from the CSV file on.
Also, multiple inetnum can refer to the same geofeed file. So you could actually just create a single geofeed file with all your prefixes and point all the Annette numb to the same file. It will work. Except if the case in which you want the file to be signing, in that case cannot do that.
So the idea is that the inetnum, the Linx to your file is giving you some kind of an assurance that you actually own that resources, we will see how now, but if you are worried about a weak ‑‑ authentication, you can actually do a digest of the main body of the file and with the relevant key and attach it to the file, but for this part, please don't ask me anything, Randy and Ross are the experts in this.
If you are fetching the file, and this is the interesting part. So if you are a geolocation provider, so, the first thing is that the referring inetnum must be ‑‑ so whatever you feed in the geofeed file, you have to exclude whatever is not in the range of the inetnum that brought you to that geofeed file. This will give you some kind of assurance that you actually own that resource.
And also, the more specific inetnum object is considered whether it has a geofeed reference. What that means, this is extra flexibility that actually is pretty good. So this means that if your customer, like, has sub‑prefix and is complaining that the geolocation is wrong, like it happens now, you can keep correcting the geolocation for them by providing the geofeed file in your less specific inetnum, but they can also just at some point add the reference and since their inetnum is going to be more specific they are going to override what you did. So you can balance if you want to support them in doing it yourself or if you want to push them to just do it.
Another important thing, extremely important thing, this solution, it's easy also because you can just parse the bulk WHOIS data, and they are publically available for all the RIRs except for the ARIN, so the bulk WHOIS data, the anonymous one you don't even need to sign anything, they are on the FTP. But for the ARIN you need to sign a form if you want to have them, or, they provide a list of the net range that is publicly accessible and you can, after use, end up to a parse the remarks and that's what we are doing at the moment.
So, there is this geofeed finder, which is open source. The only thing that it does is, you run it, it parses all the WHOIS data possible, it creates a huge ‑‑ it's not huge, it's a complete results CSV file following all the rules that I said before with all the geofeed that was able to find in the data. Of course this is a prototype. But I give you a quick demo. I just make it run. I select only APNIC and RIPE, because it's faster. Here we go, it's finding the inetnum, pulling the geofeed file from the various resources and now the only thing that I need to do is to do a cut and go and result CSV and I have the global calculated CSV.
So the great news is that since geolocation provider in Google and others are already using this from their users, they could just simply run this script, or whatever other script, and import these results CSV like if it was a single user, so it doesn't change anything from their technical point of view.
So, my presentation is over. And I left some time for questions and feedback and whatever you want.
WOLFGANG TREMMEL: Thank you, Massimo. I have one question from Andy Davidson from Astroids, and he asks: How difficult or realistic is it to solve the problem of the lack of a sample repository for IP geo data, please?
MASSIMO CANDELA: If it was easy, we would have have already solved it. The thing is that there are a lot ‑‑ I mean, so unified repository, you mean like creating one single database instead of a linking to external files? The thing is that you have to build a service on top of it and there are already geolocation providers there doing that. The thing is that they are more than one. So, this solution tries to actually give at least a central way from where to find the farthest geolocations. So...
WOLFGANG TREMMEL: Okay. I have one person at the microphone, that's Dmitry Kohmanyuk, and you have the microphone. Please introduce yourself.
DIMITRY KOHMANYUK: Hello, Massimo, I hope you can hear me. Thanks for the presentation. Have you tried contacting ARIN about the lack of public data or other RIRs do they have data about cooperation?
MASSIMO CANDELA: Sorry, I didn't get your question.
WOLFGANG TREMMEL: The question was if you have contacted ARIN.
MASSIMO CANDELA: In what sense? For what reason? I mean we already are able to make it work with ARIN.
WOLFGANG TREMMEL: I guess it was about the lack of public data because you said for ARIN you have to sign something.
MASSIMO CANDELA: Oh, networks, it's just their polls. You have to sign something. They provide, anyway, the list of inetnums which is great because it clearly reduces the number of queries that you have to do, some thousand queries, which is not really a list deal if you follow also the cache thing. But the thing is that that's not a problem. This prototype do that I did, I did it also to show how this things works but the geolocation provider, they already have access ‑‑ they already sign those forms, they don't even have to do queries, they just parse with it. But it's for sure a great feedback because we could ask to add in the format that they publish the net range to add different remarks for the geofeed or at least another separated file and this would for sure avoid also this minor inconvenience. Thank you for the feedback.
WOLFGANG TREMMEL: I have two more written questions and I am closing the microphone queues now. So there is one question from Patrik Tarpey from Ofcom, and he writes: There are documented cases where corrections to geo IP provider records have proved problematic to get this corrected. To what extent does RFC‑8805 approach tools resolve those updates and currency rather than standardising format?
MASSIMO CANDELA: That's a great question. So, in the end, you can provide what the geolocation is, but if you use an intermediary or a geolocation provider or whatever, they can always say whatever they want. And in some cases it's also good because some cases they filter clearly what ‑‑ they are fake geolocation that they are providing. So there are known cases of proxy companies; they, on purpose, feed wrong geolocations, so there is no way to really enforce them to adopt the geolocation that you provide, but at least RFC‑8805 at least provides a technical format that allows this data exchange and our draft instead allows a way to tell them, look, this is what I say, without me sending you an e‑mail and this is valid for all geolocation provider instead of discovering e‑mails of them and mailing them. So, in a way, like, you can always ignore that, but why are you doing that if the geolocation you provided is good? I mean, it would not make sense, it would just make them even look not good.
WOLFGANG TREMMEL: Okay. Thank you.
And the last question from Wessel Sandkuijl, from Prefix Broker BV. He writes: You mentioned proof that you own the space regarding trusting the geofeeds remarks entry. We control a lot of IP space on behalf of our customers including geo information, but we do not own the space. I assume owning is not a requirement?
MASSIMO CANDELA: So, okay, so, own ‑‑ okay, this is a really term also strange because in some areas you can holder, access holder, anyway the requirement of our proposal is that you have to read the geofeed that they are only in the inetnum that referred that file. So you can add in the file whatever you want but if your inetnum is just a specific /16 only the /16 must be consumed by the parser and that is what the tool that I showed. This is already it's what we declared with a must and the idea is that if you have that inetnum, you are able to geolocate that.
WOLFGANG TREMMEL: Okay. Thank you, Massimo. And with that, I am closing the session. Please remember to rate the talks and see you in ten minutes.
(Coffee break)
