These are unedited transcripts and may contain errors.
Plenary Session: 4 May 2011 at 9 a.m..CHAIR: Good morning everyone. I am Nick Hyrka, the communications manager at the RIPE NCC, and this is day 3 of RIPE 62. And I am going to open up this session that will be about the IRR, NRO and ICANN reports. This is also Herdenkingsdag in Holland, this is Memorial day. We'll have a visit of the queen this evening, at least outside, not here. But you will notice there will be some restrictions as far as access coming and going later tonight into the front doors of the hotel.
Without further ado, let's just get the show started, so, starting with the RIR updates. I've got Dr. Viv Padayatchy from AfriNIC, and if you'd like to come up.
VIV PADAYATCHY: Thank you very much, Nick. First of all, my name is Viv Padayatchy. I am the Chair of AfriNIC. I am making this presentation in the place of Hisham Ibrahim, our communications manager who couldn't come. It also gave me a chance to attend my first RIPE meeting and I must say, I am very happy to be here, and it's been an interesting learning experience for me and I just wish I attended the meeting at the beginning of my mandate rather than towords to the end.
So, just a quick update in what's happening with AfriNIC. We have reached 21 staff now since our beginning where we started with two people. Interesting point about this is 40% of our staff just joined last year, 2010. We have reached an operational budget of 2.8 million dollars, we started with $100,000 back in 2005, so, it's been a very good progression. The RIR is able to cover its expenses and gradually start building up some reserves. We have allocated 8.3 million IP addresses in our region, and we have made 54 new IPv6 allocation in 2010. We had a very good membership growth last year, where we enrolled 133 new members sorry, these are new members who enrolled between last year and now. In 2010, we also had the two policy meetings and three new policies were adopted reached consensus in our region, so, we handle more than 200 travels to participating various events around the world. So, we I think it's fair to say that now AfriNIC is a fully participating member of the RIR community.
So, these are three policies and others that reached consensus in our region, the others are still in the phase of discussion.
The numbers are going up, which is a very healthy sign for the RIR, both in terms of IP address being issued, IPv6 allocation and the membership growth.
In terms of the top countries with IPv6 allocation, it's not a surprise, we have got the usual suspects, South Africa, Egypt, Kenya, but also some smaller countries like Marrakech, Rowanda who started getting IPv6 allocation, and we we do more and more IPv6 training work shops in the region, we expect this to grow and diversify in terms of countries.
These are our executive staff. Bearing in mind as I said, 40% of them just joined us last year. This is our legal adviser is here with us today. I don't know where he is in this room. And we have moved into our new office last year, it's a brand new office. You are all welcome, for those who is passing by in our region in Mauritius, please do come and visit and we have got a very nice training facility now.
So, our next meeting is going to be held in Dara Es Salam, 4 to 10 of June and I hope a lot of you in the RIPE region will be able to come. Thank you very much. That's the end of my update. Any questions?
(Applause)
CHAIR: Thank you. Next up is Leslie Nobile from ARIN, she is the director of registration services, so Leslie, come on up.
LESLIE NOBILE: Good morning everyone. As you can see I am not John Curran, but he had to leave, so I'll do this for him.
I have a really quick update for ARIN. So, 2011 focus, like all the the other RIRs we are focusing on IPv4 depletion and IPv6 uptake, we are developing, adopting and improving processes and procedures because everything has changed literally. We are working hard to keep pace with the increased v6 requests we are seeing. We are getting more complex v4 requests at the end, and more complex transfer requests as well. And we are continuing our IPv6 out reach into our region.
Implementing lots of new policies and services. Policies are crazy at ARIN at the moment. Our PPML list is off the charts. It's a full time job reading it and we, in fact, got eight new policy proposals in one day this week. So, very busy with that. We continue our development and integration of our web based system, we are going from mail from and templates into the, you know, modern times and using a web based system for all of our requests. We call it ARIN online. We are work on DNSSEC and RBKI deployment. We have gotten very far in DNSSEC; in fact, we have just completed it, our implementation and a bit behind on RBKI as John mentioned previously and, of course, like all the other RIRs, we continue our participation in the Internet governance form.
I'll show you the number of requests we are seeing in v4 and in v6. The reasons in v4 have really trended up. The red dot is the IANA runout date and really when people start being aware right around December, we started seeing an increase in v4 requests. In fact, my staff was working the week of the IANA depletion until 10 and 11 at night to keep pace with the number of requests coming in. I didn't show the v4 space we are issuing because that trend line is actually down, surprisingly enough, but there is a new policy in the ARIN region that only allows us to issue a three month supply to ISPs, so we are issuing much smaller amount of space at this time and issuing less. If you look at our stats recently, it's really downward.
V6 requests: Those have gone up quite a bit. That is bit deceptive this slide, because that red, that trend line down shows the first three months of the year, but in 2010 we issued over 700 I mean we received over 700 v6 requests and in 2011 already we have gotten 500, that line will go straight up. As far as v6 allocations, I did put this slide up there, again we made about 400 v6 allocation to say ISPs last year and already in the first 3 months of this year, we have issued over a little over 200 IPv6 allocations, the little numbers that you probably can't see are the to the at number of 32s that we have issued.
So I told you what we are sort of giving out from the ARIN region. This is what we are actually taking back in. So I went back and I looked at the past five years and the return space we are getting surprisingly enough, is pretty significant. That's voluntarily returned by a registrant, we have gotten almost 456 /16 equivalents back to ARIN in the last five years. In fact a large it's actually trended up. If I looked at the past 24 months versus the past twelve months, we receive more space back voluntarily in the past twelve months than we did the previous year. People are still good out there. We have got 15 registration fees we have revoked 122.20 /16 equivalents, and almost 5,0002 two byte ASNS, so we have quite a good bit of supply going on. In our region they have just not picked up, so we are really heavily relying on our supply.
We have reclaimed 7.06 /16 equivalents. We have reclaimed space due to fraud, hijacking, miss appropriation, business disillusion, when went find somebody has abandoned space completely after we have done thorough research, we will reclaim space and we have gotten back 15 ASNs. Unlike some of the other RIRs we take this space back, we hold it for six to twelve months, we let it clear filters, we check blacklists etc., before we re issue, but we do recycle space that we take back continually.
We have got a lot of policies. I am not going to get into them. You can read about them if you are really interested, but we have implemented quite a few policies recently. We have a waiting list for unmet resources. We have a new IPv6 subsequent allocation policy and we have a rework of the IPv6 assignment criteria. The IPv6 policies essentially make it easier to get IPv6 address space from ARIN.
We have got a new one more a standardizeing IP reassignment registration requirements. We will implement that in the next week or so. We have got a lot of draft policy discussions. Again I probably won't go into them but there is a globally co ordinated transfer policy, and our Advisory Council has postponed a decision but they will be working on the text, I don't know if that's actually correct right there. Protecting number of resources, that one was a bond on the. That directed ARIN to recover abandoned fraudently obtained resources. That's something we do anyway. They wanted us to do it proactively but that's a whole lot of work, we are not sure we can maintain that with the resources we have on our staff. Better IPv6 allocations for ISPs. That one was very popular. That makes it easier to get v6 space nibble boundaries. Share transition space for IPv4 address extension, that's kind of like setting up RFC 1918 space. And reserving a /10, that's in last call. Returned IPv4 address space, this instructs Karen to quickly recycle address space in the ARIN region. And that's on last call with revisions.
So our public phasing developments efforts. We are work with ARIN online. And we just had a major release March and that was like our biggest push yet. We are winding down and going back to fix bugs and make enhancements etc. And do last minute stuff with billing. DNSSEC basically completed. We have now interface that is allow insertion of the delegation signer records. It signs all the /8s that it administers. RBKI, we are the laggards, and we plan on rolling out the production service in the summer of 2011.
And outreach events, like RIRs we are all over the place talking about IPv6. I am not going to go through that. And upcoming meetings: We have two meetings in the the next one is in Philadelphia in October and after that we have Vancouver in the spring. So everyone is welcome. Does anyone have any questions? Thanks for your time.
(Applause)
CHAIR: Thank you, Leslie. You are a true professional. I screwed up the order of presentations this morning. Anyway, next up is Geoff Huston, he is the chief scientist at APNIC, welcome.
GEOFF HUSTON: Good morning everyone. My name is not Paul Wilson and I am not the CEO of APNIC, but I do work there as a minion slaving away in the dungeon and I am here to offer you the APNIC updates. Many slides, a small amount of time. We'll see if we can make this look like a movie. So I am going to cover all of these things, aren't they interesting. We gave away lots of addresses because we are professionals and that's what we do. We gave away more last year than we had ever done before. And we actually gave away more v6, but interestingly it was the v4 that everyone is always interested about. We gave away so much v4 that we actually ran out. Oops.
I was at a presentation a few weeks ago where the claim was made that the Asia Pacific area ran out carefully and responsibly and no one panicked. Bull shit. Let that be a warning to you. Your turn is coming.
We had lots of v6 given out. We have done a kick start programme where if you have v4, one click will actually get you v6 and that's been popular. Probably because there is no more v4. And on the other side of this, we have been doing a lot of work to look at what crap is inside addresses. We have been suspending a fair deal of lime with the last /8s to look at the amount of incoming traffic and naughtiness that's generally out there and spending a lot of time looking at it. Interestingly enough, conflicker is the most verment thing out there. Responsible for about 3 gigabits of traffic worldwide. Anyone have any addresses in the low half of a /8? So, you know, anything .0, ,1 up to ,128? Hands up? Come on, some of you have do. Losers. One of the interesting things about some of this stuff is that Conficker, due to some bug, actually inhabits only half of the address space. All the low numbers. So, if you are in the low number of any /8 you get actually ten times for Conficker traffic than anything else. We have had a lot of fun looking at this stuff. Generally what we have been trying to do is to make sure that when customers do get addresses they don't get handed a few hundreds of kilobits or even megabits of unwanted traffic. That's been a useful service to have done.
Lots of focus, still wanting addresses, membership is gone up. Lots of help desks and that kind of thing. We have been doing bits and pieces to actually update a Whois and this year, of course, we have been spending a lot of time doing DNSSEC support particularly with the DS records on the reverse in address space.
We have policy meetings twice a year and obviously you can't do anything other than talk policy. So folk talk lots of policies. These are the policies we have implement this had year, I won't go through them in detail. These are even more policies that reached consensus at APNIC 31. And we even had consensus on these policies as well.
Some of the policies didn't reach consensus. And in particular, some of the ones about global policy for v4 allocations, and some of these issues around address transfers. Don't forget now that we have exhausted in IPv4, APNIC's prevailing policy now is that transfers can happen within APNIC without any constraint regarding demonstrated need. Two parties can basically transfer addresses between them without any imposed constraint from APNIC policies. We did consider at this meeting actually adding a demonstrated requirement needs based into the transfers at the last APNIC policy meeting. And didn't really manage to find any clear consensus to do that, so that has been in the nice way that we do this, referred back to the mailing list for further discussion.
We do reverse in addra, we set up DNSSEC as I said. We now have three co lo facilities so that when disaster strikes, we'll be fine. More about that later. As well as that, we have been doing lots of R&D down in the dungeon of the research labs, we have also had the RBKI up and running. There was a common target to get things running by the start of this year. APNIC actually had its engine running since September 2009. So, we think we actually met that target with sometime to spare.
Also, for World IPv6 Day, we have been doing some work in labs at APNIC.net. If you want to find out, without doing the hard work of putting your content on dual stack, but if you simply want to understand how much folk could get to you using dual stack, if you are already using Google Analytics, this code here at labs one, a little add on to Analytics, will tell you what would happen hypothetically if to you run a dual stack service, we are offering that as part of the World IPv6 Day tools.
We are going to lots of meetings saying that IPv6 is a very good thing, because that's our job. As well as that, a bit like RIPE, we have been doing a member survey of what they like. The good news is that most of our members love us and that's a list of how much they love us. Aren't they wonderful, this is more interesting. This is the thing that they are saying, don't do this. I like the top one. There is suggestions of a Government advisory committee similar to ICANN's down at the APNIC level. Not very popular with the members, which is interesting. And also, should governments be more involved in APNIC? Wasn't actually seen as being popular in the survey. The other one, considering that we went through about five or six new policies at APNIC 31, the membership doesn't really like that and this idea that we need a policy development process that allows policies to flip more rapidly was not seen as a desirable thing by the membership. Interesting. Also in terms resourcing. Everyone is keen on v6. We seem to have run out of v4, did I tell you? Yes, it's now v6 time. As well as that, we have moved office. So, this is a map of Brisbane. There is meant to be some graphics here. We have done a very big move. We used to be located there, we are now located here. Fantastically big move. We have gone from one glass building on the left to another glass building on the right. This one is on a hill. That's one is on a hill. Spot the difference. That's day and that's night. Fortuitously, though, we did have a minor problem in Brisbane, those brown bits, that's water. That's not a swimming pool. That's a football field, and that's the old office with water all around it. This is the new office not with water all around it, but this is outside. There was a lot of water, way too much water. We sent everyone home but interestingly as we did have all of our stuff in co lo, we were actually able to keep the business running even though F you you will, everything had died in terms of power in the new office. So, a minor bit of excitement.
Next meeting of course we are off to Korea, the honeymoon capital of South Korea, if you have any plans in that direction and wish to spend your honeymoon with us, this is where we'll be and you are welcome to be there too. Thank you very much.
(Applause)
CHAIR: I assume no one had any questions.
AUDIENCE SPEAKER: Will there be actually a chance to ask questions from all the representatives from the other RIRs at some point?
CHAIR: You mean the presenters this morning? Absolutely.
AUDIENCE SPEAKER: I can pose the question already. Now that APNIC has run out of IPv4 or is on its last legs, there can be you can anticipate the creation of patient subsidiaries in Africa, Europe or southern America just for the purpose of gaining address space from those regions, and how is this issue viewed by each RIR?
GEOFF HUSTON: We are neutral.
LESLIE NOBILE: In the ARIN region, we have a requirement that an organisation has to have a legal presence in the ARIN region, so, if they are incorporated or they have some kind of business, they are authoriseed to do business in the region, that's one of our requirements. The other is that they have to be using the space in our region and routing the space. The route origination has to be in our region. These are the things err we are checking before we will issue space.
AUDIENCE SPEAKER: How do you verify that they use the address space in your region?
LESLIE NOBILE: Well, we essentially trust them, but then we do our verification it's trust but verified, right. It's a good concept, so we will just we make sure that they are authorised, we check their legal documentation, they tell us they are going to use it and then we'll go back and look.
VIV PADAYATCHY: Our requirements are similar to ARIN. We do require that they have a legal entity registered in an African country.
RANDY BUSH: I don't give a dam. This is a global Internet. These regional cartels are an artificial construct we set up so that things worked in the same time zone and stuff like that. This is the global Internet, the IPv4 space is global IPv4 space and I think this is much ado about nothing.
AUDIENCE SPEAKER: For us it's similar to what Leslie has said with the only difference that the organisation does not have to be registered within the RIPE region, so it can be anywhere as long as the IP addresses are routed through the RIPE region.
CHAIR: Thank you. Moving on to NRO reports, we have got Axel heading this one.
AXEL PAWLIK: Good morning, so, the NRO, I am sure most of you do remember what the NRO is, it's basically the five RIRs working together, we at some point decided it would be good if we had a vehicle where we could act together and coordinate amongst other selves and present one common interface to the outside world. The NRO is fairly old by now. We also have established the, re established at the time as part of the organisation of the ICANN framework and that was 2004 and it went fairly well. So, good news more or less.
We have a couple of office holders who have decided not to give this presentation by running away and not coming here. That's also the reason why we don't have a presentation were LACNIC this time. The officers know the functions within the NRO Executive Council, they rotate and I was the Chairman last year, so I can relax and give presentations.
The coordination groups that we have is basically about engineering. Obviously the RIRs are working on similar things, and can benefit from some coordination there. Communication, the same thing and that's I think the heaviest work that we are doing together just talk with the same voice and issue statements and papers and go to conferences and present ourselves as the Member Resource Organisation. Also, we have a meeting of the regular committee of the registration services managers. Obviously we have similar problems, similar issues within RIRs, different regions. ICANN and the ASO, like I said, we are running the address support organisation for ICANN and normally we pay for all this ourselves. In addition to that, this is a contribution to the ICANN budget that we do I think since the year 2000 actually, and there is on a yearly basis a revaluation of how much we how we distribute that cost among the RIRs and there it is.
We have renewed and we basically annually renew our agreement with ICANN that we do this. They are doing some good work for us. Obviously IANA is allocating, or used to allocate addresses to us, they don't do that that often any more, but that's okay. We still like them.
So, that's the amount of money we give them.
We obviously go to all of the ICANN meetings in one form or the other. It's not all of the RIRs that are always present but there is a long list of the last couple of ICANN meetings and what we did there. We tried to go and talk to the Government advisory committee, governmental advisory committee, and we used to give them regular updates on the status of IPv4 and all the like. That hasn't happened for a couple of meetings now because they are very busy with other things within ICANN. I sort of expect them to turn around to us next time around and say what happened to IPv4? Shouldn't you have told us something, but we did before.
And there is the IGF, the first five rounds of that thing have happened and we, together with most of the folks within the Internet community think those IGFs are a great thing. It's a great big talk shop, lots of people come, lots of work shops in parallel and about three days or so, four days, those things run. We really like them. Mostly because it is just a talk shop and there are no decisions, there are no formal statements so far at least. Now, as I say the first five rounds of that thing have gone through, and it's supported by the united nations. It has, the UN have agreed to have another five meetings. Next one will be happening in Kenya, I believe this year, and there are some ideas about improvements to the IGF and it's slightly more interesting again currently on those issues like, there there be statements, won't there be statements and the like. The great opportunity that we have here is that we talk to a lot of people, especially from the governmental areas that we don't regularly see. Of course today we have a coordination workshop here and there are Government people and the Internet community talking to each other there, we meet people at the IGT, we meet people that we don't regularly see here, that's a good thing.
There is other international cooperation that we do, namely for quite a long time we are relatively active in the ITU area. I am happy to say there was recently a meeting of the IPv6 Working Group in Geneva a couple of couple of weeks ago which was the most positive ITU based meeting I went to in a long time, if ever. And we basically agreed, as the RIRs that we would very much like to, as we all do, train to some degree or other other, we would like to reach out to the development arm of the ITU and help them with some content. For instance we do the IPv6 road shows in the Middle East ourselves, the RIPE NCC, and that there is certainly some potential for good work that we can do together to benefit the Internet at large. OECD, also for a couple of years we are busy there, we are proud together with the rest of the I STAR community, all the Internet community organisations like ICANN, like the internet society, that we have been successful to establishing I TECH, the Internet technical advisory committee as a formal body with the the OECD.
Other ongoing activity: Resource certification is something the RIRs are busy with and there are a couple of implementations there and they are co ordinated through the engineering coordination group like I said earlier, we had a retreaty thing in my a.m.ey, you probably heard about that, about the IANA giving out the last /8s. Based around that, we had a small NRO workshop where we talked about things, what to do in the future and how to do this. And again, talking to our colleagues from the I STAR organisations.
We would work together, that's the outcome of the retreat, we would work together to a single Trust Anchor in some way or the other. A review of the communications group work plan. Again, we have a number of those retreats with the I STAR people coming up so we need to think a bit about what we want to talk to them about. IPv6 group coordination, it's the IPv6 group in the ITU, but that looks fairly good. Again, of course IGF is coming up again, we all need to go and talk about the good things we are doing and encourage others to work with us and the like.
What have we done? Lots of statements, and I won't go through the details. Basically they are the statements that we do occasionally, obviously around IPv6 and oh, we are running out of IPv4. Then the IANA contract is going to be renewed one way or the other, and we send a letter to ICANN. We send a statement to the US Government about that as well. What we would like to see.
That basically concludes this small update. I am still around for a couple of days here, so if you want to talk to me or any of my colleagues, let me know. Thank you.
(Applause)
CHAIR: Thank you, Axel, continuing with NRO updates, we have got NRO statistics, Andrea Cima from the RIPE NCC.
ANDREA CIMA: Good morning everyone. I am the registration services manager at the RIPE NCC and this is what we call the joint NRO stats. This presentation is put together by the five RIRs together and is updated on a quarterly basis. As you can see, this one is as of the 31 March, 2011.
Now, the focus point of this slide is the text in red, but this is old news, very old news by now. IANA reserved for allocation 0 /8s. What is the status of IPv4 address space. As you can see 35 /8s are not available, they are reserved for the technical community. Next to it we have 91 /8s which is marked as central registry, now, these /8s that have been issued before the creation of the RIR system and most of them are actually assigned and used in the ARIN region. Furthermore we have 130 /8s which have been divided among the RIRs. You can see that APNIC has received 35 of them, ARIN 36, the RIPE NCC 35, AfriNIC 5 and LACNIC 9. And, as Axel just previously mentioned, each of the RIRs has received a last /8 recently by the IANA.
Now, how much address space have the RIRs issued to their members over time? Now, we can see that there is, there is always been a growth trend over the years. I think two interesting points are the 2011, if we see, we can see that APNIC in the first quarter before entering the last /8 policy has issued more than five /8s, which is quite impressive. With regard to the other RIRs, we can see that in the first quarter, the amount of address space issued has followed to the usual trend, so we have not seen yet any huge big spikes there.
If we look at the total IPv4 address space issued, we can see the RIPE NCC has issued about 30 /8s. APNIC about 43, AfriNIC almost 2, LACNIC five and a half and ARIN slightly more than 27 /8s.
Now, moving on to AS number assignments. These are 2 and 4 byte. So all flavours of AS numbers in one slide. We can see that from '99 until 2004, ARIN had the lead and was the RIR assigning the highest number of AS numbers. From 2005, this role has been taken over by the RIPE NCC and we can see that this trend is still going on. Also, this year.
Now, one of the main reasons why the RIPE NCC assigns more AS numbers is also because we make a lot of provider independent assignments for organisations that want to be independent and an AS number is part of the being independent of course.
If we look at the total number of AS numbers assigned, we have a little news on this slide. We can see for the first time since we give this NRO stats update the RIPE NCC has issued in total more AS numbers than ARIN. So, the difference is not much, but it's a first time. For the rest we have AfriNIC with about 600, LACNIC slightly more than 2000 and APNIC about 6600 AS numbers.
We wanted to break the AS number assignments down and this is the 4 byte AS numbers. It's quite interesting to see that the RIPE NCC and LACNIC are are the RIRs that have assigned the highest number of 4 byte AS numbers. The reason also being that AS numbers are assigned in a different way in the different regions. All the RIRs have all the AS numbers in one single pool. However, while ARIN, APNIC and AfriNIC first issued 2 byte AS numbers, RIPE NCC and LACNIC issue a 4 byte AS number unless otherwise requested. So if an organisation comes and says I want a 2 byte AS number, they will get a 2 byte. If they do not show their preference we will give them a 4 byte AS number. We have a few slides about this in the address policy Working Group session some.
If we look at the total number of 4 byte AS numbers assigned, RIPE NCC has assigned slightly more than 1,000 of them, LACNIC slightly more than 3 hundred, ARIN 40, about 170 by APNIC and 24 by AfriNIC.
Finally, moving on to IPv6 address space. Now, how much has been allocated by the RIRs? On the top left, we can see the grey doughnut with all the IPv6 address space. Out of this, a /3 is being reserved for global Unicast. Out of the 512 /12s, the IANA has issued one /12 per RIR as you can see here. Plus with one /12 which contains miscellaneous blocks, including the /23s that were initially issued by the IANA to the RIRs.
If we look at the IPv6 allocations that the RIRs have made over time to their customers, we can see that there is a growth, tendency of course, especially in the last few years. The RIPE NCC is the LIR had allocates the largest number of IPv6 allocations. And as you can see in the first quarter this year, we have issued half, at least 50% of what we gave out in the whole of 2010. One interesting thing is that after the runout, the IANA runout, we have received in the two weeks following the exhaustion, three times the number of IPv6 allocations we would normally receive. After two weeks though, this trend was back to normal.
If we look at the total number on the left side, you can see how many allocations, IPv6 allocations each RIR has issued. About 3,000 by the RIPE NCC; ARIN 1,300. 1,200 by APNIC, 500 more or less by LACNIC and slightly more than 130 by AfriNIC. On the right hand side, you can see the actual address space that has been issued by the RIRs counted in /32, which is the main allocation size and you can see this this number is much higher than the actual number of allocations issued, meaning that RIRs often give out blocks of IPv6 address space which are much larger than the minimalcation size.
Now, moving on to IPv6 assignments, so we are talking our region provider independent assignments by the RIR to the end user. We can see that until 2007, the only RIRs at least according to the graph, that were issuing IPv6 assignments to end users, were ARIN and APNIC. It comes in again later in 2009, until that moment there was no policy for issuing IPv6 address to end users. Interesting to see also is that while IPv6 allocations, the RIPE NCC as I say is in the lead and issues the highest number of allocations, this is not the same thing for the IPv6 PI assignments.
The NRO site you can find these slides, the statistics, and you can find the web sites of each RIRs. Do you have any questions?
AUDIENCE SPEAKER: Leo Vegoda from ICANN. I have a question about whether you could add a new slide? Now that the IPv4 address space is pretty much almost fully allocated, it would be nice to go and see a slide with the proportion of entities that you have allocated IPv4 to that also have IPv6, so, out of that 100% of entities with IPv4, what proportion per RIR also have a block of IPv6 address space?
CHAIR: It sounds like a very good idea, we will discuss it with the other managers and yeah, thank you. Thank you very much.
(Applause)
CHAIR: Thank you. Next up we have the IANA update and giving that presentation will be Leo Vegoda from ICANN.
LEO VEGODA: Hello. I am going to talk about some DNSSEC stuff, RZM automation, that's Route Zone Management, the recent Notice of Inquiry about the IANA functions and the business excellence work that we have been doing for the last couple of years.
So, firstly, reverse zones in DNSSEC. We have been working quite closely with the RIRs and we have been working with them for a couple of years basically to make sure that we have a nice system for the RIRs to go and send updates to main servers and put DNSSEC information in and it's now been done, and it's been used. If you go and look in your e mail or look at the APNIC websites today, you'll go and see that APNIC has recently gone and submitted their DS records and that debenture come in by e mail, that was all done through this nice new system.
We have redelegated both the in addr.arpa and the ip6.arpa zones, we have got a set of named servers each. It was all done in line with RFC 5855, and ICANN and the RIRs are running these named servers and everything seems to be going okay. If you go to the DNS Working Group later on, then Dave Knight will give much more information than it that it seems to be going okay. But he'll give some actual operational details.
The in addr.arpa was carried out by ARIN since 1997 I think. That has now obviously moved to us. And thanks very much to ARIN for doing a great job. We actually published all the details of this transition on a little blog and you can go back and see the history of it, but it's now all moved and it's also DNSSEC signed. We did, we started with ip6.arpa, that seems to have been working nicely for a year or so, and now moving away from reverse DNS to forward DNS, we have been working also with other groups this time with veerey sign and NTIA to implement a nice system to help automate part of the process for Route Zone Management. For the user, generally top level domain operator, there would be a friendly web interface. The backend EPP and we have been working on it for quite sometime, it's currently in parallel testing. There is a formal 60 day parallel testing period that's in operation now. We have actually informally been in parallel testing for some months beforehand anyway. So, all going well on that front.
You may be aware that NTIA published a Notice of Inquiry on the IANA functions. They published that on the 25th, and comments were due by the end of March. The overwhelming majority of comments were quite nice, and you can go and grab them all from the NTIA web site if you want to have a look at them. We were very great. For comments submitted by the NRO.
Now, finally, with the business excellence work; as I think we may have mentioned before, we are doing this formal process where we document exactly what it is that we do in a big document and then we do a self assessment of what we are doing, working out where we are doing well and where where we need to make improvements. Out of that work, we then identify improvement projects, work on them, document, re assess and so on. We did our second self assessment in January earlier this year. There was decent improvements since last year. One of the major changes we have done is we now have a single consistent methodology for documenting our processes. We are going through a process of identifying key performance indicators based on that single consistent way of documenting processes, and that's obviously going to help us identify further improvements that we can make in the future so that we are consistently and continuously improving the level of service that we are providing.
It's a bit of a formal process. But the end result is, hopefully, quite positive for people who benefit from our services.
And that's it. And welcome I am happy to take questions now, or if people have any questions, I am here all week.
AUDIENCE SPEAKER: Shane Kerr from ISC. This is actually a question I guess to all of the NROs as well as ICANN. Now that we have signed reverse zones gone from the route, are there plans to sign the legacy address space that's currently managed in a shared fashion by the are RIRs?
LEO VEGODA: I have to ask the RIRs to answer that one. I don't know the answer myself.
AUDIENCE SPEAKER: Sorry for asking you, because I wasn't sure what the right time to ask a question to all of them was, so...
JIM REID: We have been having some discussions about getting ERX space signed for quite sometime now, and we have been actually asking the NCC to try and speed things along, and I understand now that the processes have been sorted out internally and it's now down to ARIN to sign the ERX space, and they are in control of those reverse zones. I believe now there is a mechanism in place where the other RIRs can submit the DS keys, or the DS material for the reverse zones to Karen for incorporating into signing. I don't know when ARIN is ready to push the start button on that but I believe it's about to happen soon if it's not already happened.
AUDIENCE SPEAKER: Leo, you mentioned the Route Zone Management system was in parallel running, does that mean it's actually available for ccTLDs to use during that period.
LEO VEGODA: Not yet no. The Route Zone Management web interface thing will be made available at the successful conclusion of the parallel testing. At the moment what happens is when a request comes in, it goes through the current manual process and then it's also put through that parallel process and when we have had the 60 days of parallel operations, during which time a certain number of different kinds of changes have to take place, then there will be an evaluation and assuming that it's successful, it would be made available and as I understand it, for those TLD operators that want, I think there will be some kind of system for providing credentials to use the system.
AUDIENCE SPEAKER: Rob Evans, just going back to the signing of reverse zones, one of our customers has done that 131 in addr.arpa is signed with other processes with ARIN now.
AUDIENCE SPEAKER: Just a quick, I am Leslie Nobile from ARIN. ARIN has signed all the /8s that it administers, so I would assume that includes all the legacy /8s as well.
CHAIR: Okay. That does it for the RIR, NRO and ICANN updates for this session. We are going to move on now to lightning talks. Heading that session, that part of the remaining time that we have is Joao Damas who is one of the Routing Working Group chairs.
JOAO DAMAS: As mentioned on Monday, we have the next half hour delegated to having three and then a bit of a lightning talks. The idea of these talks is that you can actually have slots of ten minutes and you can you should actually use the time during the meeting itself to come up with things that you want to talk about but not prepared a huge presentation about, and I just want to share with you. So, during the meeting, we have collected the three and a bit talks that we are going to go through now, and the first one of those is Eric Kline.
ERIC KLINE: I am Eric Kline from Google. I want to talk about some DNS white listing access control kind of stuff. A general proposal, not something necessarily affiliated with Google.
I don't think I need to go over the fact that, you know, AAAAs are the only really control switch for turning traffic on and on. You could rate the rate the limit you hand out AAAAs, and rate that over time. But few people I suspect have software to do that. And obviously getting an IPv6 UDP is not a terribly high bar to set. So, it's a bar that some clients can't meet but it's still a high bar. Of the point of using a white listing is to incodify somewhere the quality of the working IPv6. And I think well, so among other things you want to also know that IPv6 connectivity is not all equal, right, and that it's not all equally well supported everywhere that you may see it. All of this was sort of the background of Google over IPv6 which everybody here has seen and knows about it. For each one of these we get a list of resolvers or prefixes, we have to make some attempt that the person who is making the request actually is moderately authoritative to do so. We take those numbers, look them up in ASN sorry find out with ASNs they originate from and we evaluate the connectivity. There are requests from people who want Google over IPv6 but have only one router connecting to the v6 Internet and it doesn't in v4. That's really not satisfactory for production quality stuff. So, we have routing table look ups and brokenness stuff. We have to record that they are willing to support their users in v6. And sometimes there is extra overhead, coordinating go lifetimes, traffic times, dealing with time zone issues, and in theory, you know, there is availability for an emergency revert although in two and a half, almost three years that we've been doing this I think that's only happened once and that was at the very, very beginning and we had no data analysis what over.
Looking at all this, so people didn't want to have to talk to us or, could we automate some of these steps, could we make is so that one network provider didn't have to contact each individual website to say that they wanted to do this, we were kicking out around ideas. And we sort of came up this thing that you know you could sort of explicitly signal your desire to receive or not receive AAAAs, you could opt in or opt out on a per AS basis. The mechanism users, as loose verification of operational ownership. Basically if somebody said you have the right so serve PTRs for these prefixes then that's probably good enough for now. It's also pretty simple in this case people who run networks that want to receive AAAAs don't have to contact each vivid person who is going to be doing white listing. You need to do this sort of thing. There is, there was a separate discussion around using NAPTR records, that's addressed in the document. But basically, you just need to put some text records with a certain format, yes, I want to receive AAAAs, okay, or not okay. Everything is okay except I don't want AAAAs from Google and Facebook. The mechanics of purchasing and analysing this are all in the document. On the white listing provider side, you have a bunch of work to do. You have to log these addresses, you have some off line background non realtime look up of all these text records. You have to analyse the results, process and merge them all into a new list, a new set of access control lists and then push them up to your server and then repeat. But, you know, you have committed if for someone is going to do white housing you have to do some work anyway, so obviously it's got a great number of limitations. There is a non trivial effort for people who are going to do white listing. If they are signed up for it they have signed up for a non trivial effort. Compliance is not required. If you put your stuff in the DNS it may not get picked up. Timeliness is not guaranteed. It certainly doesn't address the suitability analysis phase or the fact that the suitability analysis phase is going to be opaque through the requester. You still have to do connectivity and brokenness analysis. I mean, it's actually for sort of prohibited by privacy from sharing per IP address brokenness data. So but there is, at IPv6 white list .org there is a link that has a document and also some BIND configures and pie on this and shell scripts in unioney tests and running codes and stuff like that. Anyway, you ever may have seen it, Facebook is is starting to do white listing. They are white listing hurricane resolvers and some other folks and many folks are doing white listing lists automatic and implicit. Google is going to do that. The policy isn't decided. If we see that a network is not very broken but it also has no IPv6 users behind it, there is no point in serving AAAAs there. Deploying IPv6 doesn't mean it's necessarily going to work out of the box. I think I have basically used up my six minutes. So that's essentially it. This is just essentially another possible signal of information for folks.
JOAO DAMAS: Thank you, Eric. Is the idea just to document what the white listing processes or actually someone would start using it as a clearing house for exchange of information?
SPEAKER: If you wanted to have your resolvers receive AAAAs you could put this stuff in the PTR zone and I have code that can run and look for this stuff and scan this stuff. I have open source stuff, but I also have the start up some stuff in the regular Google code to do this but it's not fallen into any production process. In theory it's not just us, any people, can scrape their resolver logs and perform this look up on them and see what's going on.
AUDIENCE SPEAKER: Dave Wilson, HEAnet. Thank you for this. It gives me pause, this is why I recognise that for a company making a good faith effort to deploy IPv6 widely on the Internet like Google, whitelists are are the only sensible way to make a progressive deployment, but they are also bad, because they still allow for the creation of IPv6 islands without it getting out to everyone else, and what I fear is that there is a mechanism in this for some people to go, we are interested in IPv6 and for other people to go, we don't have to worry about IPv6. The most powerful thing about June 8th, is that I am able to go to my clients and other people and say there is something that is out of my hands and out of your hands and is happening here that we must take action to remove brokenness, and I would be nervous that if we with all get to opt in on a semi permanent basis, it might become permanent.
SPEAKER: I understand and we certainly don't want white listing to be a long term thing. It's been an enormous investment of effort and is going to continue and we would like to spend our time doing other more useful things. But the bottom line is that I mean, as, you know, we have people who carry the page errand who are responsible for liability of the site and they come to us and say can you quantify the harm of adding an AAAA record for this host name? And we have to give them an answer, right. This number of users plus or minus this you know 95th percentile accuracy is what we are going to lose when we do this. And bear in mind we have only beginning measuring this for IPv6 with HTTP and browsers have a "Known" fallback behaviour of varying quality. We haven't yet analysed what happened when you add an AAAA to an MX record. We haven't analysed what happens when you do, adding AAAA Yours sincerely include records and each one like that. For each one of these we have to prove negative harm. I agree, there is nothing like turning it on to make people sit up and get it fixed. But there is also no vouching for the quality of the fix that is people will choose. So... I don't know. It's not good, it's not perfect.
CHAIR: Thank you very much.
(Applause)
DAVE WILSON: This talk is a bit. Please go to this address. You are very welcome not to pay attention to what I am saying. I am Dave Wilson, and for the next 50 seconds I am my affiliation is Internet citizen. I have a question which, it's not come from my employer or anyone else. It's something I personally want to answer, which is what do we as operators of Internet infrastructure consider okay to do on the Internet? And how does that differ from what our users think? I think it's an interesting question and I'd like to find an answer, so I made a survey. That is the address, and what I am doing here is asking all the people here to fill it in. Like I say, this is on my own time, so I don't have any freebies to give away, but you will certainly have my gratitude for helping me to to a bit of science and see if we can find an answer to that question. I said I'd be done in one minute and that's 59 seconds, so if there are any questions I'd be happy to answer them during the break. Thank you very much.
CHAIR: We are actually running ahead of time. So if anyone wants to start asking, we actually have a few minutes. If not, as he said, you are welcome to find him during the coffee break, or later. So next one up
RONALD VAN DER POL: This is a project I started recently. It's a implementation of the IEEE 802.1ag protocol. It makes it possible to run Ethernet OAM on your management system or laptop. These are the few IEEE 802.1ag protocol. Basically consisted of three messages. One of them is continuity check messages, these are periodic hello messages, and they are used to detect loss of connectivity.
Next one is loop back messages. Loop back message and replies. That's a sort of layer 2 ping. You can ping to Ethernet instead of IP. Last one is link trace messages and these are similar to the IP traceroute, but they start to Ethernet addresses so you get answers from Ethernet interfaces.
The protocols are using so called M IPs and MEPs, maintenance end points and maintenance intermediate points. These define the path that the protocols run between. For example, this is a maintenance level 7. Then you have a path between this router and this router, and a couple of intermediate points in between, and on the next level, you are verifying this path. For example on level 0, you are verifying just links between two routers or switches.
So, again, continuity check messages, they are sent by an end point as multicast messages. There are no replies. They are processed by intermediate points and end points. Loop back messages are sent via the operator by the CLI. Centres sent by Unicast and the replies are also Unicast. Link trace messages are also sent by the operator to the CLI. They are sent as multicast and all the Ethernet interfaces in between reply with a Unicast until you get to the final destination. And it's also a TTL defined, that is documented with each hop so that you can define how long or how far your traceroute is going. And this is all on layer 2 on Ethernet.
So, what have I done? I made an open source implementation of this that runs on FreeBSD, Linux and Mac OS X. It's all in user space, so it's not you don't have to change the kernel. You only have to have route access, you need to have access the row interfaces so row sock etc. On Linux for example. It's still a work in progress.
Today, I have released the first public release in Alpha code. I'm looking for code reviewers, people who want to test it on FreeBSD Linux versions or Mac OS X. And also people who want to test with it that have equipment that supports 802.1 AG, so routers, switches, etc.. I plan to have a beta release later this month and in the summer the first official release.
This is an example of a layer 2 ping. This is an Ethernet switch in here, there is a Juniper router in here. A couple of interfaces defined with these Mac addresses, and here a Linux server. From this Linux server I am doing a ping. I status this interface, this VLAN, this level domain, maintenance level domain, send 10 pings to this Mac address and this is the Mac address of this Juniper interface. You get replies.
Next a trace also from the Linux server. It's TTL 1, you get a reply from this interface. TTL 2, you get the next interfaces, and the replies have a field that says what that interface is doing, this means they are forwarding, they are sending a reply but also forwarding it to the next switch or router, and in the end, I am sending to the Juniper router again, this interface. When it hits that interface, the traceroute stops.
You can have more information on this URL, you can download the code from this URL or you can send to e mail if you have further questions. And of course I also have to mention IPv6, this also runs on IPv6 networks also and even IPv6 only networks. Thank you.
(Applause)
JOAO DAMAS: Anyone got any questions at this point? If not, I definitely encourage people who are involved with the networks itself directly to try it out because it's a useful set of tools.
We have one last talk to do with some issues with the arrival of the speakers.
SPEAKER: Thanks for giving us this time slot, I appreciate it. We had a short kind bash off yesterday afternoon and people came up and though we have talked about LISP a number of times at I think the Routing Working Group especially at RIPE, it's been a while and I think it's only fair then based on the feedback we got last night to reintroduce LISP very quickly. We have a few minutes and a few slides and we'll time for any questions afterwards. My name is Darrel Lewis, I am technical lead with Cisco and one of the original authors with the LISP specification and with with me is Job Snijders from InTouch and I'll do the introduction and he is going to.handle the talking about how they have deployed and what use case that is they have found useful. But by way of a couple of slides in the overview.
LISP got it start after the routing and addressing workshop in 2006. We kind of considered that PI, that there was kind of pro two competing things going on, that end sites wanted PI and the routing table would be negatively impacted by lots and lots of PI, so LISP was kind of an attempt to take a shot at addressing both those needs, in other words giving customers PI and hopefully not directly inject that go PI space into the Internet DFC.
Let's see: So LISP is IP encapsulation scheme. It decouples identity and location by doing a map and incap at edge routers, so, we take the relationship between these routes and their location, we put them in the mapping database instead of the default routing table and because of that, the encapsulation we have the ability to handle IPv4 into IPv6 or 6 into 4 or 4 over 4 or 6 over 6. There is some interesting use cases that kind of fall out that have design decision. We think that LISP so far is shown to have kind of a minimal deployment impact on the site. And not every site of course on the Internet has to use it. You can think of LISP then as a kind of a resolution protocol for location where DNS resolves names to numbers. LISP resolves numbers to numbers where the last number is the location, the attachment point, if you will, of the site onto the Internet.
SPEAKER: I am Job, I work for InTouch, I would like to share some information on LISP that it's real and there are people using it today. It's not theory any more. These are the most common cases we have found so far that we solve with LISP. Efficient multihoming. We have plenty of customers that they want a real low price point to connect their office to the VP N or the Internet, but leased lines and BGP and getting an AS and space, the barrier is too high. With LISP multihoming is simple. We get cable Internet and a DSL you put that in a LISP box and the mapping system will be updated that there are not one but two locations through which the prefix is available. IPv6 is pretty hard to get native in most countries in Europe, but it's getting better. With LISP you can do multihoming over an IPv4 only connection and an IPv6 only connection and get v4 and v6 both over those two lines. So, VIX turning it up and making sure it stays up no matter what the underlying transport is. With LISP it's much easier.
Then the last case, we have most people are used to MPLS VP Ns to connect all their offices together or if that's not do believe, multi point GRE tunnels, or GRE tunnels. With LISP since it's a dynamically tunnel system, tunnelling between sites is much easier and in the LISP protocol in the LISP address format, we have added some bits, it's called instance ID and you could think of it as VRF support. The instance ID is put in a packet and that's how we can segment between customers and have a multi tunnel infrastructure.
So, these are the common cases. Thank you for your time.
SPEAKER: We have a little bit just overview. By the way there is a global pilot network, we have got over 100 sites in 18 countries now. If you are interested in participating in the beta network and you know want to do some testing or experimentation with with LISP, just send an e mail to LISP support.
I want to mention also that the LISP protocol specifications are currently in Working Group last call in the IETF, so if you have comments or give them a read, now is a good time to give the drafts a read and kind of let us know what you think or if there is anything you'd like to see changed.
Finally LISP provides level and indirection and I think it relates to the kind of struggle that we face between allocation of independent addresses to end sites versus the state of the global routing table.
And these references are just here. Like I said if you are interested in the beta network you can send and e mail to LISP support, and finally, there is no Cisco IPR in LISP. So we are attempting to do this as an open effort.
Any questions? I think we have a minute or two left.
JOAO DAMAS: Any questions for the guys on LISP? Just, you mention installing some hardware here.
SPEAKER: If you scan for Wi Fi networks that are up in the air, there is RIPE MTG LISP network it will give you an IPv4 and an IPv6 address, if all is well you should notice no difference whatsoever with the regular Wi Fi network, but you will be behind a LISP router. So you can experience that LISP is useful. View it as a NAT64 a society where you notice all is broken, with LISP it works.
JOAO DAMAS: Thank you very much. So those are the lightning talks we had for today. I hope you found this new trial of new format interesting. I am now giving the microphone back to Nick. He has some announcements to say before we break for coffee.
Nick Nick: Final notes before we wrap up the session, the schedule today. At eleven o'clock we begin the Working Group sessions in this room and also in the side room, the St. John's room. Following that later in the day we have the RIPE NCC general meeting. Those RIPE NCC members who have yet to register for that meeting, we have the registration desk open in the hallway, you'll see a sign there and some people manning it now. Please register early, and as I began this session, I'll again remind you that today is her /TK*EPBGen stack in Holland, a very special day of Remembrance, it's a war Memorial and we have a laying of the wreaths with the Queen Beatrix. And other members of dignatries outside so they'll be clogging the streets, you will see thousand thousands of people there, traffic will stop and there will be two minutes of silence at eight o'clock which we all recognise. So, that is it for now. I thank you very much for your time this morning. Enjoy the rest of the day.
(Coffee break)