Transcript: APOPS - Session 1

Disclaimer

Due to the difficulties capturing a live speaker's words, it is possible this transcript may contain errors and mistranslations. APNIC accepts no liability for any event or action resulting from the transcripts.

Wednesday, 25 August 2010, 09:00-10:30 (UTC +10)

SRINIVAS CHENDI: Good morning ladies and gentlemen and I do apologize for the five minute delay there. Just having streaming problems for the transcription. We would like to thank the sponsors of APNIC 30. Here in the Gold Coast. I would like to remind you all. I know you're here in the conference and I know that your job is important, but if you could turn your mobiles to vibrate mode. And if you approach the microphone, please state your name clearly, and if you like, you can also state your affiliation, that's also an option, but we at least need the name of the speakers and people asking questions here. So the stenos can get your name up on the screen for everyone to see as well. If you have any questions about the APNIC services or anything related to the IP addressing, can you approach our members in the member services lounge, which is next to the lung area there. The garden terrace. Any time our APNIC services can help you out. And I would like to pass you on to the chair of this first session, Philip Smith.

PHILIP SMITH: Oh, it actually worked. So, good morning. Good morning, everybody. Thank you to Sunny for the introduction. Apologies for the slightly delayed start, but we're ready to go. What I want to do before the first speaker is give you a background to the APOPS session. Today is very much Internet operations. This would be the main part of the operations session of the APNIC meeting. This is what we call the Asia Pacific Operator's Forum. Those who are familiar with APRICOT will remember the APOPS session during KL where we did the plenary session, the plenary session where we assembled operational topics that we consider that are of interest to the general Internet community. So, we repeat the same type of thing here at the APNIC meeting. So APNIC is not just about policies and membership issues. It is also a chance for Internet network operators to come and talk about some other issues and look at some of the things that are happening on the network today. Things that are going to be happening on the network in the near future.

Just a bit of background. There are three of us who actually chair APOPS itself. There's myself, Philip Smith from Cisco. We have Tomoya Yoshida from NTT who is sitting on the podium with me, and we have Yoshinobu Matsuzaki from IIJ who is sitting over there on my right-hand side. So we shepherd APOPS. Not that there is much to be shepherded, but we do shepherd APOPS throughout the year.

There is a website, a simple website which basically points out the next meetings as introduction to the mailing list and such like. If you're not on the mailing list, you're very welcome to subscribe to it. It is not high volume, so you don't need to be afraid of being deluged with mountains of email. That's probably a positive thing to say about some mailing lists these days so you're very welcome to subscribe. There is sometimes some useful discussion and information presented there. So we'd like to encourage you all to participate.

Now, at APNIC 30, APOPS is part of the regular APNIC program, as I was saying. And again, just as part of the, I suppose, modernization or improvements of APOPS. We did a general call for contributions. We had a program committee that was formed from the general community, so rather than the APNIC special interest group chairs who have formed the APOPS program committee up to now, we had a general participation from the community. Jonny Martin, as some of you may know as the APRICOT program committee chair chaired the PC here with my assistance. And the model that we use for submissions and reviews was actually very similar to what we did at APRICOT, so people submit content via the submission system. The program committee reviewed all the content according to the specialist areas and we selected the presentations today based on that. So I put the URL of the agenda up there. And I'm sure you'll probably see it as we go through the day, in any case.

Now, before we launch into George, who is eager to get started. Just a reminder that we have Lightning Talks 4 pm to 5:30 pm. These are ten minute presentations. You don't have to do a fantastic super wonderful slides. The idea of a lightning talk is something that's latest breaking news that was too late for the submissions system. Things that have happened in the last two or three weeks that you want to or would like to share with the audience. We still have a few slots left. If you would like to put in your proposal for a lightning talk, I believe we're making a decision on those by lunch time today, so you still have a couple of hours left. If you go to the submission.apnic.net and put in your proposal there, so it can be text with the presentation or draft slides or whatever else.

Now, today's agenda - the first session I will be chairing. Tomoya and Maz will be chairing the other two sessions for APOPS. Rather than getting the speakers to speak far too fast and the stenos can't keep up, we're doing three presentations per session which gives speakers more time and you more time to answer questions and hopefully we can have a better discussion.

And we have three. First up is George Michaelson who will be talking about measuring traffic in 1/8, 14/8, and 223/8.

GEORGE MICHAELSON: Oh, we're there. Sorry about that. So, this presentation is the predominant body of work that the R&D group has been doing over at APNIC over this year. But it is also a presentation that's a show case of collaboration between ourselves and you, the community. I would particularly like to thank Tomoya and Manish from Merit who provided us with assistance in capturing the data that I'm going to be talking about today and also provided a wealth of information about what we have actually been seeing in the network.

So, it's a product of the R&D group, but with a cast of thousands. Geoff, unfortunately, can't be at the meeting and said that I could present this on his behalf. So I'm going to do the best that I can to give you the full sense of a Geoff research presentation, but you'll understand that this is necessarily me presenting someone else's slides.

So what do we really mean by background radiation? We've got the sense that the traffic on the net actually comes from two people who are trying to form a conversation. The classic end-to-end behaviour. But if you're running your own Firewall on a home network and you happen to look at the logs, you're going to see a large amount of unsolicited traffic coming in, or if you're running a corporate Firewall, you'll see clogs of traffic coming in, and generally, you don't answer the traffic. You're dropping it and putting it somewhere. We think we understand this. We talk about leakage or we talk about probing and scanning. But we don't actually have a handle on the scale of a problem as a whole. So the question that's come up is - what is this constant level of background activity that we're seeing in the network?

Now, if we couch this in terms of background radiation, there's actually questions around, what are the questions? What's its intensity? Is it focused in particular places in the address range. Are there places which are just so bad, those network addresses are never going to be generally useable? So, to put context on this, we now know that we're now at the end point of distribution of the IPv4 address space. And the prime concern is that as we start to hand out blocks that have history behind them, blocks which have been used in other contexts and then returned into process, it is possible that these actually have a sustained higher level of this background traffic. After all, other people use them. Maybe they never turned them off. So the three allocations which are kind of show cased here actually all have examples of having been used. Network one has a very long history of ad hoc history use. Network 14 was used for distribution of older technology, X.25, I guess there are a few of us who used that capability. 223 has been used in some ad hoc and private contexts. Now, in hindsight, we also got network 27 and it probably would have been a good idea if we had included that in this measurement activity. Unfortunately, we don't have that, but it would have been nice to include it. But the three here are the ones that I will focus on.

So we have a relationship with the RIPE NCC who have a wonderful facility for performing network reachability checks. And in January, when we received network 1, RIPE, on our behalf, announced a range of prefixes in this address space. 27 January they put up the two 24s, the 22 and the /16 in the back of this network block. And if you look at this graph, I think I'll use this one, because if I get the laser pointer wrong, it means that I can blind the other speakers!

Actually no, that's a bit hard. So you can see in this part of the diagram, that flat line, that's a really, really strong signal that we've completely saturated the network link, and if you look across, that's 80 megabits of data flowing there. Sorry, 8 megabytes. It is fatter than a 10 megabit link. So that kind of gave us the question - how bad is one. Will this tell us about the uniformity of the traffic? Or is this about the hot spot problem? Is this good guys, or just fat finger trouble? So we had the feeling we're going to have to do something on a systematic level and try to find out what's going on. And this radiation detection metaphor, it kind of drew us to this image. I think that it would be really lovely if this was the kind of technology we had to use for microwave point to point links now. Can you imagine trying to get planning permission to put one of these up on a pole? The big backs at the back, apparently that's a fridge. When they were designing this technology, we didn't have microchips and to do microwave data capture, you had to chill it down massively. I'm in awe of this technology! But a modern day radiation detector looks more simple. This is the basic work that comes from the work Dave Plonker did, which we regard as definitional for the large scale packet capture. You use it as an announcement of what we call the darknet. It is not something that's currently in the allocation. You then pick up all of that traffic and you put it somewhere on a collector with a large disk farm. But we were interested in the idea of drawing out more traffic. So as well as the classic passive collection, we also included the active element to send acknowledgements back in the data flow and see if we could bring a little bit more of the traffic back into view because that would give us the sense that this was a little more than scanning, because we know that scanners. They're kind of out there probing and expecting standard responses. But if we can tickle the other guys into life, that can give us a sense of equality. And we knew that we had to have a lot more than a 10 megabit link. We needed multilink access and terabytes of disk space and this was massively more than the APNIC investment on the ground. This is where we went out to the R&D community, the operations community, and asked for assistance. And I would like to acknowledge Merit, NTT, AARNet, Google and YouTube who provided us with bandwidth hosts, and storage. The collaboration with NTT in particular has been enormously fruitful for us, as you'll see later on from the presentation that follows.

So Merit is the data that I'm going to show case here, and Merit using AS 237 did a one-week announcement of network 1. And this was 8 terabytes of packet capture, which I estimate is probably four or five times as much as any other network range we've tried to capture. So this is a picture of what it typically looks like. The display here is a time series, so we're looking at successive dates. The 23rd, the 24th and the 25th for the week. It's telling the megabits in the traffic. So some things to note in this. The circle, the peak burst, that was a burst event of nearly a gigabit of traffic. We're aware that there's a bit of a water fall of traffic behaviour going on here that we're consistently losing some of the data capture. We think that that could be an artifact of the way we're running that, but we don't think that it detracted from the overall quality of the collection.

It's really quite an unusual shape of a curve. You'll notice that doesn't have the diurnal shape that we've come to recognize. This is an almost constant count of behaviour. Very strange. So if you look at this in terms of packet rate rather than bytes of data, that changes. It almost immediately actually does show up a very strong diurnal pattern. And this is the classic signature of something which is a behaviour that's predominantly about people. If it is machines, it's constant. If it is about people, it tends to reflect time zone behaviour. The other thing that's notable here is that UDP is the predominant form of the traffic.

Now, that, for us was very counterintuitive. That was not what we expected to see. There's very little ICMP. This is not from ICMP ping flooding. There's also the thing that the peak and the average traffic are really quite close.

So the packet size is kind of interesting. The one gig burst was actually also a burst in terms of packet size. You can see that it was bursting up to nearly a kilobyte of pay load. Mostly it was a small packet size but there were packet size variants and this accounts for the difference between the megabyte rate being constant and the diurnal change in packet count. It was just completely swamped by this behaviour. So it raised the question - is this normal? So we performed the same activity in Network 14 and in Network 223. Exactly the same experimental set-up. 7-day capture, passive.

Now, just as a quick summary. If you look at the shape of the graphs, the top one is the graph we were looking at previously for network 1. The bottom two are showing 14 and 223. The important thing to note here is that there's actually a huge scaling difference here. The top has to cope with 900 megabits of traffic. The bottowm two, the maximum is 250. There's already differences emerging here. The other thing here is that the shape of the records in the other two networks is really quite different. You see much stronger diurnal signal coming out in that. You see the wavy line at the bottom. Clearly, what's happening in network 1 was really quite different to what we're seeing across the network as a whole.

It's very different if we look at this by average traffic. It's about five times as much. If we look at this in terms of UDP versus TCP, the relative ratios are completely different. The diurnal ratio is different. So this visualization is actually splitting the network into its various subcomponents, so the horizontal axis is each of the 255 /16s which make up the network block. Geoff draws our attention to the fact that it is a log scale, so the spikes that you see here are orders of magnitude higher than the base level load. They are really massively higher. The other thing that stands out here is that if you go to the left-hand side of the graph, you see where the red and the blue lines have compressed together. That's where you can see the peak and average load has reached almost the same value. And that's a very, very strong statement that the majority of this traffic behaviour that we're seeing is actually coming from that very small number of networks that are low in the number range. There are other peaks which are interesting, but that's the overwhelming majority of bad behaviour. It's a little hard to see on the graph, but the very far right-hand side has a sharp drop-off. That was because the RIPE NCC was still advertising more specific /16 in this period. And this is a good thing, because it can show that, first of all, this is a true effect. If they have a more specific route, that's going to take preference in the routing. So clearly, the traffic was going to go to them rather coming than to us. Indeed, that's what we saw. A complete shoulder of ending there just on the end side.

So, those bottom /24s, here are the bad boys. Ten of them that are taking 75% of the packets. Does anyone feel like there are magic numbers buried in there?

So, Network 1.1.1.1. There's a magic number. 34% of the packets. UDP packets to this high-numbered port. OK, this is strange! What's going on? Well, it turns out, and this is work that Manish did. This is Version 2 RTP. It seems like it is coming from a fairly small number of source locations. It's a fairly small number of source ports and it turns out that it is a compressed audio format. It's some kind of VoIP behaviour which is using a default setting of 1.1.1.1. And we received an indication that it may be telephony systems where people deployed it using the factory default settings, which is network 1.

So the second observation - the 860 megabits peak, the gig peak, it was a six-second burst of traffic in network 1.1.1.1. That's a short period of time to capture a gig. And the packet traces are quite strange. It was UDP from this address pairing and it said that it was 8K, but because of fragmentation issues, what we captured was initial 1K packet. So we don't know if it was an 8K pay load, but that's what it said it was. Six seconds, I think that's a leak. People who can sustain a traffic load forever, that's few and far between, so somebody did something that caused the large amount of traffic to swing our way and realized that they had done an oops and it when away again.

We have a theory around these numbers where it looks like it's gone and embedded 168 in it. Again, this is Manish's work and he looked at this and said, if you've made a mistake in looking at the host of network byte ordering in converting your addresses, it's going to look like this. So this is actually just someone who has got a bit of a coding oops. We're interested in the question if we see this in other places and the answer is yes, you do actually see this kind of behaviour spread across the address ranges.

So network 1.4.0.0, this is utterly bizarre. It's a shifted port weirdo private DNS that someone is running. We have no idea why, but that's what they're doing. Just one of the things that people do. A story that we've been told is that it is possible that a generation of equipment was deployed into a large customer network that had a bug and faced with the decision of recapitalizing or replacing that equipment or making the bug a feature. The vendor and the ISP decided to stick with the feature set, so that's just what they do.

OK, so we come to the pragmatic aspect of this. The R&D is interesting, but we have to think about informing the operational aspects of address management. So five of the /24s are clearly unsuitable for use at this stage, and we've recommended a withhold from normal allocation process. Now, I don't want to say that this is a forever statement. That's not how the registry system works. But the recommendation that we made into operational activity in APNIC was - don't give out these ones. We're going to keep looking at them. If we can see a drop in traffic, these will be suitable for use in the global network. They are orders of magnitude higher in general than the general network. And some /16s looked problematical, so in a sense that we expected these are much more likely to come back into play sooner, we also made a recommendation that they should be with held from general distribution at this stage.

OK, so looking at the other /8s. We did this advert with NTT and I would like to point out that Tomoya is going to be talking with Frank about that activity, so I'm not going to talk in detail to the slides but we wanted to include them here for general information. We needed to reflect on this and look for confirmation of behaviours that we've been seeing. His period of announcement through to the AS 3639 using TCP dump NetFlow samples to capture. But also doing reachability work which was into the resource analysis activity. If we look at the data that he was collecting, it's been presented in a slightly different way. The strongest signal that you see here on the bottom TCP, and that's what we normally see, predominates. And it has the classic diurnal wave shape, so again, the collection confirmed that the behaviour in the nets, other than Net 1 is more about human behaviour than a saturation load. This is a stacked graph, so the UDP that follows, the green wavy line, that's mostly linear data set. UDP has mostly been a constant. In the port breakdown, Yoshida-San was seeing mostly TCP port 445. So that was a classic signature of hostile traffic in the form of conficker. Is there anyone in the room here who still runs Telnet? Put your hand up. Because Yoshida saw a lot of Port 22 and they are anticipate hunting for you. So if you're still running Telnet, turn it off.

Yoshida also did a very interesting analysis looking at the origin AS, and I would like to say that this is basically not just in our region. You can see that the ASes include European entities that are doing this activity but it is also in the region. We have to consider this as a global activity to look at worldwide. A lot of it is in region, but it is really worldwide.

In terms of the destination IP, Geoff and I have the feeling that this is basically a much more distributed problem. There are much fewer problems here. It is not about isolated nets that have specific problems, but about the general level of traffic that we're seeing across the network as a whole. Source was also very easily distributed. I'm going to skip about this, because I think that Yoshida can talk about it better. If we go back to the view to talk about the /16s. This projection of Network 14 shows behaviour that we really want to show case as what we think is going on in general in the network.

If you look at this graph, you can see that there are two very clear different parts in the average load. There's a bottom half where the average traffic per /16 is in the order of 100 kilobits. And there's an upper half where the average traffic is much lower, more like 30. Peak has the higher behaviour that's more generalized but the average, it has this amazing step function and this is absolutely at the dividing line of the /8. It's a /9 and a /9. If we look at this, by jingo! We see the same thing. We have all of the extra traffic there. The minute you get into the high-order bits, it tails off. Slight variation in the ratio between the two, but it is still very much the same story.

So, what is this? It turns out that it is conficker. Conficker has this - well, you could call it a bug, or if you look on the analysis side, you could call it a feature, but a signature that we see. The low half of a /8 is just scanned significantly more than the upper half if you're running into the conficker problem. If we do the comparison of the /9s in a breakdown, you can see that this has a radically different shape. In particular, you might notice that the TCP and the UDP flip over in relative terms of intensity. So it is a very clear distinguishing fact that conficker is saturating the network blocks. And I don't mean just the last ones, I mean all of them.

So the port list that people are doing traffic. This is the sin list. 445 stands out. It is quite clear that this is overwhelmingly the majority traffic. But I would like to stress that we do not believe any of these ports are benign. We think this is all bad. We think that this is all hostile scanning. These are some protocols that we're seeing. It's very old vulnerabilities. These are things that go back years and years and years. But you see that thing in there called koobface. That's a Facebook attack. Faceback is not old. These bad guys think up new stuff and scan for it too.

So April, the new zombie army came out of the wood work. So on this, we're going to do temporary reservations and hold back some stuff in network 14 and 223, much as we did in network 1. And we think we've come to an understanding about what background traffic is across the general address space. We think that it is around 600 bytes per second per /24. It is very heavy tail on this. If you exclude network 1, this is really not a lot of traffic. It's of the order of a few packets a second. Every address anywhere on the Internet can expect to receive a few packets a second. And that's just the back ground noise of the world scanning you and looking for vulnerabilities. It is kind of not benign. Every packet out there probably has two horns and a tail. This is predominantly about Windows. If you're a Mac user, can you rest easy. You are not exposed to the same level of risk here. That won't last forever, but that's the observation right now. If we were going to say that there's a top ten, Geoff has said that I should say, "Conficker takes all the top ten slots."

The total traffic across the entire address space would appear to be of the order of 5 gigabits. That's a very strange number. I can't decide if that's a lot or a little. Given the size of the network, I would probably go to the little, but it is still a large number. The variation between the low and the high half. If you're in the high, it's one every 120 seconds. In the low, it's about one every three seconds. It will not be a problem for any technology which is out there. We intend continuing doing this class of measure. The problem of not having started earlier, we know that this has to come to an end because there will be an end to v4 and at that point, the whole of the v4, /8 announcements will be extremely logistically difficult to do.

So this is not an open-ended activity, but we feel it is useful to continue measuring and value the collaboration with people and continue to test net blocks before we do release into the general community.

Now, there is a little extra. Which is some work I've been doing in visualization. The primary data work that you just saw is actually what Geoff used to inform operational activity, but to try to get a handle on this, we also looked at some other ways of viewing the data to try to see if we could see patterns and get an intuitive feel for the nature of the behaviour. We have some history here because we did movies of BGP uptake and thought that we would use the same network to visualize stuff here. So what I'm going to show you is a sequence of movies of the packet captures and I want to give you a sense of what you're looking at. This is a view of the whole global Internet address space.

The white stripe is the part that can't be used. It's the multicast range. Everything else represents the address space that's in general play. The yellow is the density of use, so it is a very highly densely deployed network. The black tends to be spaces that haven't yet been deployed that's actually the ranges we're running into now. So in this view, you can kind of get a sense of the different network blocks. Every vertical chop-up is a different /16 in that /8.

OK, network 1 that we're visualizing has been brought to a finer grain. So instead of looking at 16s, every pixel is a /24 in the address explain. So now we're looking at one block, same grid, but every pixel represents a /24. And the colour represents the intensity. And you'll notice some features in the movies that shows you ranges of activity or perhaps specific address points which are taking traffic, but keep an eye on the bottom left-hand corner, because that's the hot spot that takes most of the traffic.

OK, I'm going to plug in the sound and if there's a huge squeal, I apologize.

Is that better?

(Video plays)

VOICE-OVER: Frontiers of science. Documenting the latest developments of medicine and science in the space age.

GEORGE MICHAELSON: OK, so this is the view of the general network traffic over a period of time going into network one. Left-hand side is the global Internet. The right-hand side is network 1. And you can see from this, the traffic is actually coming from a wide range of addresses in the global network. But it's going to a fairly small set of addresses in network 1. Those tiny flickering points, those are the hot spots which are taking most of the traffic.

So this is an example of scanning. It's a little indistinct. But if you look here, you can see the beginnings of a scan that's going up the address space and if you look here, you can see the source address, which is responsible for generating that traffic flow. So you can see the scanner moving up linearly through the address space. Now, keep your eye on this source as it gets to the top. And bong! It's gone.

This one is an entirely different class of attack. It's coming from quite high in the public number space. Have a look at this. Now, that is an attack which is scanning every IP address across the whole of this network block over around 15-20 minute period. It was just saturation bombing every address on the net to try to see if anything out there would respond to it. Very, very rapid. This is actually happening all the time across the whole address space. Someone somewhere in the number range is receiving an attack like this. They just stride through the space. Because we're in network one, we're seeing the beginnings of this. But when it goes off the right-hand side, it winds up in network 2 and they just keep on going. Oh, there was another guy. Let's have some fun.

So did you see that flash there. This a slowed down version. Now, if you look at that, this is trying to say that the whole of the global Internet, all of it sent packets To one destination inside network 1. Now, that's not really possible, so what we're looking at here is a distributed denial-of-service attack with spoof source. They were trying to make people think that it happened, that wasn't really what happened.

This is in network 181 or 177. So this is a slightly different view, but you can see the intensity of the traffic outside of network 1 is really markedly low. There are hot spots, but it is different. This is quite nice. This a cumulative traffic going over here over the network period, and you can see the distinction between the low-order addresses that receive that, and the high-order addresses. It's absolutely clear, the conficker predominantly goes to the low order bit. The other thing is the sheer variety of addresses in the source address range that emit these. This is not a problem to point fingers at individual people for hosting the bad guys. It is everywhere.

So there's another one of these spoof source attacks taking place in network 181. Here we go. That's just another instance of people spoofing the resource address. I had some fun with this. I thought it was probably useful to probably reflect on this a little bit. I couldn't work out how to animate having them explode, I'm sorry.

(LAUGHTER)

That's it. Thank you very much

APPLAUSE

PHILIP SMITH: Thank you very much, George. Are there any questions for George.

DAVID WOODGATE: David from Telstra. George, have you thought about running similar things for any IPv6 ranges at this stage?

GEORGE MICHAELSON: Watch this space. No, we have already started the data capture for IPv6, and we think that that is an interesting story. We think it is a very important story but it is a story for another day.

DAVID WOODGATE: Thank you.

PHILIP SMITH: No other questions? OK. OK, so next up, we have Tomoya Yoshida and Frank Salanitri. Frank, you're going to start first. You're going to talk about route filtering And about handling with care.

FRANK SALNITRI: Good morning everyone. I'm the project and system services manager at APNIC. I'm going to talk about the APNIC quality assurance program, which is raising awareness, address reachability and collaborative testing with other organizations. I'll be talking for about 10 minutes, and then I'll hand over to Tomoya Yoshida who will be sharing his findings on BGP testing and he'll be speaking probably for about 20 minutes. So I hope everyone's enjoying the conference so far as a stand-alone meeting. It's turning out to be a great success. However, it is not just APNIC working on its own for the success, it's a collaboration for many different groups, such as the program committee, sponsors, the venue and APNIC Secretariat staff. As well as yourself. Similarly, the quality Resource Quality Assurance program needs to be there. There are many facets to the program, including training, outreach, testing, and of course, you, the consumers of the resource itself.

So I'm just going to talk and give a brief background of filtering In general. Talk about what the problem is and then talk about what APNIC as the Resource Quality Assurance is trying to do. And then I'll be trying to talk about Tomoya about this BGP collaborative testing.

So, as a background, you know, why do we... why are IP addresses blocked? There are many different reasons why filtering occurs. It can be due to outdated bogon filters. Possibly abusive behaviour where you choose to block an IP address due to a spamming or a DOS attack. You might choose to have policies on filtering traffic in and out of the networks base on how we choose to access particular machines. So what sort of methods are in use out there? Predominantly, in most cases, filtering Is done through routing. Application filters, hat's mainly done by email filtering when the applications filter based on email header content, and also firewall filtering Where we also experience some undesirable behaviour from an IP address and might choose to block it.

So, as I said, before filtering, it's a good thing, and hey, what's the problem? So, what if route filters are not updated automatically? And you know, we have to remember to update these bogon lists? Or what if I got DOSed by an IP address yesterday and I manage my firewall, but say two weeks later, it's in legitimate use by an ISP. The problem is that we're starting to filter good packets from people that we may want to do business with, but only if we knew that their website existed or possibly if we had just received their legitimate e-mail. So we're finding that it is the RIR is being blamed for this or being seen as responsible for allocating these bad address blocks and we think... well, we assume that the number of complaints will start to increase as we start to reach IPv4 exhaustion and we start to receive /8s from IANA that we start to call the bottom-of-the-barrel, where we, for example, say the 1/8, which George spoke about, where organizations in the past have thought - well, I don't think that 1/8 will even be allocated by the IANA so I might make use of it for my own private numbering, which then through misconfiguration could be exposed to the real world. There's also the examples that George gave where they'll look at the VoIP settings as a default setting. Interestingly, I had feed back from other people where a certain net cafe, we were actually using address space from 1/8, but I think that that is possibly being fixed by now. But of course, obviously, we'll start to have to recycle, as we reach exhaustion, we'll have to start to recycle and to reclaim blocks where, as we've been saying, the new holder will start to get penalized for the bad behaviour of the previous owner.

So just upfront, what can you do? And this is just a general messaging that we've been trying to express through our website. Through our printed material, basically, manage the bogon filtering responsibly. Make sure that the ACLs are up-to-date and we keep referencing back to Team Cymru and IANA saying, visit those sites regularly, keep up-to-date, see what's been allocated. You know, filter responsibly.

So Resource Quality Assurance. What has APNIC been trying to do? Well, we started discussing this program late last year and it was just some time for the allocation of the 1 and 27/8 back in 9 January 2010. So we don't expect to work miracles, but we do promise to be more proactive and put in place some sort of a long-term strategy. But of course, there's no one simple solution to fix everything. It's a number of things. So one of the things that we talk about in RQA is community awareness, or outreach. We're trying to build relationships with reputable organizations, and we've had some success with getting introductions to Team Cymru and Spam Assassin. We're trying to get introductions to get acknowledged and involved in possibly even messaging and anti-abuse working group. But it sounds easier than it is in practicality. I mean, you, yourselves - I'll give up an example. Has anyone here been receiving emails lately b from some guy who tells you that he's got photos of your wife? ()

ALL: Yeah.

FRANK SALNITRI: And the other thing is that he nicely zips up all the files. Isn't that nice! But of course, every time I see it. And my manager, Sanjaya, we even laughed saying that he has photo of my life and he laughed as well. But anyway, I ignore them and delete them and delete them. But what if someone, an acquaintance of yours sent you an email saying "I have pictures of your wife." What would you do? Would you open it? What would people do?

NEW SPEAKER: Depends what friend it was?

NEW SPEAKER: Delete it?

FRANK SALNITRI: So my comparison of what we're trying to do is that if we were just to send emails to people that we don't really know. You know, you go to a website, say some particular spam product appliance, and you go to their "About Us" and ask for the list of contacts there. And you try to sent them an email. They don't know us and they probably don't really care. They're involved in the business and we don't really appreciate or understand what APNIC does. And forgets all about us. Deletes the email. So, if they were introduced by... sorry, if we were introduced by a friend of theirs. Of course, then they would take notice to the email and they would actually read it. So that's the comparison of what I was trying to make with that example.

So we've also been trying to, through education, we've been involved with the training team and looking at where appropriate messaging about bogon filtering Can be placed in the Training material. Also keeping the who Whois data accurate. There is a policy in place there, but we've been looking at looking at historical emails that APNIC has been using for various fields like change-by or notify-by. So there are simple things that we can actually do as well.

So, when APNIC receives a new /8, the sort of thing that we do to try to do to minimize problems with routability. First up, we spam all of the NOCs that we can in our region. And then, through our sister organizations, the other RIRs, we then try to spam all of the other NOCs that they're involved with. We do reachability testing which is valuable with RIPE NCC, and then we also, in addition, try to do as much of the other testing that we can. We've been doing Lots of great work with NTT Communications and also with APNIC R&D and the connections that Dave had with Merit and other organizations that we've had. So we've been having some great collaboration there.

Now, if any of you feel that you might be able to help us or could collaborate in the future, please come and see us. Come and talk to us and send us an email. Please let us know.

APNIC is also looking at some future projects in terms of being able to amount some sort of testability tool that we can implement ourselves. APNIC, we're not a huge organization with huge infrastructure and you know, can easily do this. But you know, the sort of testing that we're looking at doing Is at the application level, trying to test mail, http, there's a list of services there on that slide. But also testing outgoing and ingoing connections. At the moment, concentrating on v4 connectivity, but in future, hoping to expand over to v6 as well.

So, at the moment, we're just talking about the possibility of implementing these test sites or these solutions. We encourage feed back from you. We would love to hear what you think about it. So the first proposal was actually establishing mini-sites in every continent around the world. Using different transit providers. So, then we'd have our test prefix possibly sitting here in Brisbane and we would be doing two-way testing, testing going in to the prefix from the mini test sites around the world. And also reachability from the test prefix going back out to the mini sites. At the moment, we have a modest plan of one test site at each continent, but it is possible to scale it to possibly 200 mini-sites in two years.

So this is the first idea that myself and Sanjaya have been thinking about. The second option that we've been looking at. It follows the methodology or the principle that Geoff Huston has been using for the v6 reachability testing. Basically where we place a one-by-one graphic pixel on APNIC's website. We get a fair amount of traffic each day. A noticeable amount of traffic. So that one-by-one graphic image resolves to a test prefix. So by doing that, when they hit our website, we can see if that traffic coming in can reach that image and also the... and vice versa. So this is a very simplistic approach and it is something that we could quite easily implement, and I think that we possibly will in the next few months.

FRANK SALNITRI: I would like to hand over to Tomoya. If you have any questions, please wait until the end of the presentation. If you have any feed back, can you introduce yourself to me and to my colleague, Sylvia, who will be here today and will be available during all of the breaks.

TOMOYA YOSHIDA: Good morning, my name is Tomoya Yoshida from NTT Communications. I would like to talk about the collaborative testing between APNIC and the NTT Communications. And before I talk about the detail of my test of the IP addressing in the world, it may not always reach to every network, in case of the new IP allocation in particular, so we often encounter a few things. You know that the bogon word comes from the word bogus, meaning false and fake. In the bogon route is the prefix which is not advertised or must not be advertised usually. And you know, the private IP address, RFC 1918 10/8 or other private address space, or the link back local loopback address, or the benchmark, multicast address which is the least of the bogon list.

And also, many people put in the bogon filtering The IANA reserve. This is the one big issue, so in this case, the ISP-B set up the incoming bogon filtering Between the ISP-A. But ISP-B said that setting up the bogon filtering between the ISP-A, and in this case the ISP-A accidentally announced 10/8 but ISP-B set up the bogon filtering so that it doesn't receive the 10/8 network from the ISP-B and also that ISP-B doesn't announce to the 10/8 for the customer. This is the bogon filtering.

And you may know about the ESTA problem. So that is the Electronic System for Travel Authorization. So when we go to United States, you should fill in your passport number or the hotel information or the information of the travel before we go to the United States. But this is my experience, and two years ago, we have two ASes. One is the AS 38639. The HANABI means Japanese firework. And the AS 4713, provided by NTT Communications. So we have the two ASes connected to the network. And for the light side, this is a commercial AS it is OK to have access to the commercial website, but using the 115.69.224.0.21, is not reachable to the website this is the bogon filtering of the border of the DHS AS.

So 115, you know that 116 are allocated to APNIC from IANA three years ago. So after one year, so the filtering Is still remaining in this new allocation block at that time. So we encountered many bogon filtering.

So as my colleague said, I tried to advertise the whole /8 filtering in 223 /8 for one week. And also, I checked the reachability using the BGP and 14/8. Or 223/8.

So this is the result of the 14, 223. And also, I checked the 27/8 reachability.

And as you can see, the 36 was in the route view 115.69.224.0. So I could see the 36 route from the ISP using this using this route. But 27 or 14, 223/8, that was not a good number of the BGP route information, for the route view. And so... approximately 20-30% are not reachable from the new allocation IP immediately after the new allocation from the IANA to the APNIC. And the 27 was not reachable, almost 10%.

And I found the very interesting things is that there were differences between the 14/8 and the 223/8, even though the same allocation of timing. So you can see, the 14/8 was 31. But 223 was 28. Three differences between these two prefixes. But the same allocation timing, so I have no idea. But probably a different way of filtering for the ISP.

And the... this is the allocation status of this year. We had six allocations from the IANA, half of the new allocation space of all the RIRs. We checked in April this year, and it was here. And before thinking about the 27/8. After the three months, I checked. But 10% are not reachable.

And also, I checked the 1/8 reachability in June. The five months after the allocation to the APNIC. But 10% are not reachable even five months later.

And after one month, there were no big changes, one month later, there were no big changes. So it was not in good reason.

So the result was really similar to the live debogon project website result. So from the 70% to 80% is the reachability percentage. And after two or three months after, saw that it is going up to the 90%. It is very similar result which was done by NTT Comm and APNIC. And this was the ping reachability test. I picked up more than the 20,000 ASes. Just like ping checking. And this was in April this year. And 203 is a very old IP address and this was 2% of the no good condition. But 27/8, this is 11% unreachable. This is big differences between these two, and also, the 1/8 and the 203 tested in June, it's a similar result. So in this result, so that we can see about 10% is not reachable. And probably now, it is less than the 10% because the 27 is probably gone to the RIR, almost.

So I think that currently, it is a good situation.

This is the blacklist which is collected by our NTT Communications commercial ISPs based. So we have 72... the name of the blacklist... it's inspired by every time I couldn't access these websites using the new IP address block, so I check the 27/8 in this April. So about half is not reachable, and also, the 1/8 is also in the same condition. So approximately 50% is not reachable. This is the ESTA website included and the Major League Ball, American Airlines, and BBC. It is very hard to access to the airline for our customers.

So at that time, I told them to please disconnect and re-connect. So after that, so that they could receive the other address blocks so that they could have access to those websites. So this is the result.

And this is another trial in the 1/8 network for the JANOG meeting last month. So I set up to the network connectivity to the JANOG meeting using the 1/8 address block. And from the conference hall, we connected to the AS number and to the Internet and this is the list which is not reachable. And the metro.tokyo.jp, it's a very important website, but we couldn't access this website using the 1/8, and this is some Government websites. A hotel website. Mizuho-tb.co.jp, it's a very critical website. So in Japan, we had many of the websites which were not reachable.

After that, about half of the websites are reachable, but you can see the IETF.org website. Tools.IETF.org was OK, but I think that the network had some issues, so I believe that now it's OK using the 1/8, but this was the result of the JANOG meeting. So at that time, the 1/8 usage was approximately one third of the usage.

The red one is already assigned to the LIR from APNIC at the JANOG meeting so that one third block to the LIR. And this is the example of the allocation to our AS at NTT Communications. We received recently 27 space and also 223/14 space.

And I checked the reachability, the routability using the router view. But 27 is probably 100%. It's similar to the old one. But 223 was not in a good condition. So because the allocation timing is different between these two, so about 10% is not reachable, I think. That's in a very bad condition for our customers.

And finally, so 49/8 and 101/8 was allocated to APNIC this month, and I started to advertise from this Monday and I still continue to announce to there globally. And the capturing way is the same one for 14 and 223 TCP dump.

And then this is the result of George Michaelson said up here, it is the same condition as the 445 conficker. This is the packet-byte based. So the PPS will be more higher rate, I think. And the second one is the UDP 1434, and this is there. So these two are major packets coming to the 2/8. And the partition of the space, you can see the 49.0.0 and the 101.101.101.2, so we can see there some specific address spaces this time.

And last night, I observed, we all observed some invalid route advertisement from 101.101.101.0/24 from this AS number. I don't know what the issues were, but there was a few minutes leak globally yesterday night.

And this is the comparison of two occasions of 14 49 and 223. This is the one-week scale and this is the one-day scale. And they're almost the same condition. The 1434 packet is the major packet. So it is a very similar result.

So, for the future, the observation of IPv4 will be continued and also, we can test IPv6 and as Frank said, a construction with the checking way in regular, not only the routability and reachability test. And using the new IP address block, next Monday we have the AUSNOG, so please use the new IP address block so that we can improve the reachability global. And the last JANOG meeting was very successful so it will surely improve our reachability using the new IP address block operation event.

That's it. Thank you very much.

APPLAUSE

PHILIP SMITH: Any questions for even Tomoya or Frank? No. OK. Thank you both very much. Next up we have Matt Lepinski who is going to talk about, do we need a registry for IPG information.

PHILIP SMITH: Are there any comments for Frank or Tomoya? No? Ok next we have Matt and Do we need a registry for IP geo location?

MATT LEPINSKI: Yes, wonderful. Hello, my name is Matt Lepinski. This presentation is collaborative work with my colleague, Richard Barnes, who wasn't able to make it here. I'm giving this presentation because I have a question that I would like to raise for the community, hopefully get some discussion around.

Do we need a registry for IP geolocation information? I'd like to start with some background. As I'm sure you all know, content providers are increasingly interested in tailoring their content to the geographic location of the user who is viewing the content. The most common example of this is wanting to put up a home page for my company which appears in a language that the user is able to read? Also, if I have a news or weather site I might want to display local news or local weather that is relevant to the person who is visiting my site. Finally, another example is I, as a content distributor, might have an agreement with the producer of certain content that I will only distribute it to people in certain countries or certain geographies.

So, to facilitate this goal, content providers need to have data to map IP addresses for incoming web requests to geolocation information that they can use for localization or to create a relevant experience for the user. And just the examples that I looked at, this isn't geolocation information that needs to be very precise. We're looking generally for language. Many countries speak a single language or at least regions of countries tend to speak the same language. If I know, for example, what province I'm in, often times that's enough to produce local weather, local news, correct local language. So, let's see, to support the needs of the content providers, there's a number of proprietary commercial location service providers. Two big ones are Max Mind or IP2Location and their business model is that they supply to content providers, essentially databases that map IP addresses to geography. Either the content provider or the proprietary provider of these databases needs to get this information. Somehow, a common way that they get it is by mining the Whois database. In particular, there's a lot of geography-correlated content in whois - things that were not originally intended to mean - this is where my customers are, but things like technical points of contact or corporate addresses which are sometimes correlated with where people's customers are. Additionally, companies that do this have their own special sauce. Their sophisticated heuristics that they use to merge data from multiple sources and sometimes use additional validation sanity checks. Things like latency checks and the bottom line is that from the point of view of myself, and probably most of the people in the room, this process is a black box.

You know, there's a bunch of inputs that we don't know about, don't have any control over, that going into a black box and out comes a location which determines the web experience of our customers.

So basically, the problem is not that IP2Location mapping doesn't work. I mean, usually it does work. The commercial products are by and large high quality. And most of the time, for most of the people, when you go to a website, you have the correct experience that the content provider wanted you to have. So the reason why I'm here is because the failure mode for the IP geolocation system is in my opinion, not very pleasant. So first of all, I apologize. I have an error on this slide. Some of things were difficult to test remotely, so Max Mind is a large provider of IP geolocation services, and they're kind enough to have a demonstration tool on their website where anyone in the world can make a small number of queries to test their product.

So Max Mind does indeed believe that we here at APNIC in Australia are actually contacting them from the Philippines. And however, Google is smart enough - I don't know what Google's special sauce is - but they're smart enough not to display the Filipino version of the website to me. They're merging data from different sources and doing something that gets me an English language search page. But on the other hand, I do have another example, which was kindly given to me by an anonymous APNIC participant here.

The Australian Broadcasting Corporation. If you try to go to their site from this meeting network and view shows on the ABC, they will not show you their streaming content, because they only do that for people who are in Australia, and we are not in Australia. So, actually, of course, I mean that we all know that we are in Australia, and we should get experiences that are localized for Australia. But I understand that meeting networks are hard, because this network moves around a lot. But there's other cases in which people end up with incorrect results on these IP geolocation services. For example, if you were an ISP in Malaysia, and you got your address space from your upstream provider who happened to be incorporated, have a headquarters in Singapore, it is likely that many websites would give your users an experience as though they were in Singapore, instead of correctly determining that they were in Malaysia. I'm not trying to pick on the IP to geolocation service providers. This is a hard problem. They don't have by and large good sources of information to deal with, so they do the best that they can, and most of the time, they're right. But when they're wrong, users go to the web. They go to some hotel home page and it comes up in a language that they don't speak and so users then do what users always do when the Internet doesn't work - they call their local ISP support desk and then we have emails like this appearing on the NANOG list. So this is here. I have a couple of examples here of traffic from the NANOG list in the past year or so. People who find that their users in this case, Google, is redirecting their American United States users to the Google Canada site asking, "How do I find a way to get my data uploaded to all of the location providers' databases as quickly as possible? " Or, "Does anybody know the contact for Google and Yahoo? The NOC at addresses don't seem to work." Can anyone at Bing or Microsoft help me because I need to get them some location information?

So if you have problems with the large content providers, and your users are complaining, then it seems that in many cases, people, ISP employees go to the network operator community and try to figure out who it is that they need to talk to in order to get the right geographic data for their users into the right databases. Now, the problem with this approach, other than the fact that it is labour intensive and creates excess traffic on lists like NANOG, is that if your users are having problems with Microsoft or Google, probably your chances of getting these problems resolved are pretty good. But if they're going to some website that I've never heard of before, that maybe you've never heard of before, and having a bad experience, then it is much more difficult to track down where is it? Which location provider is selling location services to coolnewsearchengine.com that my users are having a bad experience with? And this is, in my opinion, a situation... well, let's see. Yes, in summary. In summary, things work pretty well most of the time. But when they don't work well, customers get the wrong content ISPs get support calls and ISPs are left scrambling, trying to get the right data to the right person so that their customer can have a good experience. I would like to think that there is a better way to address these sort of failure modes. And the reason that I'm optimistic is that this is a situation where pretty much everyone involved wants the same thing. Content providers want to deliver geographically appropriate content. Location database providers want their database to be accurate and users usually want to get content that's appropriate for their geography. Sometimes they want to watch Australian TV from Indonesia. But most of the time, end-users will not call your support line if they get geographically appropriate content. If they're blocked out of getting Australian TV for legitimate reasons, they're much less likely to complain, and really, ISPs are here to serve their customers and they want their customers to have good and appropriate experiences when using the Internet. So maybe, what we need is a standard way for ISPs to tell those who are interested where their networks are located.

So, why not make a registry? So, we already tell a lot of people a lot of things about our IP address allocations. So there's information available on what organisations are registered for which blocks. What ASNs will be originating which network blocks? Who to contact if there's trouble with a particular network. So geolocation is just another data element, and you know, perhaps we can provide a better user experience if there's a way for ISPs to voluntarily have control over what information is available, and the accuracy of that information. So that way, if there was such a registry, if an ISP had problems, they could opt-in and put geolocation data into the registry. Hopefully the location providers, the content deliverers would call this registry frequently if it was available, and problems would be corrected with little work on the part of the ISP. Or even better, if there was a registry, one could opt-in before there was trouble and maybe users never have a bad experience with poor geolocation. Obviously this won't solve all of the problems. But I think that as a compliment to other techniques that they use to create the IP to geolocation services, that having a registry of information provided by the owner of an address block is a reasonable idea, in my opinion. So what might this look like? When I talk about this to different people, different people have different ideas to what a registry might look like. So one thing - we already have a lot of geographically correlated information in Whois. But nothing that specifically says, this is the geography where the people using my network are located. So possibly we just extend Who is and explicitly put in, this is where the people who are using my network are located and in this take case. Because this is a conference network, maybe we put in the full address and maybe put in a particular province and something that says "Metropolitan Tokyo" to give geolocation content providers a sense of where the users are.

Now, the advantage of this is that it re-uses existing databases, tools, provisioning systems. On the other hand, it's not clear what the right structure is for putting this type of geolocation data into the Whois in a way that makes it easy to parse and easy to use think I think at the end of the day is the goal.

So as far as re-using work that people have done elsewhere, the IETF has developed a web service called HELD, which is a request response protocol asking for geographic information, and in the process of this, the IETF working group consulted with a number of experts in location, geolocation, GIS folks and came up with a standardized http or XML format for encoding cities, metropolitan areas, regions, a point with a big circle around it, however is the most convenient way to describe where it is that a particular network is located. And so we can could use the IETF HELD web service, provides more structured location format. Possibly using http makes internationalization easier, maybe? Could still bootstrap from WHOIS by putting a pointer in whois to the web registry.

And also, and this is where I will take a slight diversion. So, personal interest of mine - location URIs. One advantage of doing things over the web is that it allows for arbitrary amounts of indirection. In particular I've heard it said that no system can be better engineered by introducing one additional option for a layer of indirection. So a web registry could provide a static location like Queensland, Australia. Or it could provide a URI to location.example.com slash, slash, to something which is run by whoever it is that runs this network, to allow for an ISP to more easily serve location, to have control over the frequency of the updates of the location if they want to manage the servers themselves. Also, by managing the servers oneself, it becomes possible to give different answers the question - where is your network? Depending on who it is who is asking. In particular, if someone had an advertising partner who they want today share more fine-grained postal code style information with a trusted partner, they could do so, and still give country level Australia information to the rest of the Internet. Finally, APNIC is putting a lot of time and effort and resources into issuing certificates that certify someone as the legitimate holder of a piece of IP address space. And additionally, APNIC is creating a repository for objects that are signed using the certificates and can be validated in this fashion. So possibly, another solution is to put inside some signed some signed object a standardized location format, perhaps the same XML format or http format which is used for the HELD protocol or maybe something else, and sign it using a public key associated with a resource certificate. And possible advantage of this is that it leverages work that's currently being done in support of routing security to be able to get objects out there that are validatable using these resource certificates. Additionally, whoever it is that is using the location data knows for certain that it was provided by the person who is the correct holder of the IP address resource which, perhaps, gives them additional assurance in using the data.

So I think I want to end with - I think that there's some promise in developing a registry for IP address geolocation information. So certainly, this isn't the panacea. It's not going to replace existing methods of doing IP address geolocation. But as I said at the beginning of this presentation, the process today is very much a black box to me, to most people who see it from the outside. And this, at least, having a standardized registry that we, as a community, could publicize, gives ISPs who own the addresses the opportunity to have an input into this black box. So still, there is, this is operator-provided data. There's no guarantees of accuracy. But on the other hand, there's no guarantees of accuracy with what we have today. People who are putting data into this registry probably would have an incentive to put in correct data, because they want their customers to have good experiences, and even if it is not perfectly accurate, it can still be a valuable input into this proprietary black box that churns out IP geolocation mappings. And there's some cases where registry might call for accuracy in the data. There may be IP geolocation things used for heavily-regulated areas like determining proper taxation. And so certainly, a registry is not going to solve those really hard problems. But you know, maybe for the average user and the average network operator, having an input into the black box might make things better than they are today.

So, in any case, the questions that I wanted to leave you all with are, first of all, is there a problem here that we're solving? Personally, I'm not happy with the failure modes in the status quo, but if, in general, the community is happy with the status quo, then there's nothing more to do. Are the types of approaches that I discussed for making a registry, are those the right types of technologies? Are there technologies that we haven't considered that we should be considering? And finally, if there was a standardized, centralized, public registry that you can put to say, my customers for this network block are in Queensland, Australia, would you contribute that kind of data for your network?

Anyway, thank you so much for your time. Love to hear from you and I think we're probably about out of time in this session.

PHILIP SMITH: Thanks, Matt. Any questions? Any answers to Matt's questions?

MATT LEPINSKI: So please think about this, love to talk to you during the breaks.

GAURAB RAJ UPADHAYAl: My question is - we have this thing called Whois in IRR in this and that is what the operators are supposed to update. They have not done so and there is a lot of wrong data in the IRR. Why do you think a new registry is going to be useful? Why do I want to put the data twice?

MATT LEPINSKI: So first of all, I think that this isn't data twice. And I apologize if I'm mistaken, but I think but I think that part of the problem is that there isn't actually a place in the IRR database in my knowledge that says, this is where any customers are? I mean, there's other... I agree that there's other information in the Whois databases which isn't kept well enough up-to-date, and I agree that this isn't generally going to solve the problem of people wanting to keep things up-to-date.

GAURAB RAJ UPADHAYAl: Yes, I think that the IRR, you can go and put the customer assignments is your choice whether you want that information to be public or not. So all of the RIRs give that function. And if they choose to have that, I don't know why they would want to make the location of the customers public. We are creating what has failed with IRR and then the RPKI is trying to address so I don't see this registry being much more useful.

MATT LEPINSKI: OK, thank you.

YI CHU: From Sprint. I speak in support of your view. You vented a lot of my frustrations given the failure when geolocation doesn't work. From the ISPs perspective, it is a very hard problem to tell your customer that it actually is not really your problem, your ISP's problem! So I think, would it help to go a long way, if there's some sort of guideline that says, OK, from the ISP's perspective, when you update your whois record, you put in the country code, your location code, and that's all you need to do. And the rest is up to the geolocation, the content providers for them to deal with there?

MATT LEPINSKI: And I certainly agree that part of the problem that we have here perhaps part of the problem that we have here is that publication, a marketing problem in the sense of, we need to get ISPs somehow, and I mean, this is a hard problem and I don't claim to have the answer, but I would like to find it. We need to get ISPs and content providers, geolocation providers on the same page as far as if... I mean, what do I want to say. There's something of a chicken and an egg thing. If ISPs are all putting the location for where the end-users are in the same place, wherever it is that that place is, and they do something simple and then they're done. If ISPs all agree on what the simple thing is they need to do is to make this work, then content providers and geolocation providers have an easier time going going and finding the right information. But I think that there is a problem that in many ISPs, they're not putting that location anywhere, and as a result, location providers, content providers are looking in a million different places and somehow we need to bridge that communication gap.

YI CHU: Yes, I totally agree, I think some sort of guideline from APNIC, from ARIN, other the registries would help along with.

SANJAYA: From APNIC. So, just to give you the experience that we have in the APNIC Secretariat. The enquiries that we have in the Helpdesk about the this issue. And we have actually contacted some of the geolocation providers just to test the water. Where exactly is the information that we help to use for that database. It seems like the majority of them, the primary FTP stats files that all the RIRs have agreed on a specific statistic format and it seems like that would be the primary input for all of the geolocation providers and then they add on top of that.

MATT LEPINSKI: Special sauce.

SANJAYA: Yes, special sauce exactly. So I'm just sharing that information. It could be useful in that information.

CHAMPIKA: I'm from APNIC and I'm relaying from the jabber chatroom. There is an answer from Richard Barnes to Gaurab Raj Upadhaya. The answer is that another answer to the question is that it is not routing information, so it doesn't go into the IRR, and the RPKI approach addresses the update problem since the people will need to keep it up-to-date to get the traffic. So that's an answer to the question which was asked before. And there is another question from another of our guests.

And the question is - "As a user, I would love to be able to adjust my location to be able to get content which is blocked from me."

MATT LEPINSKI: Yeah, I appreciate that. I think that's a problem which I think we're never going to solve! I think that there is hope. I think that there is hope as long as everyone wants the same thing. Sometimes when users want things that are different to what content providers want, I think we're just going to see. I don't see a technical solution to that at all.

JUDITH DUAVIT VASQUEZ: From the Philippines. Matthew has a good point about the need for the extremely localized... this, what you want done, I can't see on a continental plain because of the huge amount of data required. Actually, OK, just to recap. Where basically my family is in the broadcast business and it is true that there is a fragmentation of markets. We're actually seeing content, not on the national scale, but on a provincial scale in local dialects. Which is an analogy to what is happening on the Internet, especially with the rise of IDNs, probably in the next year or two years from now. You can't do this in IPv4, you need IPv6 to do quality IP geolocation, for me. So we're designing something, but it will be in IPv6, because the telcos are the ISPs in the Philippines, so when you're talking about 90 million Filipinos across our landmass, there's no way.

They're on DHCP. So how can you do localization on DHCP. So v6, and I'm underlining the importance of IPv6 for this particular requirement of yours and I'd like to talk to you.

MATT LEPINSKI: Yes. Thank you. I certainly believe that the problem in general is easier with IPv6 than with IPv4. I think in some circumstances --

PHILIP SMITH: Sorry, we'll just wrap up anyway. Thanks very much to everyone.

^ Top    < Home