Transcript - Lightning Talks

Philip Smith: I think we should make a start to the Lightning Talks session.

Welcome back after the extended tea/coffee break, following the early end of the Policy SIG.

I don't know, I tend to see this as kind of a bit of light relief from the earlier proceedings of today, at least I hope we treat it all like that in a way.

So we did the call for lightning talks at the start of the week. As a reminder, a lightning talk is a short talk on some current hot topic. By lightning talk, I mean that it's a short talk, not a 30-minute talk delivered in 10 minutes. So, note to all speakers, please don't talk at 150 kilometres an hour or whatever.

Again, please realise that a lot of people here do not have English at their first language, so if we can keep the presentations comprehensible, that would be useful, please.

On the screen there, I have eight presentations. We only have one hour for this, because the transport to the social event starts leaving pretty much about 5.30 and folks who want to go to it probably want to change or drop laptops back at rooms and so forth, so we finish at 5 pm, unlike what it says on the agenda.

So I'm looking at my laptop here still on Brisbane time.

What I'm going to do is I have given each presentation number 1 to 8 and so I'll just pick them out of -- I don't have a hat, but I have a little jar here, somebody had finished all the sweets, so I have a jar here and I'll call the first presenter up once I pick up the number. The number is number 7, which is Che-Hoo Cheng. Your 10 minutes begins now.

Che-Hoo Cheng: Good afternoon, I'm Che-Hoo. I will talk about HKIX especially the plans for 2013.

Here is a simplified diagram of HKIX. As of this moment, we have one main switch at our main campus in Sha Tin, that is Cisco Nexus 7018 and we have another Cisco Nexus 7009 at HKIX two sites in Kwai Ching, but most people connect to HKIX 1 in our campus. The two sites are connected with two 10G links and here is another diagram about HKIX. The key point is we support bilateral peering.

Of course, because we have a lot of costs to maintain this IX, so we have a special charging model.

The first two ports in fact are free of charge, but if you ask for more or if you ask for 10GE ports, we may charge you, depending on your traffic. If your traffic is high, then you may not need to pay, but in your traffic is low, we will charge you. But still, we want to maintain not-for-profit status.

Some information about the current connections status. We have more than 220 gig traffic at peak and we have 175 automated systems connected in total. We have around 5910 gig connections in total and we have around 255, 1 million megabit connections in total.

Here is traffic statistics. We broke our record about a little more than a month ago.

We had a record, because there was typhoon in Hong Kong and everybody stayed at home and did Internet surfing, so that's why we broke the record.

But afterwards, our traffic has picked up, mainly because the Premier League has restarted and we have 210 gig here, just the last weekend. So we are confident that the traffic will go up again.

Here is the number of routes on our root server. We have about 60,000 routes at peak for the IPv4 and about 6,800 IPv6 routes at peak.

We are connecting not just Asia but also other continents. But for Asia, in fact, we have more and more members, new members from around Asia, even including Cambodia and other Asian countries.

We carry more on in Hong Kong routes than Hong Kong routes now, so we in fact help keep intra-Asia traffic within Asia. I will say HKIX is good for intra-Asia traffic.

As for IPv6, we have successfully implemented software to look at the net flow version 9 layer 2 data and we confirm that our IPv6 traffic is around 1.2 per cent when compared with total traffic. I will publish this data regularly on our website and hopefully we'll see higher growth in the future.

Talking about us, we are ISP neutral, telco neutral, data centre neutral, content provider neutral. We keep confidentiality and we are not-for-profit and although we are a university and our core business is not doing IX, but we think because we started it, so we think we have the responsibility to continue to do it.

But we need the support from others, especially from the government. HKIX is very much like a infrastructure at airport in Hong Kong.

Going forward, of course we see a lot of potential for traffic growth, like we will have more and more new data centres in Hong Kong, starting next year and we have a lot of broadband access, cloud services, high-speed mobile access.

Our traffic will continue to grow, but the case is we only have one switch in HKIX1 and we only have less than 10 10GE port left and less than 40GE ports left.

We receive request for 40G and 100G interfaces, so we need to support those soon. We see it is also a big concern, because we only have one switch. We cannot afford any performance bottleneck and we must cope with continuous technology changes.

The income that we receiving actually can only cover the operating expenses, but we need money to buy equipment from time to time, which is very high end, very high spend equipment. Our auditors have already said we are subsidising the operations, so we have tremendous pressure to change our model.

Here is the plan. For 2013, we'll establish one more core node in our new datacentre, close to the train station, which is actually about more than 1 kilometre fibre distance away from the current datacentre. We'll call the new node HKIX1b. We don't want to call it HKIX3, because it's our core node, so we'll call it HKIX1b and we'll build equipment over there, switches and root server and so we can -- we'll provide site resilience and chassis resilience in addition to card resilience. Over there we will support 40G and 100G.

We are glad that we can have government funding, but it's one-off funding to support our capital expenses at the HKIX1b.

But talking about future, because we need to be self-sustained in long term, so we need to change the charging model. So we'll gradually change to the simple port charge model, starting next year and in fact, I would say simple port charge model is fairer to everybody.

We also have possible long-term plan. We have HKIX2, which is at one of the commercial data centres in Hong Kong. We hope we can have HKIX3, 4, 5, so that we can support more connections and also allow people to connect to us more easily.

That's it.

Philip Smith: 57 seconds for questions.

None at all? All right. Thank you very much, Che-Hoo.

Che-Hoo Cheng: Thank you.

APPLAUSE Philip Smith: Next up we have No. 2, which is Xing Li.

This is talking about the IVI deployment at APRICOT 2012 in New Delhi.

Xing Li: Actually, my presentation is very short, shorter than 10 minutes, I believe.

Several things: first is actually if you were in New Delhi at the previous APRICOT meeting, we have set up SSID, which is called IVI, stateless translation between IPv4 and IPv6, and we run this test and also the record.

IPv6 access actually is quite interesting, because we do stateless translation, so actually the IPv6 address is embedded with IPv4 address. In that case, actually, you have to run DHCP v6 state 4 and Windows 7 can support that, but not Windows XP.

So that's something interesting. The traffic, because of the DHCP stateful issues, actually those SSIT is working the last day and the traffic reached about 500K in two directions.

You can see the ping results in the black box.

Actually, because that's IPv6 only host, if you want reach IPv4, actually you need to have a formula or DN64 to convert A record into AAAA record and ping that record, you got the echo replies, so it's the same. If you want to do, that's the same you have to, because IPv4 and IPv6 are not compatible protocols.

So Windows 7, coming Windows 8, whatever the system, can support DHCP v6 state 4, you can run stateless translation. Based on the report, actually, that's from Ericsson, there is RFC. This kind of IPv6 only client can support about 80 per cent of the applications.

However, this is not satisfied, because people want to run Skype and currently, there is no IPv6 version of Skype.

Another thing is like FTP, because the address is embedded into the application layer protocols. In that case, you need application layer gateway. So that's about 15 per cent of the occasions, you cannot really run translation between v4 and v6.

How to do that? I can give you example. This is CERNET, China Education Research Network, and I'm working on. There are two backbones. One is CERNET IPv4, another is CERNET 2, IPv6. CERNET 2 is IPv6-only backbone, so they are IPv6 only hosts. We set up a translator between CERNET IPv4 and CERNET to IPv6.

The IPv6 only clients connected to CERNET 2. So as I mentioned earlier, there are about -- it can only work for about 85 per cent applications, for example, surfing the web, no problem. Then actually, because we are doing stateless translation, so we thought we can translate IPv6 back to v4. In that case, actually, even Skype can work on FTP. FTP can work. You can see on the CERNET 2 site, we have IVI. That's the single translation and we have host based through a CPE, the second translator. In this case, you can support the Skype and other applications.

The good thing is, actually, single translation, the double translation can be mixed. If you only do web surfing, you don't need to do the second translation.

However, if you want Skype, you have to do the second translation. So that's good, because like in that case, we can have IPv6-only host, but still can talk to IPv4.

Another story from another point of view, actually, if we review the transition schemes between IPv4 and IPv6, actually there are three methods: dual-stack, internally and the translation. Actually, originally, they are NAT PT. The stateful translation and the later actually is phased out because of DS issue and like security issue.

For our research, actually, single translation, IVI and double translation and the like dIVI and those kind of things.

Another is tunnelling, especially automatic tunnelling, that's related to stateless tunnelling and that's 6to4 and 6over4 and Teredo and Isatap ^nme and later it's 6rd and 4rd, so that's encapsulation.

The IETF, in the past couple of IETF meetings, we try to merge the encapsulation and the double translation. So you can imagine if we do stateless double translation, actually, the outside behaviour is similar to encapsulation, actually with high decompression.

So double translation encapsulation can be mixed.

So actually, that's idea of transition. For the new users, we need to deploy IPv6 only because actually that's the future. So if the other side is also IPv6, we do native IPv6. If the other side is IPv4, we should try single translation first. If they're IPv4 only application, then ART issues, we can do double translation ... Double translation won't work, because that required update of the transport layer, for example, then we do encapsulation. So that's the less preferred method.

What's the meaning of transition from v4 to v6? So we should queue encapsulation, then queue double translation and queue single translation. If there is no encapsulation, even single translation, then we -- and into native IPv6 and that's the end of the story of transition.

Thank you very much.

APPLAUSE Philip Smith: Any questions? If not, thank you very much.

So next up we have No. 4, which is Richard Barnes.

Richard Barnes: So I just want to kind of add an epilogue or a coda onto a lot of the good discussions that have been going on with the RPKI this week. The one thing I thought was maybe missing a little bit from a lot of the discussions, the RPKI is this big wonderful thing, it does lots of good stuff for the Internet, but the question is if I'm an ISP, what do I do with all this RPKI stuff. Randy gave us some overview. I wanted to push this down one more level of detail to what does an ISP do to start getting involved, start making use of this RPKI.

There's three main things you need to do. You need to download the information from the repositories, you need to verify it to make sure it's all good, the security part and you need to make sure of it and use it in your routing policy and decide how you match the routes to match the security information that's in the RPKI.

We have some tools for this already. Of course we need fools to automate this process to make sure people aren't going to do this by hand.

The download thing, all the Rsync and so that's a pretty standard, pretty open tool.

Likewise, there's getting to be some standard tools in the router platforms, we have had some good presentations at the above the other day on how routers can read RPKI information once it's been downloaded and validated. What I want to talk about today is something to go in the middle here, this tool that can download and verify and process all this RPKI data and turn it into something a router can use.

What I would like to present is a tool called we're calling RPSTIR, which is an acronym I don't remember the expansion of. I think it's on the next slide. But it's a tool we have been developing at BBM that does, like I've been saying, it downloads the RPKI, it validates the information and it exposes it in a way that routers can digest.

We think it's pretty cool. It's secure. We have designed it to be really tightly conformant to all of the RFCs because we have been developing it in parallel with the RFCs so it does a really good job of verifying that everything is correct and we have been using it to do testing with some of the RIRs and some government groups to make sure that our RPKI implementations on the CA side are correct and they work well. You can benefit from the same security properties using this internally.

Like I said, it's interoperable, we follow all the standards for the RPKI itself and also for the protocol that we would speak between this validation system and routers. This is the so called RTR protocol.

So it's simple. You point your router at a server running the software and it just gets the RPKI information validated and it can use it for policy decisions.

Finally, it's open source. So you can download it, take a look at it, play with it and provide feedback, provide patches and get involved. There is a link to the software there and an email if you would like to get in touch.

That's all I have.

Questions? Philip Smith: Any questions for Richard? If not, thank you very much as well.

Richard Barnes: Thank you.

APPLAUSE Philip Smith: Next up, No. 8, Shin Shirahata.

Can I suggest you speak to Frank and I'll call the next speaker up.

So next speaker, No. 5, Andy Linton.

Andy Linton: I submitted it to AJ who asked me to put it up into the PC system. Sorry.

Next? Philip Smith: This is good.

Martin, your turn. No. 1.

Martin Levy: I also submitted my slides to the PC system, but two minutes before we started realised -- you can start the clock. 2 minutes before we started, I realised the problem.

Okay. Slides.

Okay. I want credit for these 2 seconds.

All right. Lightning, no kidding.

So I'm going to show you some information off collectsed BGP routes from various collectors around the world, focus on Asia, some work that we've been doing to try and continue our visualization of the BGP world.

The major caveat -- and I will repeat this throughout this presentation -- it's only as good as the BGP data that we collect from the route, route views in Oregon and RIPE RIS, it's not based on our routing tables and therefore, it it can only be taken as is.

Basically, here is the question is we asked: is there enough routing, is there enough v6 routing between various ISPs in Asia? Can BGP routing tables provide that insight? The answer we thought was yes. The methodology was simple.

We have this massive amount of BGP routing tables today.

They are feeding many different researches around the world. They also are feeding BGP.HE.net, so we took the database behind that and dealt with additional processing to try and build a graphical view on a country by country basis.

A couple of comments about doing this. First of all, a hearty thank you to the RIPE RIS guys, to the Oregon guys. A big thank you. I said we used the BGP database and the goal is to do this user friendly visualization.

But what we did was we took ASs and we used the RIR data from and the world to map an AS into a country code. That is not always perfect. It's not perfect for a large AS, somebody who is a global provider.

Anyway, this is work in progress, as you can imagine. But the idea and you can do this today, is to go out, look at a country code list, which gives you a list of AS that is we see active on the routing table, there are various sites that do this around the world, and gives you a list of ASs, then you take those ASs and say where's there adjacency? For example, if you take an AS in any particular country, and look at the adjacencies, it may have a transit that's global or it may have a transit that's in country, it may have customers or peers in that country.

What we do is we remove every BGP adjacency that's inside the same country. If we connect from Cambodia to Cambodia, we crop that information. Therefore, we end up only with the ASs with international connectivity, some form of international connectivity -- customers, peers or transit -- then sit down and try and map it appropriately.

We also do a count. We look at the number of connections between one country and another. So for example, there may be 10 or 20 or 30 or 100 ASs or more in a particular country. We look at them collectively and count them.

What do you end up with? What you end up with is a diagram like this. This is the v6 connectivity that we see presently inside Asia. Look for your country.

See where it interconnects. If this is wrong, let me know, but I'm going to tell you what my response is in a moment.

What we see here is we see some very large amount of v6 connectivity out of Australia, out of Hong Kong, we see it out of Singapore, as you would basically expect.

Then the countries peter down after that.

The ordering of the graphing here is that countries that have a larger number of interconnects end up floating to the top of the diagram; those with fewer interconnects drop to the bottom. In fact, we don't differentiate between peering and transit, customers or not.

The reason is we were just interested in how much interconnectivity existed inside a particular region.

The thickness of the line shows the number of potential ISPs or number of ISPs in one country that connect to the number of ISPs in another, AS number to AS number.

Notice that there's a bunch of countries that are marked as unconnected. They are just textual on the right-hand side there.

You'll actually notice that there's some interesting data there.

It says here that there's no one in Korea running v6 connected to anyone else in the world. We just know that's wrong. But this brings up the second point and is really the big issue here.

Every line on this diagram is there. It's out of real BGP data. However, there are still plenty of plenty and plenty of missing views. There always will be. You can never get the full view.

But you get as good a view as you can get from the collectors. Once of the things that you can say is that you need more feeding of collectors. It turns out you may be need infinite amounts of feeding of collectors.

But some of the other ones make sense.

But the thing is, this diagram doesn't have the rest of the world on it. So it doesn't show a connection from Hong Kong or Australia to the United States or to London or to Frankfurt.

So therefore, you can then go back and look at Korea and if you pull in the data, which we have done and realise that in fact Korea does have v6 connectivity globally, it just goes back to another country outside of Asia. It's lacking the connectivity at the moment inside Asia to enable bits to roam freely inside the region. But this is v6.

As we know -- and we hate to say, but it's the absolute truth -- v6 is just lagging behind v4. Let's look at what happens when we look at v4.

You end up with a spaghetti mess. Guess what? You're meant to. BGP can handle this. This now starts to show up the connectivity between different countries.

We start seeing a very few number of countries that are lacking interconnection inside a region. Basically, only two countries, that I presume are island countries, that are only getting international connectivity over a satellite and potentially let's say coming out of the United States.

But the reality here is that all these other countries have some sort of connectivity. Maybe not much, but some.

The thickness of the line again shows the amount of BGP ASs in each side. Hong Kong floats to the top.

Australia floats to the top. Japan floats to the top.

Singapore, et cetera.

So as you go down to the bottom, you start noticing that some places and -- in fact actually I know we're standing in Cambodia, but it's not a bad thing. In Cambodia here, we see the lines, there's one going all the way around the left up to Hong Kong. Che-Hoo mentioned that Cambodia ISP is available at Hong Kong Internet Exchange and then you see slightly smaller lines and then other ones being fed from Thailand and Viet Nam, which makes perfect sense based upon our trace route experience inside the room here.

For v4 and v6 to be equal would be wonderful. But at the present moment in time we're still off a notch or two.

What does the rest of the world look like? If you try doing Europe, it gets really messy very quickly, and that's good. That shows lots of interconnectivity. If you try doing North America, we still haven't got the code to actually work all the way through the amount of data there, but we think it's going to be one big blob of America connected to one big blob of Canada and everything else being minor.

Look at the Middle East, Latin America, Africa.

These start to make sense as you see them, whether you have mature or growing interconnect markets.

The colouring here is slightly different. What we did was we added when there's a v4 and a v6 link, we added this nasty horrible magenta colour as opposed to doing two different graphs. All in all, for Latin American, Brazil comes out high on the list and in Africa, you see South Africa being pretty well connected.

The last point to mention is this is BGP data. So it does not map perfectly to physical interconnects.

For example, you may know that there's a peering that goes on between someone in one country and someone in another country, but a third country is involved in the peering and this is measuring BGP, not physical interconnect.

Here is the summary, well within time. You can do this. You can get results. You can get results that we hope over time show more and more complicated diagrams where more and more interconnects occur. And you can question the results, because it's BGP. It's not a physical interconnect. You need to overlap a large amount of trace routes to make this work.

Thank you.

Philip Smith: Thanks, Martin. 25 seconds for questions.

No? If not, thank you.

APPLAUSE Philip Smith: Andy, are you all set? Andy Linton: I, along with at least two other people here, are people who are trusted community representatives who sign the DNS keys, help with the key process for signing the DNSSEC at the root. Dmitry is over here and he's going to put his hand up and wave, and Gaurab is also one. If there's anybody else here from the east coast, I don't recognise them, but anyway.

So, the last time I did this was on 26 July this year. What I want to talk about is the process for signing the DNSSEC root zone. I'm not going to talk about how DNSSEC works at the technical level. That's not what I want to talk about and that's probably a relief all around, because we have already had some of that this week.

What I really want to do is talk about the detailed business process, how the process works, just so people get some idea of what actually goes on in that secret bunker and so on.

These slides were originally done for use in New Zealand and our system in New Zealand for signing .nz isn't the same as this, but it's similar and that's okay, that's not a problem, that it's different process, but the fact that there is a process is the important bit.

There are a couple of definitions in the here. The idea of the root of the DNS hierarchy, the 13 name servers, the key signing key and also the idea of the ZSK, the zoom signing key. When I first looked for KSK on Google, I came up with Kommando Spezialkrafte, which is the German equivalent of the SAS or Navy Seals, that sort of thing. It's not that.

Chain of trust, the idea of validating each component of the hardware and software right down through the tree.

So here is an example of a chain of trust in this sort of sphere. We have the root zone at the top. The one underneath is the UK, underneath that we have org.uk and underneath that nominate.uk. So each of those entities validates and vouches for the one underneath.

This slide is taken from a tool called DNSVIS^nme , which you can use to actually visualize what's going on. And the chain of trust at the root, which is really the core of the thing here, there's a key signing key which is in the top blob at the top here, a number 19036 and that was generated about just over two years ago, when the root was first signed.

Underneath that is a zone signing key which gets generated using the key signing key. That then signs the SOA for the root.

Here is an example of what goes on for New Zealand.

Again, using the DNSVIS tool, the top part of the root, we generate our keys in New Zealand and we get a DS record put into the root zone which is then validated by the key that's above it.

My 26 July -- anyway, I left New Zealand, I had a day trip to Los Angeles. I left New Zealand on Wednesday evening, I arrived on Wednesday afternoon and took part in the ceremony at 10.00 on Thursday morning, we got the process all finished and I got on the plane at 9 o'clock at night and flew home to New Zealand again and was back home for breakfast on Saturday morning.

I like to thank the New Zealand Domain Name Commission for providing a business class fare for that, because if I had gone economy, I would have been a mess.

My trip to America didn't actually involve very much. Here is a map from Google Maps. Along the top you can see the runways at LAX and underneath you can see a little pink dot and that's where the facility is.

So it's literally sort of just straight under the runways and turn left.

Once you get onto the runways at LAX -- and most of you know that area, if you have been there -- industrial sort of area with lots of buildings and warehouses and so on. Equinix have a Datacentre there and this stuff is housed in there.

There's quite a lot of process around this. To get into the building, there's all these rules, two types of government ID, your bags scanned, you can't take cell phones and radios and all that sort of thing. And I do like the last couple of points in here. Health and safety regulations say that open-toed shoes are not allowed on the premises, which is sort of a bit contradictory for asking a bunch of computer people in California to turn up and not have open-toed shoes -- well, it feels that way anyway.

You're also not allowed to take guns, explosives, pepper sprays into the premises. I'm not quite sure what you would be doing with them in there, but there you go.

The ceremony was on 26 July. There is a script which you can go and download and have a look at. It's 22 pages long. It's 99 steps and it includes things like, go into the room, check the clock, set the clocks and so on.

The process takes about three hours. There's ICANN staff and external witnesses there. The thing is streamed on-line, so you can actually watch it. We had the grand total of about 20 people watching this. I'm not quite sure who they are and why they want to watch it, but Martin Levy was one of them.

Okay. So we have seven crypto officers at each location. Five of them were present. We need a minimum of three. There's a VeriSign representative there to convey the material we generate back to prime the master root server.

What are we actually doing there? If you look at the second key down here, we're actually trying to generate the ZSKs here and those get rotated on a regular basis, so we go and generate keys for a three month period and then on the east coast they do a similar thing and generate keys for a three-month period.

This is the crib sheet from the first ceremony, and Gaurab's signature is on here. I can't pick it out, but there's a number of other people there. I just throw it in for sort of curiosity value.

What we end up doing is producing the crypto material. I'm not going to go into all that detail, but you can see if you look back through the slides, you'll see this number here 50398 is the key -- the ZSK that's in the diagram.

So what we do is we generate -- you can see these details here. There's an inception date and expiration date. The ZSK tags and the KSK tag, those, if you can see the dates in there, were for the period from July through to October. So those are the keys that currently are in place. Then if you look at the bottom here, you can see a 24220 on the last line. That will be the key that is in use in the next period. These rotate in so that we can be sure this no one has actually breached those.

There's a secret chamber. I have a better diagram of this, but when I put the slides together, this was it.

Those of you who are fans or old enough to remember the early episodes of 'Get Smart', you show your passport, you get in, you go through a set of doors, you go down a corridor, you go through another set of doors and you eventually end up in this section down in the bottom right-hand corner, where somebody has to put their hand on one of those scanners and then we sign books and so on.

We go into this room and there are some safes in the cage at the top right. The whole process is detailed in the script that we have. It includes things like "Don't forget to take a flash light in with you, because it's dark in there." So it's real, real detailed.

Nearly there. What I really want to iterate here is not what the crypto process is, but that the process that sits around it. It's a whole idea of it is that it's a robust process. It's publicly visible. There are people there who are there to witness on your behalf. Collusion is probably possible, but it seems highly unlikely. We could all get together and come up with some bizarre scheme to pervert this, but I don't think it's likely, because that's probably as good as we can do.

As far as I can see, the keys are all generated securely and that was just a point, really, about the New Zealand staff. You know. Ours is nearly complete and over to users and so on. Having that process is something that if you haven't already done this, this is one of the things you have to work out for your site.

There are a lot of material out there that will help you do that. 50 seconds for questions.

Philip Smith: No questions. All right, thank you very much, Andy.

APPLAUSE Philip Smith: I don't see.Shin Shirahata in the audience.

He's here. Are your slides available? Great.

Shin Shirahata: Good afternoon, everyone. This is Shin Shirahata from ... University. Today I would like to share about the cooperation between route increases and IPv4 address transfer.

There was a similar concern on the IP address transfer proposal. One of them was route aggregation caused by address transfer. According to prop-50, there is one concern about the route de-aggregation, the role of strong aggregation capability in the address space, with the consequence load being imposed on the routing system.

So I analyse the result of the address transfer proposal. Here is a number of IPv4 address transfers for recent years.

According to this data, since year 2011, third quarter, we see about 40 or 50 transfers per quarter.

But it seems to be number of the transfers is increasing in these days.

I analyse the full routing table on the transferred month. I analyse the number of prefix on the transferred block. Orange bar indicate the number of prefix on IP address -- orange bar indicates the address block which is being transferred by IP address transfer and the brown bar indicates the number of the route advertisement on transferred address block.

I analyse the full routing table on the Internet for transfer on transfer date and 12 months before, nine months before, six months before, three months before, one month before the transfers.

Also, I check one month after the transfer, three months after, six months after, nine months after and 12 months after the transfer.

The blue line indicates the ratio of the route advertisement on transfer block. So I could see the number of increase is increase the ratio of the route advertising.

At the same time, there is a similar concern on route defragmentation caused by the IPv4 address transfer policies.

I checked the full route one year before the address transfer. If the advertised address block is shorter than transfer size, I see that address block has been split by the address transfer.

According to that criteria, I found that about 10 blocks have been separated, split by the IP address transfer and about 25 or 30 prefixes were doing punching hole on this kind of subnet.

I would like to proceed to conclusion.

The number of the transferred IP address block will be increased if the current trends continue. We observed hundred of route increase by IPv4 address transfers.

IPv4 address transfer isn't a major factor of route increase, of full route increases, in past two or three years.

So I conclude that route increases by IPv4 address is not major factor of the route increases on full routing table at this moment, but we need to watch carefully about route increases caused by IP transfer in near future. That's all. Thank you.

Philip Smith: Thank you.

Any questions? No questions. People want to go to the social event. Thank you very much.

APPLAUSE Philip Smith: Next up we have number 6, Gaurab.

Gaurab Raj Upadhaya: Good afternoon, everyone. I have a few slides here. I'm going to talk about root server reachability in the APAC region.

A bit of background. A couple of months ago, in April, we're looking at how many root servers are installed in APAC and where they should be installed and so on and so forth, and I started thinking is it really being useful or not really being useful? Are the servers there actually being used? So far, most of the root servers that are installed in APAC are at major exchange points or inside some carriers. But is it working as intended? What I did was I looked at countries where there was a local instance of unicast version of the root server and looked at the major carrier in that country, the incumbent or the biggest eyeball network and did some random trace routes.

This is the chart and that is probably my entire presentation. It's probably you can see that from the back, I don't know, you can download this. You know, I produce this, I looked at the FIJL and K root server, because they are the most widely end casted ones and I looked at different countries.

You can see there there are some carriers which I have highlighted in yellow, starts with Singtel, TMNET, PLTD, skbb,Optus and Telecom New Zealand.

The idea there was to go in the network and do a trace root to each of these I realised there are at least four or five different root servers in Singapore, but Singtel was not reaching any one of them. That case is resolved. I sent this to Singtel and they have solved it. They are now connecting with the root server in Singapore. So if I do this again, they probably won't be in the yellow chart any more.

But some places there were some interesting things like skbb kind of stood out. In Japan, KDDI kind of stood out by not having all green for all the different root servers, but it looked pretty good for OCN and SoftBank. Optus probably fared -- the worst faring is probably Telecom New Zealand, which doesn't see any root servers inside the country, despite there being four or five or them in the country.

The next one was PLDT, with whom I had a chat last week. It might get resolved very soon.

So I think the feedback here from this thing was maybe when root operators are looking at installing root servers or when someone is looking at supporting that, going to an exchange point might not be the right thing any more. There are enough root servers at enough exchange points and if you are really serious about getting that access to the carriers, you might be looking at putting servers inside the carriers.

Questions, please, and I see someone standing up.

First question.

I did send this to Peter beforehand, so he's seen this before. So he knows what this is all about.

Peter Lasher: The only comment I would like to make, we do have a root server in India, which is currently down at the moment, we're working with NIXI to bring that up back up as soon as possible.

But for any of you, I said this also in the F root presentation, if any of you think that you should be getting a closer root server, please come to me and I'll see what I can do. It may just be an issue with a local node. We're not reaching even we should be reaching.

I'm actually working on the Phnom Penh node right now, trying to get to more providers in Cambodia with MekongNet.

So if you think that you're going to the States or some place like that or Japan, when you should be going in-country, please let us know.

Gaurab Raj Upadhaya: Something with this observation, you can see that the K root server actually serves quite well, very well in fact, which probably reflects the fact that most of Asia probably connects well to Japan than to each other. I mean, K root server is just two or three instances in all of Asia and they seem to be doing the right intended use, whereas the more root servers you have in more places, it seems like there needs to be a lot more attention paid to how the routeing is done. You can go through this, look at this and figure it out.

If you have time, sign the numbers and do some calculus on it and you will see what I meant. I removed that part from there. I do have some weights assigned and I have done some numbers. F root is still pretty good, seems like that.

Anyone here from VeriSign? I would like to talk to them. J root seems to be for homing, really bad in terms of taking queries from India to Sofia and to Sydney, kind of way too off.

It's quite natural to see queries going to the US, because routing, that's where the original locations are, but taking query from India to Sofia and to Sydney is a bit too much wacky. Thank you very much.

Any more questions? I see Martin waving and winking.

Philip Smith: Thank you.

APPLAUSE Philip Smith: Last one, No. 3, Paul.

Paul Wilson: I'm here to present something which I have taken around quite a few meetings over the last year or so and also presented to an ISOC event in Phnom Penh this week. It's something I hadn't brought to the APNIC community, mainly because it's not really a technical presentation, it's more an attempt to help to answer a number of questions about IPv6 and the IPv6 transition through a particular analogy.

I would be using something called Presi, which is a really nice funky animated presentation thing that kind of makes it look newer than it does on PDF, but we have just got PDF in this case, so it's more or less the same message.

The thing is this is about the future of the Internet, the transition from the old world to the new world and the analogy that I have drawn and I find it fairly useful, is to see the old world as the transportation system that we all know and love, the global transportation system which is fuelled by oil.

That system is pretty huge. It's pretty global, in fact. When I first did this at a global IP V summit, I kind of addressed the meeting as a summit of transportation energy people, as people who are involved with extracting oil or transporting it or refining it or selling it or manufacturing the cars that use it or maintaining the cars or driving them or fuelling them.

If you think about the size of that community and the number of different people involved with it, then you sort of understand that when oil runs out, it's a pretty big deal. It affects everyone. It affects every one involved in a different way.

The funny thing about oil is that we have known for a long time that it's going to run out. This is a very familiar story. It's going to run out at some point.

We don't know when. But the thing is we know kind of what's going to happen afterwards. We know what we need to do afterwards and that's to move to transition to a new form of energy for our transportation system and we even know kind of what that will look like. It's electric power in various forms and that's what the world is going to look like.

We're even in fact in the middle of that transition now, because you can buy hybrid vehicles that run in some way on gasoline and electricity at the same time.

You can buy these vehicles. They are being manufactured and people are learning to maintain them and the interesting thing here is that the vehicle that runs on either fuel -- the two vehicles that run on the different fuel run exactly the same and perform the same and, depending on who you are, you might as well see them as exactly the same thing. You could be a driver who needs to know a little bit about the fact that you're using an electric vehicle instead of a fuel vehicle, a gasoline vehicle, because you need to get your power from a different place.

Of course, the mechanics need to know the difference of the internals and the manufacturers need to know the difference very much, but the kid in the back doesn't need to know. That kind of is a nice answer, I find, for this issue of compatibility between the old generation and the new. It's pretty obvious here that I'm talking about the IPv4 to IPv6 transition.

V4 and v6 aren't compatible. Electricity and gasoline are not compatible either. You can't put one in a vehicle built by another, but they do run on the same roads and they perform the same function. They drive the same way. You know, there's compatibility and there's not.

The point of this is we kind of know that before us, somewhere down the track, is this much more efficient Internet. It's kind of a clean, lean, green future, which we're all heading for. So we know where we're going.

Part of this presentation is to inform these people, who I have imagined are transportation energy people, to inform them in fact that we have just extracted the last drops of oil out of the ground, so oil has actually run out now, in terms of its source supply. There are regional stocks around the world that are available and will last for a little while longer. Unfortunately, in the Asia Pacific, we have kind of run out of the Asia Pacific stock, so if you really thought some time ago that this was coming over the horizon and it was a future thing, then the thing is in this region, it's happened now. You have really got to work out what your business is plan is.

I'm always asked, what do I have to do about IPv6? The question has to be reflected back: what is your relationship with IPv6, what's your reliance on the Internet? Because the answer to what you have to do about IPv6 depends completely, like if you're a kid in the back seat, you don't have to do anything. If you're a mechanic, an engineer, you have to do something. If you're a manufacturer or an energy distributor, in the gasoline analogy, then you'll have to do something different.

If you're one of those service stations or gas stations that have been spending their time turning themselves into mini markets and music shops and all sorts of other things, you may have been too distracted from your core mission of dealing with gasoline to even have thought about electricity yet. You may be caught out. So it's a case, I think, in either case of sticking to your mission.

Actually, we are in the transition in both cases, in the analogy the transition from gasoline to electricity is under way in transportation, it's under way on the Internet from v4 to v6, where are we? So a series of slides, I think we all know that IPv6 addresses are being allocated rapidly and readily and very easily.

They are being routed all over the place. There is a fantastic exponential growth showing that part of the transition is under way. V6 in use, the actual use of this new source of power, is still rather questionable.

I do a little promo here for the fact that APNIC Labs are looking at this very regularly and taking half a million measurements a day or so to just back up the data we have.

The question then for the audience, having heard and understood this, is where do you want to go? Do you want to go here where you are sort of sticking to and clinging onto this old world of old technology? The analogy can go a bit further here, because we're doing all sorts of funny things these days to try and get more life out of our cars. We are putting compressed natural gas into them, we're fracturing aquifers and dragging gas out of the ground so that we can keep that up, and we're trashing the environment at the same time.

Think not CNG for compressed natural gas but CGN for carrier grade NATs. You can spend a lot of time and you can spend a lot of money just trying to make this thing last longer and longer and avoid the inevitable.

The alternative is to really set your sights on the new future and to -- I'm not saying you don't have to decide when you to do it. You actually do have to decide. This is not so much a religious campaign, but simply a business decision. You set your sights on where you need to be and you work out what you need to do to get there.

In this question, there's only one answer. The answer is IPv6. People will say, "When? Can't I wait, please?" When I started on this presentation a year ago, I said, "Yeah, well, you should do it now, but you can wait a little while, but not too long." These days you can't wait any more. In this region, you do need to make the decisions, start making the real plans and taking action.

Why do we have to do it? What's the killer app? The killer app for IPv6 is already here. It's the Internet. We should all know that by now. When you think about the Internet, these days you need to think of IPv6. Whatever Internet product or service you're using, whether you're thinking about software or hardware or upstream connectivity or peers or consultants or the staff that help you to connect yourself and be a part of the Internet, even of those service providers in all their different forms needs to be able to answer your question about IPv6.

So that's the sort of motivating line for the more nontechnical audience who really wants to work out where IPv6 is in the scheme of things when they hardly in many cases understand even the Internet.

Of course, I don't need to say any of this stuff to you all, because you all know exactly what you need to do and no doubt you're thinking very hard and making all your plans and it's all under way.

I just thought I would like to share that with you.

If you find that analogy useful, then it may be useful in your own work in convincing your own colleagues and so on.

Thank you for your time.

Thanks.

Philip Smith: Thanks very much, Paul.

APPLAUSE Philip Smith: 15 seconds for questions.

None at all.

So that brings us to the end of Lightning Talks.

Thank you to the eight presenters who volunteered their presentations, their short presentations, to end this Thursday session at APNIC 34.

Social events, social dinner tonight. Transport starts at 5.30, so you have some time to go get changed, whatever, and meet the transport at the front of the hotel.

Tomorrow, we have the APNIC Member Meeting starting at 9 o'clock, so if you're staying on for that, we'll look forward to seeing you tomorrow. Otherwise, enjoy your evening.

Thank you all very much.