ARIN XVII Public Policy Meeting Draft Transcript - 10 April 2006
"This transcript of the meeting may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting."
MR. PLZAK: We're just waiting for the people that are still consuming food in the breakfast room to get over here. So, I sent Leslie to go there and bring them back here in her amicable manner. So, they should be here shortly.
Okay. Welcome to Montreal and to ARIN XVII. And so, first of all, let me give you your Miranda rights. We are producing a video and so when you signed in at the registration desk, you were given the opportunity to opt out and if you want to opt out, you must sign the form. If you don't, you could end up in a movie. So -- and if you're looking for your chance to break into Hollywood, here's your chance right now.
What we're doing is that we're producing a video which will showcase the meeting activities and so you'll see the crew around today. They'll be at the social tonight and -- so, depending upon what you want to have in that video, you ask for an interview time at the social night and we'll also be doing it on Wednesday.
So, again, remember, if you want to opt out, go to the registration desk, fill out the form.
So, first of all, let's thank our sponsors. They're going to do us a really good job, so we'll see how it goes and I'm sure everything is going to be fine.
So, first of all, hotel floor plan. Everything is pretty much on this floor. You guys found a breakfast and lunch room and I'm going to go through a little bit where everything really is. The general session, everything is where we are right now. The meeting registration is at the foot of the escalators and the Cyber Cafe is around the corner.
So, the general session room is where you are at. The Cyber Cafe and the help desk are in the St-Pierre room. The Cyber Cafe is a new thing we started this time. It is -- we did away with the terminal room. That's what we did. And you still have the capability of printing and there is still a couple of terminals in there if you want to sit down and do stuff there. But there is a bunch of other things that are in there.
So, the cafe is opened at these hours, today from 8:00 to 5:30; tomorrow 8:00 to 6:00 and Wednesday from 8:00 until noon. And you visit it and you can sign up to win a Mobile Edge Premium backpack in the Cyber Cafe raffle.
So, in addition to the help desk being located there, there's also some flash presentations running, some information brochures. There's going to be a continual supply of coffee and so forth. There's some places and chairs to sit down and carry on conversations. There's a live audio feed from the meeting in there. So, there's a lot of things.
I will tell you this that the room that it's in this time is relatively small. The next time that we do this at the next meeting, the room will be much larger. It'll be more of a meeting area set aside, so more tables, more lounge chairs to sit and converse. But this is another place to have those little side bar discussions that you like to have without having to necessarily sit in a bar or wherever and be relatively close to the meeting.
So, if you need to step out and have a quick discussion, this is the place. If you want to relax, this is the place. So, please take advantage of it.
And in the Cyber cafe before I forget, we're going to announce the winner Wednesday morning some time. Registration Services Help Desk is located and also the Billing Help Desk. The Billing Help Desk registration service help desk keeps the same hours as the cafe.
Now, for those of you that are concerned about the fact, "Well, gee, I don't want to have anybody in the Cyber Cafe hearing me have this serious discussion with registration services or billing about my problems or my concerns and so forth", there is a room that's set aside close by so that private consultations can take place. So, going back to the first, yes, the psychiatrist is really in and so you have the opportunity to set up appointments or just to have a general chitchat with the registration services people. But at the same time, if you need to have a private conversation, facilities are available for that as well.
The Billing Help Desk, they're bankers so they have more banker's type hours and it's as shown here, 8:00 to 9:00 this morning, noon to 1:30 this afternoon and the same thing on Tuesday. And Wednesday, they'll be open all day.
So, in both cases, you can make appointment by sending e-mails to the e-mail addresses, that's email@example.com for Registration Services and firstname.lastname@example.org for the Billing Help Desk.
So, please take advantage of it. We're interested in your input and what we can do to improve this service for you to make your meeting experience more rewarding to you.
So, meeting registration, as I said, is at the bottom of the escalator, wireless cards, if you need them, are available there. Remember, at some point in time, you'll have to turn them in. Otherwise, they become here very expensive souvenir of the meeting. And, as I said, you found the breakfast and lunch room; it's on the other side.
Restrooms, there's two of them, as shown and it's marked.
So, before we proceed on, I thought we would want to get in the mood of things a little bit here so, let's -- and I know we all have concerns about this being Montreal and this being April and what it is. So, whether the weather be hot or whether the weather be nice, we'll weather the weather. Whatever the weather, whether we like it or not. So -- So, and I defy anyone to say that as fast as you can, 10 times in a row without making a mistake. So, I'm sure somebody we'll take me up on it tonight after having a few beers. So -- anyway.
Going out with that, we need to do a few introductions. So, in terms of looking at the weather, we have the board of trustees: John Curran, the Chair, Scott Bradner, the secretary and, at the back here, Lee Howard, the treasurer. I'm president. Bill Manning is somewhere out here -- back there, the trustee, Bill Woodcock is over there. Paul Vixie could not make it. And also not a member of the board, but a person that's present at the board meeting is little snow flake, Steve Ryan, our general counsel. So -- I don't know where Steve is. Oh there he is, he's back there. Okay.
So, now, that was sort of a winter tableau. Going to spring, we have the ARIN Advisory Counsel, the raise of sunshine causing the flower to bloom and this is the ARIN Advisory Counsel. And everyone is here from the advisory counsel except for Alex and Cathy. So, please feel free to grab them and talk to them. A number of them will be identified as we go through the policy processes today and tomorrow as being of specific policy proposals. They've been identified to a certain extent on the e-mail discussions as well.
But they're the ones you should really corner if you want to talk to someone about understanding what a proposal is about. And if you have some very specific questions and you want to get some input into the system a little bit.
So, the number of resource counsel, we've got three guys here: Sandy George over there, Martin Hannigan, Marty -- I don't see you, Marty. And then Louis Lee. So -- so, that's our weather for today but keeping on, we have our RR colleagues, AFRINIC. Today's weather, a high of 30 degrees Celsius, low of 23 with light showers. Ernest and Adiel are here.
From APNIC, we have Geoff, Gerard and Save. The temperature in Brisbane today is a high of 27, low of 15, sunny.
From LACNIC, Raúl is here. In Montevideo, it is nice 23 degrees centigrade -- uh, celsius, low of 19, partly sunny. So, it looks like the Australians are beating the Uruguayans again as far as sunshine goes. And from Amsterdam, for RIPE NCC, we have Axel, Paul and Leo. The weather is 9 for a high and low of 1, and very unusual weather, it is sunny in Amsterdam and Axel is here in Montreal. So, you missed the one day of sunshine for the year!
Anyway. Welcome to all the colleagues. If you want to get a little bit more in-depth discussion about what's going on in the other regions, I'm sure they would be glad to talk to you.
So, the key ARIN staff flying kites, Jenny -- there she is -- Susan -- Leslie -- Mary K, back there and Bob. Where is Bob? Oh, back over there. Okay. And Richard and Nate -- where is Nate? Oh, okay. Back over there. All right.
So, please feel free to see us. Also, the rest of the staff is here -- well, I would say a good chunk of the staff. We also have a contingent backing home making sure that business runs as usual. We don't stop doing business because we're having a meeting. The business of the registry goes on.
Staff can be identified by the yellow badge packets. So, we make easier targets that way. It's an easy target to look at. So, that's why I have the yellow shirt on, okay?
Okay. Some attendant statistics. This is the largest second quarter ARIN meeting we have ever had 155 people here. So, thank you very much.
So, first timers 58. People are here for the first time. That's a nice good number. The -- all the members here are from two of the countries, ARIN region, U.S. and Canada, 94 people here from the U.S. from 21 states and we have 40 people here from Canada, from three provinces. And from outside the ARIN region, we have 21 people here. So, thank you all for coming and we look forward to your participation.
So, first of all, welcome to first time meeting attendees. We did something new yesterday. We had a first timers luncheon held. We did it on Sunday, I should say. The attendees had a chance to meet the ARIN staff, some members of the board of trustees and advisory counsel. You can see pictures there of a few of them. And now, one of the things that we did is that as they went around, they had little slips of paper that had the names of all the board and staff members and AC members who are there. And as they met and chatted with each one, they had to put -- that person would put a little star or something on their sheet of paper and it took all of those and they put them into a bowl. And so, what we're going to do is take those things and draw.
Now, in order to be considerate for the raffle, you had to get all the little stars and dots filled in. So, if I could have -- I don't have Price-Waterhouse but I do have Susan to bring up the bowl here and I would like to have a volunteer come up who is not a member of ARIN staff to make the drawing. So, would someone please come forward? Let's not be shy. I know you're not shy, so -- come on! Ah, okay. Susan is here. Okay. So, Susan, if you would reach into the bowl and draw it out and give it to me.
Now, what is this person going to get? They're going to get a USB HDTV tuner with remote which -- what's down there. Right here. And -- the winner is Doug Wilson. Doug, are you here?
MR. WILSON: Thank you.
MR. PLZAK: Okay. Last night, we had the seventh annual foosball tournament and the tournament -- we were assisted to conduct this tournament by a member of the Canadian National Table Soccer Team, okay? We were politely informed in very strong words that we don't play foosball, we play table soccer.
Anyway, the interesting thing to note is that when we did the tournament two springs ago in Vancouver, the people that did it are also members of the Canadian National Team and so, I was talking to Adam last night, the gentleman that's here from the Canadian Team who was doing this last night and he said, "Oh!" And so, they are all, of course, on the same team and the team is going to Germany, by the way, to play in the World Cup. And so, I said, "Well, now you guys have something to talk about on the airplane". So, it was interesting, to say the least.
So, anyway unto the results. Third place rewarded trophy last night, Raúl and Scott. Second place, Scott and Owen. And the 2006 foosball champions are Lee and Bob. Now, for those of you who don't know or you do know is Lee is the treasurer of ARIN and Bob is the director of financial services. Now, probably many of you know, at ARIN, we have a small room where we have a foosball table. So, I thought these guys -- Lee was coming over to work on a budget but obviously, they weren't working on the budget, John, they were doing something else! So, we'll let it go at that.
There's one other thing that needs to be done and also present were Danielle and Jordi and I don't have a picture because they weren't there last night to receive their award. If they are here today, I have them and I will give them to you right now. So, Jordi and Danielle, if you are here, please come forward. And everyone knows what they look like and what they had to do to earn this esteemed honor. So --Yes, I will go there, Bill. So, anyway, join us tonight, 7:00 to 10:00, we're having a street party and we're going to have food and beverage of the local cheese sampling, we'll have a buffet dinner, open bar. Musical, we have a jazz trio. We'll have a DJ. For entertainment, we're going to have stilt walkers, jugglers, a magician. For Jordi and Danielle, there'll be foosball tables for practice and we're going to have some racing games. But it is literally going to be a street party. So, sponsored by Teleglobe. And so, be there tonight. There'll be more information given out later today.
Now, in the bag, you've got a bunch of stuff. You've got probably -- depending upon your point of view is what you think is most important. So, we'll get stuff out of here first. We have the meeting folder and I'll go back to it. Also, since we didn't know what the weather would be like, we included a blanket with the meeting logo on it. So, if you get cold, you can always wrap it up or wear as a the superman cape or something.
Also, you'll find, in here, some sustenance to help you get through the meeting -- that kind of thing. There's a travel guide. So, there's a lot of neat things in here. So, please enjoy it. Our sponsors went out of their way.
Also if you notice, at your disposition is another thing that's not in the bag, are these little folders with pens and so forth to allow you to take notes during the course of the meeting.
So, looking at the meeting packet itself -- folder, I should say, inside there's the bulletin which has the agenda and everything else in it. There's the quarterly newsletter. There is the annual report, resource policy manual which you will probably want to have handy to refer to as discussions will float around that.
Also, the ARIN policy -- ARIN XVII public policy meeting policy proposals are in here in text form for you to have handy to read and also a copy of the Internet resource policy valuation process, the document that we're following to do this.
And also, you'll find a new item which are -- is a sheet that discusses some meeting courtesies and the rules of discussion and also a survey flyer.
So, as we go through things over the next couple of days, these things will all become very handy to you. So, please, take advantage of it. And, also, we'll do a little bit more about the survey.
Meeting information, remote participation is available. We have had people sign up for it so they will be on line and, as in the past, their questions will be taken and brought to the mic. Webcast information and presentations and announcements and agenda changes are all at these URLs and, by the way, there are several agenda changes and they will be announced as we go through things this morning. So, meeting survey.
You had two chances to fill it out. One is -- you can either fill out the IPv6 workshop sheet or -- if you went to that. And, also, at the same time, fill out the ARIN XVII meeting survey. If you've only gone to the meeting, you can fill out the meeting survey. The surveys are online at the URLs shown. But you get a chance to win another prize.
So, if you went to both workshops, you're only going to get one entry from completing two surveys, sorry. But on the other hand, there are two lucky winners and the lucky winners are going to get a iPod nano. And so, please fill out that raffle -- uh, survey entry and enter the raffle.
So, what are we going to do? Well, what's on tap? We had a couple of information presentations about what's the IGF and it's going to be done by Lynn St-Amour from the vice-presidency of ISOC and then, we're going to talk about law enforcement of uses of the WHOIS databases and that's going to be done by Don Blumenthal from the U.S. Federal Trade Commission.
Technical presentations, Thomas Narten will be doing and IPv6 activities report and also we have bogon filtering for the fun and profit by Team Cymru. And this morning, very important and something that is going to become extremely important this year from an ARIN perspective is we're having a round table discussion on X.5 -- X.509 resource and routing certification. We have a panel here. The names of the panel members are in the agenda. So, that'll be this morning after the coffee break.
So, what's on top of the tap in terms of policy discussions? Well, issue area number 1 in terms of AS numbers policy proposal 2005-9. Issue 2 in the directory services area, two proposals, 2006-1 and 2006-3. In issue area of IPv6 assignments, three policy proposals, 2005-1, 2005-8, 2006-4. For those of you that have been following the discussions on the PPML of 2005-1 and 2006-4 are very closely related and 2005-8 could actually have an influence on the outcome of 2005-1 and -4.
So, all those discussions will occur today and so, please be around and participate in that. It's been lively discussed before and we need to go forward.
And in issue area dealing with micro allocations, also two proposals: 2006-2 and 2006-5.
So, I've mentioned the PPML several times here. What is it? It's a forum. It's a forum in which can raise and discuss policy-related issues. It is an open forum. The only thing you have to do to participate in the forum is go to the ARIN website at the URL shown and subscribe. Once you do that, you're on.
All policy proposals are always introduced first on the PPML. So, subscribe to it and participate.
You may probably be one of those many people that just works and watches what goes on. That's fine. If, at some point in time, you want to say something, saying "me too" is a very valuable thing. So, don't just hold off because you say, "Well, I agree with what's being said so I don't need to say anything". Saying, "me too" is a very valuable input as the AC goes through the process of trying to determine consensus.
So, back on the weather topic again. You've got to learn the signs to navigate the road safely. ARIN is -- operates under actually a set of parliamentary rules known as Robert's Rules of Order. All of our meetings are conducted that way, whether it be the board meeting, the AC meeting, the members meeting or the public policy meeting. And these rules are there to do several things and one of which is to make sure we can have a good free and open and honest discussion.
So, there are a few courtesy. Let's please be courteous to those around us. So, please, pay attention. So, let's not do e-mail, let's not do any serving or whatever else needs to be done. We understand that some of you are here because your boss say, "Well, you can go but you still have to work". So, we can understand. But I don't understand your work being surfing -- reading the CNN news site or whatever you're reading.
So, please be courteous. Silence all cell phones, pagers, computers and other various electronic devices and we probably should think about doing something for somebody that -- whose device goes off first in a meeting. So, we'll probably think about that.
Okay. So, the proposal discussion road. Every proposal, as it goes through the meeting is going to follow this little path. So, the first thing is that it'll be introduced in the meeting. And then, we will also discuss the -- what has happened to date on e-mail discussion list and I don't know if Einar got up at 5:30 or 6 o'clock this morning to summarize the latest overnight mails but Einar is busy at this time of the year.
Then, you'll see a presentation of any legal impacts that counsel thinks that this policy proposal could have if it was enacted. And you'll see an implementation analysis from ARIN's staff, what we think it will take to implement this and we'll categorize it as being significant, moderate or minimal.
And something new, there's either question about, "Well, gee, how is the staff really going to understand what this means? What is their interpretation of it? What are some questions and so forth that they may have?"
So, we're introducing it at this meeting and for all future meetings, staff observations will be posted to the PPML prior to the meeting. So, it'll be out there for discussion but we wanted to do it at this meeting here so we could basically make sure people understood what we were doing.
So, you'll see staff observations. Now, this is not staff commenting on the merits of proposal. We will never do that. However, we are the ones that have to implement the wishes of the community and so we have to interpret what you're trying to tell us. And so, as in any form of communication, it's good for us to understand what you want us to do and so, if we have questions, you're going to be presented here. If we think that this is the way that we are going to do this, we're going to tell you that. And -- you know, what we're trying to do is table off those unintended consequences that may arise as policies get implemented. So, let's pay attention to that and perhaps our policy proposals can become a little bit more crispy clean and we can get rid of some more ambiguities.
I know in yesterday's open policy hour, there was some discussion about the text of -- wording and so forth of a proposal not necessarily being clear. So, perhaps the staff observations will help that along as well.
So, anyway, after that, the author of the proposal, if present, will give the presentation. If not, then one of the shepherds from the advisory counsel for that proposal will make the presentation. If the shepherd does it, it's going to be an objective presentation. They will not present it in terms of whether or not they agree with it or not. They're going to make just an objective presentation using material provided by the author. And then, lastly, we will have a moderated proposal discussion led by the Chair.
So, on to that, the rules of discussion, first of all, and there's 10 of them. And, as I said, these are derived from Robert's Rules of Order. So, think of this as Robert's Rules light. Okay? You know, I considered why don't we put, you know, these signs about maybe, you know, 10 commandments and then finding an appropriate board member to stand up and hold the two, but I decided we wouldn't go this way. We'll see what happens.
Anyway. So, Robert's Rules light. First of all, everyone has equal rights, privileges and most important, obligations. Okay? So, we were all -- we are all right there and say, "Hey! I've got my equal rights. I've got my equal privileges." Well, excuse me, you also have responsibilities to execute the obligations that go with those rights and privileges.
So, we are going to have a full and free discussion. No tolls here. So, you don't have to sign up to be anything, you don't have to pay money to get here. You just want to be here. But it's a full and free discussion.
One proposal at a time, please. We're not going to embark off on tangents and raffles and so forth and the Chair will make sure we stay on that single track road.
So, speak from a designated spot and they are very easy to be identified. They are called microphones and there are two of them here, there and another one over there. So, do that and only speak when you are recognized by the Chair. If you try him up from sitting in the centre of the audience, there's two things: A) we don't know who you are; b) good chance that people aren't going to hear you and the people that really aren't going to hear you are the people who are trying to participate remotely and so you're doing everyone a great disservice by sitting in the centre of the room and just yelling. So, it's not going to be recognized.
So, state your name, state your affiliation. And before you go on a long preamble about who you are and why you're glad to be here and all the rest of this stuff in diplo speak and everything else and about how important this proposal is and so forth, up front, state what your intent is to either support or not support the proposal.
So, as the sign says, speak your mind and ride a fast horse. So, let everyone speak before speaking a second time. Share the road. Now, the Chair will moderate this and make sure that everyone gets a chance to speak and the Chair will make sure that if -- you know, we'll remember if you've been up to the mic and all of a sudden, right back in line again and we'll want to make sure that everyone else has had a chance to speak before you get a chance to speak a second time.
So, basically, we have an imposed a three-minute speaking limit. We don't have a clock timer go up when you get up there and all the rest of the stuff. So, you're not playing beat the clock. However, be considerate and be prepared to stop. The Chair may ask you to summarize and cease your presentation.
If you need more time, I suggest that you have a private conversation with the Chair about that.
Direct all remarks to the Chair. You don't debate across the floor and you don't attack the other people that have made some presentations. So, no transgressing. Violators will be shot and survivors will be shut again.
So, suggest amendments or secondary proposals to the Chair, okay? And certainly, as we go through discussions, there will be changes of thought about the way things go and maybe a better way to do it but those suggestions and amendments go to the Chair so the Chair can take appropriate measures in the discussion.
And lastly, only the Chair can poll a participant. You are not permitted to stand up here and say, "Give me or show hands everybody thinks we should do this". That's the Chair's job. Okay? Because the Chair is the one that has to explain what an affirmative and negative response means. And for those who have been here before, you know that John takes a great deal of time to make sure that everyone understands when they raise their hand what they are saying. So, for that reason, only the Chair will be polling participants.
So, before I move on, does anyone here have any comments or questions that they would like to make regarding our rules here? Okay.
So, moving on, this is a shot of the Cyber Cafe. If you haven't been there, please go there. Oh, that little laptop in the corner, by the way, has been replaced by a much larger plasma screen and there's a flash presentation running on it.
But anyway, if you've been around there, you probably have seen these guys here too. And you may be wondering who those guys are. Well, I was there yesterday too and I took the opportunity, and you can do so too, and I got my picture taken with them. So -- now -- we are looking for character faces to put on -- maybe put on some of these guys. So, Alec, you may be a good candidate, I don't know. So -- although I do know that when we discussed this in a board at our meeting in March, the board told Susan that, "Eh! I don't want to see board faces in these pictures". So, anyways -- so, who are these guys? Well, they're team ARIN and I can't tell you. But Susan knows everything and on Wednesday, she will tell you more about this. So, they are coming soon.
So, on your mark, get set and let's roll. So, we are now onto the agenda. So, the -- are we ready? First order business are the regional policy updates. Einar -- I'll do this for him, Einar Bohlin, ARIN policy analyst, and he will tell you what's going on in the other regions. Einar?
MR. BOHLIN: Thank you, Ray. I'm going to talk briefly about what's going on policy-wise among the RIRs. Under the category of IPv4 address base, there has been discussion in the APNIC and RIPE regions about changing the way they measure utilization. Instead of using 80 percent as where it used to, they're talking about using an HD ratio for that purpose. And just last week, LACNIC started talking about this too. I expect a proposal to come out about this.
In the APNIC region, this proposal is still under discussion; in the RIPE region, it's pretty far along. It's past last call and it's waiting a decision by the working group Chairs.
In the LACNIC region, they have a policy discussion similar to a policy that we already have which is multiple discreet networks and it would allow regional ISPs to come back for address base as a lower threshold. And in our region and the RIPE region, we're discussing any test -- IP for address based used for any cash services.
And more IP for discussion. At AFRINIC, they're moving forward with allowing assignments directly from AFRINIC to end users and they're -- the minimum for that is a /24.
They're also moving forward with the policy to allow temporary address assignments. That's similar to our policy about experimental use.
In the LACNIC region, they're discussing a policy to recover unused resources. And essentially, this one would be if a number resource hasn't been seen in the global routing tables for over a year, then they'll put into motion a procedure to attempt to recover.
And in the category of IPv6, the first discussion item here is changing the HD ratio to.94, that's for utilization measurement. It's been implemented in our region. It was adopted in APNIC but theirs was -- there was a stipulation that they would wait to see what the other RIRs would do. It's under discussion in the RIPE region.
And once again, last week, on the LACNIC list, there was discussion about something similar here and I expect a proposal to come out in regards to this.
The second item is amending the IPv6 assignment in utilization requirement and it's under discussion in the regions as show, APNIC, ARIN and RIPE. This one concerns changing the default assignment for example to /56 perhaps allowing variable length prefixes, changing the ratio to be -- the utilization, not ratio but default prefix size to be /56. And in the RIPE region, any cast proposal also includes IPv6 base.
Additional IPv6 discussions or development, the global policy proposal on allocations from the IANA to the RIRs is moving forward. It's being adopted in three -- by three RIRs and it is pending review by the AFRINIC board and waiting -- it's in the final stage at RIPE.
And the bottom two items here are ARIN region discussions and they're on the agenda this week. They've already been mentioned.
Autonomous system numbers. All of the RIRs have the proposal for the four by AS numbers. That's going to be discussed this week and in the AFRINIC region, they are moving forward with the proposal to change their ASN policy. Essentially, you need to be an Afri -- you need to be an AFRINIC member to get that resource.
In the category of directory services, we have a policy on residential customers -- residential customers privacy and captioning origination in templates. Those are on the agenda this week.
Services, we have a policy on residential customer -- residential customer privacy and capturing originations and templates, those are on the agenda this week.
If you want to see those proposals and the proposal texts themselves, here are some links to the policy proposal pages and as Ray said, there are members from the other RIRs here and I'm sure they'd be happy to help you with any questions you might have. Thank you.
MR. PLZAK: Thanks Einar. Okay, before we proceed, I did say there were some agenda changes today. At 1:30 will be the discussion of policy proposal 2005-8.
Today, at 3:15 will be the discussion of policy proposal 2006-1 and today at 3:45, Dave Deitrich will do the bogon filtering for fun and profit presentation.
Again, all these agenda changes are posted on the ARIN Web -- meeting Website and so I won't spend anymore time dwelling on it.
Next stop is Leslie Nobile and she will provide the Internet number resource status report. Leslie?
MS. NOBILE: Okay, good morning. First, I had to figure out how the -- the directions are right in front of me. This is an update on the joint statistics, the five regional registries otherwise known as the NRO collectively. Sorry, I'm still not getting this, okay. Okay, good, got it, thanks.
Okay. So, this is the -- actually the address -- the /8 address base, the IPv4 base, the current status of the v4 space.
In the bottom right is the space that's not available, it's deemed as special use by the IANA and there's 34/8 in that space.
What's available, above that, right now, in the IANA reserve, available for issuing to the RIRs are 62/8.
And then what's been allocated or what the RIR are allocating from presently is on the left -- the -- you can see, this space that we each have issued or are issuing from and then there's the central registry, that is the not the pre-RIR space, the old SRINIC, the DODNIC, et cetera, so there were 94/8 issued pre-RIR days.
So, this is the -- in a side-by-side format, we went back to -- I think it's 1997 and we -- through today, actually, there's a current as of March 31st, so they're pretty recent and we've looked at all of the P4 allocations from the RIR to their communities.
It says LIR, but this is actually the total space we've issued including End-user space. So, and 2005, basically, the things we note here is we've -- everyone of the RIR issued more space than they did the previous year, we're seeing some growth in all the regions in v4 allocations.
This is just another way to look at it, it's a cumulative total -- I'm sorry, it's from 1999, it wasn't 1997. So, the cumulative total that we've issued since '99 and this is kind of interesting because this is the first time that APNIC and RIPE NCC have actually issued more space in total, cumulative total, than ARIN has.
So, it's kind of interesting. These are the ASN assignments from the RIR to their customers and the thing that I've noticed about this in 2005, this isn't the first year that the RIPE NCC issued more ASN than ARIN, previously, it's been ARIN issuing the largest amount of ASN but RIPE is increasing their ASN assignments.
And again, the cumulative total from '99, ARIN in the big blue pie, there's really not much to note there, just to see the cumulative totals.
IPv6 allocations. These are the number of /23 that each of us have received from the IANA to date and you can see, the RIPE NCC, the growth in that region has been really incredible, they've gotten a 198/23 from the IANA thus far.
And the rest of us are just kind of trailing behind. APNIC, there's been some growth in that region as well.
And this is the IPv6 allocations to our customers to the ISPs obviously with the policy, right now, it is for ISPs and LIRs.
We all saw a growth -- well, we saw -- ARIN regions have growth last year. The RIPE region actually issued less space than they did the previous year as well as APNIC.
I'm not sure what that -- what to attribute that to. Just so that you note, RIPE NCC and APNIC have issued very large allocations in IPv6.
We typically issued LACNIC AFRINIC and ARIN so far, actually, I think LACNIC issued a big -- a larger than /32 allocations but RIPE NCC and APNIC have issued several /20s and /22s and very large allocations which is part of this growth that you're seeing here.
And the cumulative total again from us to our customers and the RIPE NCC has obviously issued quite a bit of space, 552 allocations they've made thus far in v6. And this is just a link to the RIR stats, they are on the Web page and then you can get actual raw data from the Website, the IANA Web sites and the ASO ICANN Website. So, are there any questions? This is -- that's it. No, okay? Thank you.
MR. PLZAK: Thanks Leslie. Next stop is Thomas Narten and Thomas will be representing with his IPv6 activities report.
MR. NARTEN: Okay, I'm just going to do a brief update on what's going on in the IETF, and particularly what's happened since the last ARIN meeting in Los Angeles.
And I'll start off with Shim6, there's been a lot of work going on in here, I don't think I need to talk too much about what Shim6 is, there's been a fair amount of discussion, even the PPML list on the net and on other venues as well.
But the working group is moving along, they have sort of three core documents they're focused on, there are close to being done with all three of them and the current plan is actually to advance them together as a unit because they all really fit together, they depend on each other.
There's a cache-based addressing, addressing document that's already been declared done by the working group and is sitting on the ISG's plate; there is a protocol document which is undergoing working group last called to current time; and there's a failure detection document as well which is going to be going through working group as called fairly soon.
And I can't say -- enough time, now would be a good time to review these documents if you, you know, have any comments on them as they're going through the final stages of review.
The goal at this point is the working group actually had a pretty long discussion at the Dallas IETF meeting, you know, are they reading for implementation and so forth and there's a clear sense that they are ready for implementation in an experimental sense and if the specs are clear enough, we'd like to incur some experimental implementations.
But the working group is clearly also not sending a signal that they're ready for, quote unquote, production implementation and then deployment, okay, but there's definitely a desire to get implementation experience and operational experience from it.
In terms of what else is going on, and again, this is not new, we've talked about this in Los Angeles already, there have been Shim6 BOFs held at some of the various operative forum, there's been one held in NANOG recently, the was one in APRICOT -- well, not that recently.
There's an upcoming BOF plan for the ARIN region -- I'm sorry, for the RIPE region in two weeks and some of the feedback so far, this is as sort of summarized by Dave Meir is, you know, end systems complexes concerns about the complexity, DNS latency issues, what is the impact on traffic engineering and on the overall routing and dressing architectures.
And for more information, I'd encourage you to look at the slides that Dave Meir put together and presented, the Shim6 BOF reflecting the feedback.
Of course, one of the big concerns that have been raised, you know, in this forum and also other places is that Shim6 is not really what some of the operators were looking for and they want something that's more oriented towards having a lot of the policy and decisions being made, kind of an edge box in the network as opposed to the end host.
And the working group is starting to have some discussions about that, I wouldn't claim that they've gone very far but there is -- on a particular, there's one draft that's been produced for the last IETF draft, Nordmark Shim6 ESD which starts exploring the applicability of the Shim6 design to doing some of the offloading on edge devices.
And Dave Meir has also put together a draft that talks about Shim6 and traffic engineering, these are all very -- definitely it's a very early stages of work, need review, need feedback, need more discussions and again, I'd encourage you all to -- if you're interested, to go look at those and, you know, follow up with the authors and with the working group.
Over in the IPv6 working group, again, as I reported last time, this group is now really the maintenance mode, wrap-up mode, they did not have a face-to-face meeting in Dallas, there's no plans to have face-to-face meetings in the future.
They have three documents that they're close to being done and they revised RSC so there's nothing really new, they're really cleaning up ambiguities and making clarifications to the existing RFCs.
And in one area, they're still trying to nail down the policy discussion of when to invoke -- when to use DHCP and when to use stateless autoconfiguration and how much of that should be sort of forced by the standard versus just a recommendation on how to word that.
There's also a document that I -- Lay Roberts, myself and Geoff Huston submitted, 3177 bits which we talked about here before and the goal of this document is really to update and revise, replace RFC 3177 which is the original recommendation from the IETF, from the IAB and the IC on the /48 recommendation.
And finally, in the RFC Editor queue, they had one document that's been produced and approved by the ISG since the last year meeting, that's ICMP name look-ups which is another way of doing reverse queries, not using the DNS but by sending essentially an ICMP query to the node saying what is the DNS name associated with this address.
And this is something that's sort of experimental, it's been around for a long time, there have been implementations and people --have asserted that it's quite useful for debugging it, if not more.
Okay, in other words, the v6ops working group, there's a number of documents again that are under active discussion, there's enterprise analysis, this is really about, you know, v6 and how it applies to the enterprise, there's an ICMP v6 filtering document that talks about, you know, recommended guidelines on what to filter in the granularity and some of the issues relating to filtering ICMP.
There's one IPSEC documents, they've also set a number of documents up to the IESG for consideration, there's a broad band deployment scenarios which is really talking about different ways you could deploy v6 in broad band networks or in remote access scenarios in support -- there's a NATPT experimental, there's been long discussions in the ICF about whether protocol translation -- that protocol translation which is essentially the v6 to v4 conversion using that, but how good of an idea that really is.
There's a lot of concern that is really not a good idea and the -- doesn't really want to be recommending it, because whenever you sort of go in that direction, there's always these other issues that crop up and so, it's not really a good solution in any sense.
And the purpose of this document is to reclassify the NAT PT technologies experimental and include you to more warnings about why it's not really recommended and why, you know, it's not a good general solution.
There's also a document that describes some security issues that relate to v4 and v6 and running them both, you know, dual stack in the network.
And then since the last meeting, the IESG has approved a couple of other documents, one on VLAND usage and one on the on-link assumptions, it had to do with, like, determining which prefixes were on link and some of the implications of that.
Okay, one of the more interesting groups, again, for this venue, there's a softwires working group at the last ARIN meeting, this was still a BOF, this started off as tunnel config but the basic idea here is, it's trying to do tunnel set-up for v4 over v6 and for v6 over v4 and the specific scenario that's the main focus is for an ISP that wants to provide IPv6 service to its customers but doesn't necessarily -- in fact, it does not have IPv6 at the edges and so, there has to be some way of tunneling across -- at least the partial v4 infrastructure to get into the core of the ISP whereas IPv6 service.
And it is a formal working group now, they had an interim meeting prior to the Dallas IETF and they're moving along fairly quickly, they -- you know, they're -- in some sense, if we don't get this done quickly, then we've missed our window and the main focus at this point is finishing up the problem statement and then they have some solution documents that are in the works that they're also actively discussing it at this time.
Okay, so another BOF, this isn't really IPv6 related specifically but there's a secure inter- domain routing BOF, this is a topic that's been discussed here a little bit in the past and in the IETF on and off.
I won't say too much about it because it's an ARIN topic for this week as well other -- then, there's -- you know, been a proposal to create a formal working group to follow-up on this work in the IETF. Okay. Questions or comments? And that's really all I have.
MR. PLZAK: Before we do proceed, one comment. You know, the continual battle, if you will, back and forth between the RIR and the IETF is about staying out of each other's business.
And so, just as we don't want -- or the IETF doesn't want us running technical working groups, and we don't want them running policies, it's important for us to communicate back and forth to each other.
So, that's one of the reasons that Thomas comes to our sessions and presents this information.
And he did make a few calls in there for you to pay attention to what's going on because the last thing we need to have is an IRSC get propagated that's called policy implications in it and all of a sudden, he says, well, why did they do that?
Well, he has the opportunity to participate and so, that's a very open and public form as well. So, please take and pay attention because there are a number of policies that we have in effect today that are the result of actions by the IETF and some of those are causing controversy factors, policy proposals on the docket today is the result of an IETF action several years ago.
So, I ask you to please go back and look at those things that Thomas has been talking about and really pay attention to it because some of them obviously do have policy implications for us.
MR. PLZAK: So, off the soap box on that one. Now, we're on to the first policy proposal of the morning and that's policy proposal number 2005-9, the 4-Byte AS Number.
And a description of the proposal is to establish three dates for changes to autonomous system numbers.
The policy, first of all, in January of '07, the request will be processed for 32-bit ASN but otherwise, the default is a 16-bit.
In other words, if you come and ask for a 32-bit, you can get it, otherwise, you're going to get a 16-bit.
On the 1st of January is that that situation reverses, that you can ask for a 16-bit but otherwise, you're going to receive a 32-bit and then lastly, on the 1st of January in 2010, you'll cease to make that distinction.
The AC shepherds for this are Alec Peterson and Mark Kosters. Brief history proposal, I was first introduced in December of '05 and was designated a formal proposal - we have a little problem with the slide there, how about that?
On the 26th of January of this year, the first public policy meeting discussion of it is this meeting.
This policy has been revised one time since the text was submitted and that was in February of '06.
And the URL is listed and as I said earlier, the proposal text and the meeting docket. So, from an implementation assessment that was done in March of this year, resource impact is significant in that it's going to require a template change, registration software changes, guidelines change, staff training and some educational material.
Some of that staff training is training the staff on how to answer the questions that the community is going to have to -- is going to have in regard to this, so the help desk needs to know what to say when they're talking to the community.
And we will be producing educational material to have available, for example, in the Cyber Cafe for people to read, and also on-line.
So, counsel sees no legal risks in this policy at this time as of March of 2006 and to date, staff really has no comments about this proposal in terms of understanding it or how we would interpret to do the job.
So, the PPML discussion -- approximately 112 posts, 23 people, 12 number against a couple of comments and I won't really read those for you, you can read them or you can go to the archives and read them all.
And that proposal is on-line and I will now turn it over to Geoff who is the author of this proposal.
MR. HUSTON: Thanks Ray. Good morning everyone, good morning John. Bonjour, mesdames et messieurs, ladies and gentlemen.
This is a proposal actually which was introduced 2005 RIR simultaneously. And I must admit, the one thing I do want to note is that only the PPML mailing list was active in reviewing this across the entire global RIR system and thank you all for your constructive and detailed review, I really appreciate it, actually.
And in fact, I've been quoting the PPML review and comments raised to the RIRs and I hope that sooner or later, they actually pick up the picture of these things that are here to be discussed. So, thank you.
What is going on here is that what I wanted to do is to actually create a policy framework that eases this into a transition from one numbering plant into a second numbering plant with as much predictability and clarity as possible.
So, what I'm trying to do here is to actually set up some dates here that allow us, as industry players, if you will, to figure out what we need to do and by when and how needs to do it.
This is based on earlier work in the IETF, the entire sort of technology behind this is now sitting with the IESG, it's gone through the idea of working group and is now sitting there as a proposed standard, I expect that to be published relatively quickly.
And what it proposes in the ARIN policy proposal is to take that work and then nominate three dates which are actually critical milestones as Ray has already described.
So, what I'm anticipating as a result of this is that IANA will be there with an expanded 32-bit AS number registry completed by the 1st of January 2007, and the other assumption behind this proposal is that ARIN, in this case, would ensure that its systems are now 32- bit claimed by that same date.
So, those are the assumptions behind this proposal and what is going on here is, as Ray has already gone through, is that three dates happened.
As of the 1st of January next year, you can ask for larger number. If you don't, you'll get a number from the existing 16-bit, in other words, the higher with a 16-bit will be zero.
That will go to two years, there's no particular conditions under which you can ask for larger number, if you want a larger number, simply say, I want a larger number, is the idea behind this.
In two years time from that, however, it will go the other way. If you ask nothing in particular, you'll get a number with norm zero -- bits.
If you want a 16-bit number with zero -- bits, explicitly ask for one. So, it just flips the bits.
Commencing on 2010, there'll be no more distinctions between the two. So, that's the essence of the proposal here.
What it does not do, it does not propose any further additions to the private AS numbers base, so the private AS numbers base is between 64,511 to 65,535 and that's the way.
It doesn't define any documentation these AS numbers, there's no additions to that. It doesn't advocate the continuation of any legacy number, so I'm not saying that ARIN should hold any 16-bit numbers in reserve.
On 2010, it simply becomes a larger pool and that's it. This is a temporary policy so the 1st of January 2010, it vaporizes and this number pool was a 32-bit number pool.
This can be done separately by each of the IRRs so there's no coordination across the IRRs being implicated, yes, the same policy is being submitted to all five IRRs and yes, the unbelying predictions of the exhaustion of this 16-bit AS number space are still laid globally and it's still somewhere around 2010/2011, so this makes sense in all the regions, but there's no precondition that we actually have to coordinate this. And nor does it define any different AS number allocation practices, so the existing policies for AS number allocations remain precisely as they are today.
So that's the essence of the policy proposal. I believe the next step is to hand it to the Chair. Thank you.
MR. CURRAN: Thank you. Okay, microphones at this time are open for any questions on the presentation, or questions about the policy proposal. Please speak your name --
MR. DILLON: Michael Dillon, BT Radiance, and I don't support this policy proposal. I'm wondering, there are three dates; on the second date, you propose that people can apply for an AS number and specifically request one less than or equal to 65,535. That's some two years from now. How do you know there will be any left?
MR. HUSTON: If you're asking what are the ranges of how do I know there will be any left, the last three to five years has actually seen a relatively uniform rate of AS number consumption. The underlying assumption behind these dates is that that industry trade will largely continue as it is. By 2009, there is an expectation over roundabout 15,000 AS numbers left in the pool.
MR. DILLON: Okay. Can I ask a second question, Mr. Curran?
MR. CURRAN: Oh, yes, proceed. Sorry.
MR. DILLON: I don't understand why this proposal introduces a classical nomenclature for these AS numbers. As far as the policy is concerned, it's a 32-bit number, and yet we have this confusing nomenclature which makes them look like floating point numbers, where 1.0 is not the same as AS number 1. Why?
MR. HUSTON: My brain is small, I find numbers bigger than a few tens of millions difficult to remember. Segmenting into number-dot-number just made it easier for my brain, and I hope that it will make it easier for others.
MR. DILLON: Well, I don't think any of us have to remember these numbers, they get configured into a system somewhere, and you forget it. It's handled all by machines, not by people. But from the policy point of view, you know, we're simply dealing with numbers that range from zero up to some four billion or four million, or something like that. Why do we need to stick dots in the middle of somewhere and make the number different from what it really is? I don't understand this.
MR. CURRAN: Just let me ask this question of Geoff. The proposal has a discussion about, in various time ranges, what happens if you make a request and it's not specific about the range that you want your assignment from. The proposal also introduces some nomenclature. Is the nomenclature part of the proposal that's mandatory? Would you be amenable to not having the nomenclature in the proposal?
MR. HUSTON: I'd be entirely amenable to not having the nomenclature in the proposal. It was simply, as I said, an aide to actually describing what was going on. So it's not a part of the proposal, it can be dropped, yes.
MR. DILLON: Well, my brain works a lot better with 65,535. It's either less than or equal to that, or it's bigger than that, and there are three dates relating to what you do with those two ranges. Anyway, thank you.
MR. CURRAN: Thank you. Back to the microphone.
MR. SCHILLER: Jason Schiller, UUNET/Verizon Business. I just had a question about the dates listed in the proposal. There's some specific dates numbered, mentioned, and are these dates in line with when the RFC is likely to be accepted and when vendors are likely to have running code, or say, for example, if by 2010, we don't have routers that support longer AS numbers, what happens to this policy?
MR. HUSTON: There are a couple of things, I suppose, that we should all be aware of, and the current run rate of AS numbers by or roundabout October 2010, if we do nothing and the current run rate continues, we've all got a relatively large problem, vendors, industry, the lot of us.
Now, this proposal doesn't require that everyone with existing AS numbers does anything at all, because the way the transition scheme works, this is a transition scheme where the deployer of the longer number actually has to do the work in new BGP implementations. Part of the reason for this proposal is not just for, if you will, the ISPs, but this is an industry with suppliers, and if you will, customers, and we need to give clear signals to suppliers as to when technology is actually necessary in order to stop disruptive transitions that cause pain and expense. So these dates are deliberately pushed in a fair way.
So we're actually saying here to industry that there will be -- in 2007 who have a legitimate need to run BGP implementations that support 32-bit AS numbers, and this is as much a policy proposal signaling to the supplier side of the industry as it is to the customer side of the industry, the ISP.
MR. SCHILLER: So if I understand that comment, this should drive IETF and vendors to provide a solution by these dates, or sooner?
MR. HUSTON: This should be a clear signal to those vendors who haven't released code in that area that this is a good date to have which tested as well as then starting releasing implementations of code to support this, yes.
MR. SCHILLER: Okay, thank you.
MR. CURRAN: Okay, far microphone, Marla.
MS. AZINGER: Marla Azinger, Frontier Communications. The last time this was discussed, I had the same question, and I haven't heard it since. Has there been testing with 32-bit on v4 and v6, and what were those results, if there were?
MR. HUSTON: This is testing with BGP as distinct from the protocol of the payload. The IETF in the inter-domain area, in fact in the routing area of the IETF, is now insisting that implementation and inter-operability reports being prepared as part of the submission of the draft to the ISG. There have been two implementations known and reported on that have been tested to meet the requirements of the draft and inter-operate. There is a draft describing that the implementations are, and here I'm trying to remember correctly, Juniper and I believe Red Sand; I'm not sure.
To the extent that there are implementations out there, they have been tested for improbability. To the extent that it affects the payload of the protocol, it is unclear that this would affect the payload of the protocol. This is BGP signaling not what's inside the packet, if you see what I mean.
MS. AZINGER: I do, and that answers some of my questions about it, because there were more actually doubt I guess the last time we talked about it, whether or not there would be issues, and if we needed to reserve special 16-bit, a certain amount of 16-bit numbers in case all hell broke loose with the 32- bit. So, that was --
MR. HUSTON: We do not believe there are issues around that require a reservation of 16-bit numbers, no.
MS. AZINGER: Okay. Thank you.
MR. CURRAN: Marla --
MS. AZINGER: Oh, and I support this policy. Sorry.
MR. CURRAN: Thank you. Side microphone, Owen.
MR. DELONG: Owen DeLong, Netli Networks. I do support this proposal. The nomenclature is actually not part of the proposal, it's part of the explanation that went with the proposal, so hopefully the fact that it's not actually part of the codified proposal will align Michael's concerns and perhaps he can change his opinion on that basis.
MR. CURRAN: Thank you. Far microphone?
MR. SEASTROM: Robert Seastrom, ARIN AC and Inter dot net. I'm generally in favor of this proposal, although I am not in favor of the nomenclature, and hopefully the fact that we all seem to have a pretty good luck rate at remembering telephone numbers, which are similar numbered digits in length, will allay some of Geoff's fears about that.
MR. HUSTON: Either that, or you can help me with my small brain. Thank you very much.
MR. CURRAN: Thank you. Other microphones are open? Yes, Jason.
MR. SCHILLER: Jason Schiller, UUNET/Verizon Business. I just wanted to point out that telephone numbers have dashes between the numbers.
MR. CURRAN: Okay. Microphones remain open. Randy.
MR. BUSH: Randy Bush, 3130, I agree with 702.
MR. CURRAN: Okay. Yes, Leo?
MR. BUCKNELL: Leo Bicknell, ARIN AC, and Harrah's Entertainment. I support the proposal and my comment would be that because the nomenclature is not part of the proposal, I would hope ARIN would use whatever industry standard nomenclature is developed, since we are not the nomenclature development group. So whoever makes that decision, because I'm not even sure who it is, I hope we just make our documentation map so it's not different.
MR. CURRAN: Okay, thank you. Further comments? Okay, let's all thank Geoff. Thank you. At this time, it's necessary to provide guidance to our Advisory Council so they can know what to do with this recommendation, with this proposal. We've had a good discussion of the topic, and now it's going to be necessary to put it to a show of hands for people who are in favor of this policy proposal and people who are opposed. So first, I want to verify, do I have my counters ready? Yes. Yes. Yes. Very good.
Okay, so, the question is, Policy Proposal 2005-9: 4-Byte AS Number, I'm going to ask for a show of hands for everyone in favor of advancing this policy proposal, and I'm going to ask for a show of hands for the people opposed to the policy proposal. Okay?
All right, all those in favor of Policy Proposal 2005-9: 4-Byte AS Number please raise your hand. Hold it nice and high. Hold it high; no waving your arms, please. Okay, thank you. All those opposed to Policy Proposal 2005-9: 4-Byte AS Number please raise your hand. Raise your hand high. Okay, thank you. And the numbers are coming up. Thank you.
So, in favor of Policy Proposal 2005-9 is 70 votes in favor; opposed, 3. So that information will be brought to the AC for them to do their work. Thank you.
MR. PLZAK: Okay, thank you, John. We are actually going to have a long coffee break this morning, so -- or should we just do a half hour? What do you guys think? Do you want to go up for a longer coffee break? Well, I tell you, you guys are really asleep. I don't know how 70 of you got a chance to raise -- 73 of you could even have the strength to raise your hands. Okay. Okay, anyway, let's take our break.
Please take the opportunity to visit the Cyber Cafe and to chat with the AC folks, especially about the stuff that's coming up, and please be back here at 10:45 and you will be called back in the room if you aren't here. Thank you.
MR. PLZAK: Okay. We're now going to convene a discussion panel, X.509 resource routing and certification and the members of the panel are on stage here, really left right, we got Geoff Houston, Steve Kent, Steve Bellovin, Randy Bush and John Curran.
And in regards to certification and so forth, it's no longer a matter of it, it's nor a matter of when.
And so, I won't go any further than that and I will turn it over to the moderator of the panel which is Mr. Bush. Pardon?
MR. BUSH: No, I'm not. I just got nominated as a moderator, I never had any notice of this, et cetera. I'll fake it.
For those who weren't there at the time, by the way, this was the first ARIN T-shirt, it is nine years old, how it managed to put up with me for all those years, we'll leave as an exercise to the student.
The discussion is certification of allocations, of resources by the registries, this work is being spearheaded by APNIC, we're trying to give you a little perspective on the subject. Steven Bellovin will kind of motivate it from the routing security view point which is where we all hope to end up in five or 10 years, which is secured routing.
In the interim, we're also interested in secured and verified data in the registry of -- you know, I can actually check that you really do have those allocations, et cetera, I'll cover that.
Then I think it's -- Geoff is going to cover -- give you a status report on APNIC's trial and there was a second piece, give me a clue, Geoff. Tools, there we go.
And then Steve Kent will tell you some about the dirty bits and then John will kind of wrap it up in ARIN perspective. Doctor Bellovin.
MR. BELLOVIN: You know, as an Internet security guy, what's much less known, though I have stated thinking about routing security issues that got me interested in Internet security in the first place.
So, I've been worrying about this problem for literally 20 years. We've made a little progress.
So, what is routing security? Well, it's bad guys playing games with the routing protocols to divert the traffic in some fashion.
The enemy can see your traffic, the enemy can modify the traffic, the enemy can drop traffic and of particular interest to an organization such as this, makes it easy to do things like prefix hijacking and prefix stealing and prefix assertion, land grabs.
If you have anti-encryptography which not very many people on the Internet do, that will help what is well known by no means solve the problem.
It's also a different kind of threat and most of the threats that we deal with when we're dealing with Internet security, most communication security failures happen because of buggy code or broken protocols.
With routing security, the protocols can be 100 percent correct and the implementations can be 100 percent correct and you'll still have a problem because of a dishonest participant, it's got to do with people lying or routers lying, not routers misbehaving because the coder is having a bad day.
And the simple kinds of authentication that we know how to do the hop-by-hop authentication, I think IP set or TLS or something of that order is not sufficient to solve the routing security problem, the BGPMD5 hack is not sufficient to solve the routing security problem.
So, when this very simplified Net, we've got site A trying to talk to site B and the -- it should go through XY and W to reach there, the problem is we have an enemy out there, Z and the enemy is trying to divert the traffic to go through Z.
It's a longer path, it shouldn't happen, besides, that's where the bad guy lives, we don't want it to happen and it can.
The way it happens, the enemy would generate some sort of fake routing advertisement, pick the prefix of your choice, the one you're trying to hijack or the one belonging to your target, he can't make that in the BGP world with a fake AS path.
One that looks more attractive to the next top, then legitimate advertisement for that prefix.
Your neighbor is going to be -- is going to look at the two advertisements and say, oh, this one looks shorter, I'll take this one, I'll believe this one and we'll route traffic to that prefix towards the attacker instead of down the correct path.
And if you just want to spy on traffic and not completely hijack it, after you look at it, after you modify it, you set up a -- to something that is closer to your victim, close enough that that router won't be deceived by your fake advertisement and reinject the traffic over there.
It means basically you need to own two routers, one near the source, one near the victim. From all reports, even if we don't have -- the easiest way to do it is simply buy connectivity at two different points on the Net.
If you don't want to spend your money, you can go hack into a router some place but all accounts, that's not particularly hard.
So, again, in this particular example over here -- the -- Y is telling Z and X legitimately that it's got a 2 AS hop path to site B but Z is telling X it's got a 1 AS path to site B.
It's easy to see which X is going to believe. The problem is that X has no knowledge of these real connectivity, even Y has no knowledge into these real connectivity, the problem isn't the link from X to Z, the problem is what Z is saying.
And, of course, in this example, Z being dishonest, but Z, in fact, could have been completely honest but deceived by some upstream neighbor of it, say Q.
Unless you know the full topology of the Internet, the full AS interconnectivity, and everybody's policies and no one knows either of any degree of authority, you can't solve this a priority, you're just looking at these paths and they look right, your neighbors may be completely honest, no one is playing games with the link, it's just that somebody is lying.
So, next question is: Who's launching these attacks? The most visible use of this has been the spammers, they've actually lately backed off on this a bit as best I can tell, it's easier to go create bot nets, have worms create bot nets and launch the spam, that way, to close that down, you know, in five years, Windows just might shut some of that down, they'll switch back to routing attacks.
We have people who want to do genial service attacks, take somebody else off the air, we get that for vandalism, you see, there's a lot in the D dos world for extortion, especially against bedding sites, all you guys are ISP, you know this better than I do. There are industrial spies who can do this and well, let's just say that there are other people who are playing these games and I'd rather not say more but these are the first reports I heard, well, this actually happening in the wild.
The biggest attack would have left off this category, the accidental misconfiguration, things like the AS 7007 incident, like last September, AT&T, backbone being largely off the air because a Bolivian ISP was announcing 12/8.
All of this is threats that could be averted if we had proper routing security. You want a spy on traffic? Well, traffic that should be encrypted isn't, especially e-mail, even stuff that is encrypted, say secured Web pages, you generally get to that Web page by clicking on a link on an unprotected page.
So, I divert all traffic to that site and when the unprotected page goes by, I change the link, a secure link to go some place that I control -- certificates, who checks certificates?
I won't ask in this room who knows where a certificate is, though I've had fun asking that in other audiences, but let me ask, and I hope this doesn't violate the world against voting, John or the Chair. Who always checks the certificate of a site when doing a purchase on-line?
Very good, I see about four people. Steve, I'm not surprised that you are one of them. The attack has been modified, think fishing on steroids and of course, most e-mail is not encrypted, even if it should be.
Denial of service, you attract the traffic by sending out this fake prefix and divertissement but you don't forward it, or a subtle attack as you forward most of it but not all, you forward things that look like traceroutes and pings but you selectively
drop TCP traffic that you're interested in and really slow that connection, you selectively drop DNS queries, think about that way to attack.com or the route.
But the pings and traceroutes will all work just fine unless you're using a DNS protocol based to traceroute or a TCP base traceroute.
You know what prefix is? In general, just connect to a clue as ISP, one it's not filtering the advertisement from their own immediate customers, there are plenty of those out there.
ISP you have PI space, and start using your stolen prefix or a land grab, there have been articles, places like security focus, people are finding prefixes that aren't used and reselling on them what they will call the gray market, I will call the black market and people just start announcing them.
How many put these sites three hops upstream checking all of the AS path they receive against routing registries.
You know the answer to that as well as I do. We don't fix routing, we don't fix routing security, we will see more attacks. As some of the other attacks vectors are closed, the bad guys will pay more attention to routing.
The worst thing about spam is not spam per se, it's that it's created a profit motive for hacking.
The spammers and the extortionists are paying the hackers, well, this is already in their tool kit, they will dust it off.
Anyone not using end-to-end encrypt will be susceptible to eavesdropping or packet modification, everyone will be vulnerable to highly tunable denial of service.
You get more from others on what to do to fix this? We have to have digital signatures, no other technology will let us let people -- on an arbitrary points, in the network, verify a routing advertisement without knowing some secret in that in a way that doesn't scale.
We need certificates of some form to bind resources but AS numbers and prefix is to the legitimate owner and particularly to the public key so someone can verify it.
A lot of details need to be worked out, including exactly how we want to do this over the wire, I have my own preferences, I won't go into them now but all possible solutions rest on these two points, and is also very very clear to me and I suspect to most people in this room, that the certificate infrastructure for this has to rely on the RIRs because it's the RIRs who are issuing the prefixes and issuing the AS numbers. Thanks.
MR. BUSH: Thanks Steve. Okay. The quicksand we're in, the quality of WHOIS data is, to be polite, unknown. The quality of the RIR data, the routing registries is in a similar really brilliant state, okay.
There is no formal means of verifying if a new customer, if I'm an ISP, and you know, Axel comes to me and says, hey, here's my prefix route, I have no way of formally rigorously testing that, I can go to the WHOIS data but since the WHOIS data is kind of weak, I'm up creak, okay.
There is -- and the routers, as Steve says, have no formal means of verifying routing announcements, okay.
The issue, as Steve has pointed out, is not router security, let's not worry about how they're tracked but routing, the protocol attack -- infrastructure, creation, storing and moving it, okay.
What is a PKI. For us, in our context, it's a database of the identity certificates for the routing registries, for the ISPs, for the end sites, the resource certificates for the IP allocations, for ASN allocations and rights to route, and rights to route are when Axel came to me and said, route my prefix, he has to put something in the routing infrastructure that says Randy's AS 3130 should be able to announce my prefix, 66642/16. Okay.
So, okay, what we need is a formal verifiable system that allows me to verify that a customer has actually been allocated a resource they're asking me to route and that could be a manual process for the moment, this is kind of in time, how usage will progress.
Next is, you know, hey, I'm debugging, somebody says a prefix has been hijacked, can I verify in a formal fashion which cryptographically signed that they do or do not really own that prefix.
How about when I'm building route filters in my routers to filter announcements from my neighbors, this isn't a change to secure BGP, this is just building the route filters we have today, I have the ability to validate that data formally.
And lastly, in the long terms, as Steve says, allow routers to formally verify BGP announcements so that actually the routing itself is formally signed.
Okay, the underlined architecture that I, as an ISP, would like to see is to have one implementation underneath which is used by all registries and by all ISP who want to run this kind of infrastructure.
The RIRs have to each be allowed to have their own business processes, user -- et cetera as will be the ISPs run this, the way things happening now are different than they happen in APNIC or different than they happen in LAPNIC, et cetera. Okay.
And it allows ISP to build our own processes on top of the base tool set. The applications we want to handle are the ownership of ASs and IP space and certified transactions with the RIR.
In other words, this is the business part of it, how it's -- to be able to send a formal request to the RIR, to get an allocation, the RIR knows that is from me because it's a certified request, et cetera, et cetera and the same for billing, the same for DNS Delegation, et cetera. Okay.
I want to operate across RIRs, I don't want to have a problem when the prefix I got from ARIN, I want to route it over an AS I got from RIPE.
I want to be able to take and mix and match these things and I want to be able to mix and match normal allocations with experimental, with legacy, et cetera, okay.
Some ISPs are so big that they have spent tenths of thousands of dollars on getting formal certification structures already and they have large security departments and formal ways of handling certificates already.
They are not -- you don't want to place, you know, my friend 702 in the position of going upstairs to some telco minded -- security people and saying, by the way, for my routing, you're going to have to change the way we do things.
And our certificate's useless, we're going to need new private keys, et cetera, et cetera. So, I should be able to come into the system and use the private public key pair I got from Verizon or whoever, to enter this game, okay. That doesn't mean that we're going to dynamically check to the Verizon registry for identity because it turns out that that is, they charge you 25 cents every time you want to know. Okay. Most members are not going to want to do this.
Most members are going to go to a web site at the registry, are going to say, "give me a certificate", they're going to install that certificate in the web browser, and it's just all going to magically work for them because they're just, they don't have funny bell heads with funny security policies in the company. Some of us aren't so lucky.
There are some key aggregation things, I want to be able to de-aggregate a resource and route the parts independently. So that means, you know, I've got a 16 and I want to route the two 17 separately. I want to de-aggregate a resource and transfer part of it to a third party. Geoff Huston has done a lot to try to get in our minds, but as the IP-4 space gets used, that there's going to be an active market in v4 address space, so I don't want to speak to whether or not that should happen business and culturally, but if it does, we need to be able to handle it technically.
I want to be able to acquire a resource allocated to an ARIN member while I'm an APNIC member. I want to be able to aggregate resources that were obtained separately. If I get two /9s, I want to be able to pull them together into a /8. Those could have come from two different RIRs.
The RIRs identities are the trust anchors for the system. In other words, when an end site has an allocation, that allocation was signed and given to them by an ISP that was signed and given to them by an upstream ISP, it was signed and allocated from them -- to them by an RIR. Plunk, we've reached the top of the tree, maybe. There could be a further top of the tree, the NRO or the IANA. This is a policy in business decision that RIRs have to make, okay.
Alternatively, they could have generated their own, et cetera. But the tough issues, by the way, are key roll over and levitation, what happens if ARIN's key is compromised. So there's some business and technical policy and process that has to be wrapped around that, and there are some alternatives. Okay.
Similarly the ISPs and the end sites, they have certs that are generated by the RIRs. Note that these only need to be reproducible. They're not formal identities, they're just used in business transactions, and to create, allocate -- resource allocation CERTS. They could be started with the keys from an external CERT. ISPs might use an ARIN identity for an APNIC allocation or business transaction, so ISPs that span the globe really want to do that, okay.
The mess kind of looks like this, there's the database, RIRs, do a CERT, you know, do the CERT for the ISP, ISP for downstream, downstream to the end site, each one putting the CERTs in for the things they allocate, so when the RIR allocates an address space to me, they put that CERT for the allocation into the database.
Let's call it an API for the management of the public key infrastructure database. It has to be across RIRs for dealing with multiple pieces of the repository. The entire repository just isn't going to be in one computer in Fort Mead, Maryland, okay. It describes interfaces and the transactions for publishing, validating in certificates, et cetera, note that the PKI is self-authenticating, in other words the CERTs form a formally verifiable hierarchy, or grass. It can be traversed and tested. You don't have to take and get a CD-ROM with the stuff on it that's signed by somebody and handed to you with a secret handshake, okay. So there's no need for transport security. The data play is just going to talk about the APNIC trial code, which has some more work on it. We've been converging on requirements. Geoff and George have a good sketch of the API, so there's the questions of how we're actually going to go forward as a community, getting common code. The coordination of updates in central repository is not feasible, so we're going to R-sync the pieces, et cetera.
This is the wrong presentation. I'd like to stop here. And I do wish to thank Geoff, George, APNIC for taking long lead on this, and so why don't we hear from Geoff next?
MR. HUSTON: So, if you've got a router handy, or you can get access to one, if you want to play the game of trying to find out who's lying right now, go and look for 184.108.40.206/8. It appears for about a minute or two, and then it disappears for 10, and then appears for about a minute or two, and it's been doing that for about a year and a half. No one actually owns 220.127.116.11/8, do they? Anyone here? You don't. It's a /8, it's a /8, we're actually doing allocations from. So why are you seeing it in the routing table? It's not real. It's a base for spam launching.
If you have a look at the lightning torques at NANOG 35, there's some brilliant piece of detective work by Nick Feemster in matching spam sourced from the vacant addresses in 61/8 to the appearance of the router. It's not a bogon in the sense of IANA are still holding it, therefore we can't route it. It's out there, but they're doing a massive aggregate. It's lying in the routing system.
So what's the problem here? As Steve said, there are many ways to lie in routing. And what really happens out there is that our current mechanisms of bogon filters and routing policy databases and IRRs are about the best example I could possibly give you of what Bruce Shania describes as a security pantomime. It's the appearance of trying to do something without the substance. It might make you feel good, but it doesn't actually get close to what the problem is. They're not robust forms of defense.
So, what we're trying to understand here in APNIC is our business's uniqueness and validity. How can we help you? Because quite frankly, if you're in the ISP world and you get routing requests, "Please route this address," you have to do data mining across WHOIS data. It's a very fuzzy match. The better you are at it, the more expensive you are as an employee. The better you are at it, the more it costs your business to have you doing this. Now, if you're getting, oh, about two bucks a month margin on that particular customer, how many hundreds of dollars are you going to spend to validate that routing request? The pragmatic answer is that as an industry, we're not equipped to do that kind of expensive data mining. So these very basic questions need to be answered in a manner that is better than what we're currently doing. Is 61/8 valid? No. Who injected this prefix? Go look. Did they have the credentials? Evidently not. And that's the kinds of questions you need to ask every time. And sometimes they're remarkably difficult questions to answer just by data mining.
So the motivation we had in APNIC in looking at this is can we provide you, the industry, with tools and techniques that would allow these questions to be answered automatically? Request the person who's asking you to route this to sign it digitally, and then validate that signature against resource holdings.
So what would be really cool is, as we've heard already, a public key infrastructure that is actually designed to talk about assertions, about resources and their use. You know, is this address real? Can it be routed? Is it actually out there? Is the person claiming to originate that, the origin AS, authentic, or is that too a lie? And most importantly, it might be my address, and you might have a good AS, but I have never told you to route it. So can you actually uncover that explicit authority from the address to the AS to actually punch it into the routing system? It would be really cool if we could do this through digital certificates without spending an enormous amount of time on fuzzy matching in WHOIS data mining. And if you've ever looked hard at the accuracy and validity of WHOIS information, you'll appreciate that that is a world away from where we are today. If we could answer those basic questions with the PKI systems, we'd be miles ahead.
The ICS has done some good work here in laying down some standard infrastructure, they're talking about a different kind of use for PKIs. Identity certificates were normally all about who I am. I bring my 100 points to some authority, passports, bills, or whatever, and they say, "Yeah, Geoff has presented this, it's really Geoff, we're going to sign his public key to say that's Geoff." This is not a case of talking about who.
The X.509 extensions are actually trying to define a different certificate, a certificate that talks about resources. And what it allows you to do is to hang an extension into that certificate that actually lists IP address box and AS numbers. And what we're talking about now is authorization of the subject to actually say, "I am the unique current holder of these resources." And whenever I sign something with my private key, the public key in that certificate can validate that assertion. So it's a critical extinction in PKI turns, and I think Steve will talk about this. The validation of anything I do must include a validation that the IP addresses I talk about are contained within that resource blocking the certificate.
So, in APNIC, we've been talking about this for, ooh, about eight years, and spent a lot of time looking at various ways of doing this. Over the last year, it's crystallized into a trial. The trial is actually all about three things I think that are useful. Trying to understand if PKI systems and certificates in particular, this kind of format, are the right thing. Is this a right use of that kind of technology? Is it a good fit? And the other thing is, can it be useful?
So, in terms of sort of looking at this, the best thing we thought to do was to actually start generating these certificates. So, this is the kind of thing we are talking about, and there a few features of this certificate that I'd actually like to point out. This is a standard certificate, version 3, it has a serial number, it keeps on rising, it has a signature algorithms, which these days is SHA 1 and should be actually SHA 256, yes, that's fine. The issuer would have actually said, "This is the CA trial." Why? Because down at the bottom, you'll find that the certificate authority bit is on. People can then generate subordinate certificates from this, so if you go back and say, "Well, hang on a second, what was this about?" If you look at the issuer, it's APNIC trial, not APNIC, the registry. It's trying to make it very clear.
Validity dates, we were using explicit validity dates in this trial based against your membership periods, in other words, based against our view of the holding of that resource as it sits within the membership system of APNIC. So this is a trial about member services in this instance.
The bit that I want to highlight however is the subject name. We're not saying you are who you claim to be. What we're actually saying here is this is all about resources, and the holder of the private key is the current controller of those resources. The subject name is actually blurred out. And what we're providing instead is basically a hex digit field. In this case, you know, FC00- whatever. We'll be using, and have used in the trial, this kind of anonymized subject name because it's not really about who you are, it's the resources that you currently control. And of course public key info.
There are some extensions, the extensions we're talking about are over on the right, the IP address and AS numbers in a block. These are your current holdings as current member database. The CA bit is on. That means that if you're a local registry and you do allocations further down, you can issue the same kinds of certificates yourself. So this is a system that is transitive in that respect.
It's critical, the digital signature is there, the key set certificates, they are real signers, and so on. There will be a certificate practice statement referenced by an OID. This is an evolving system, and we are looking at a number of extensions to the current trial, and those are grayed out in the middle. Maybe you would actually like to say, "Look, it's really Geoff. You may have given me FC00-whatever, but it's really Geoff." We're looking at doing the subject alt-name field to actually identify who you claim to be. It's an alt- name because it's not something that we in particular are saying you are really that entity, but if you wish to add a field in there, the alt- name would be the place.
In looking at how validation would work, one model is to put everything in one massive repository, in which case, you wouldn't need to actually reference where the certificates are being held. In looking at also with these kinds of certificates, you can introduce pointers to repositories, and we're looking at in particular the authority information access location, the subject information access location, and the CRL distribution points to allow someone who wants to operate their certificates in their repository to be linked into the system.
All of that is signed with, your public key info, signed by the APNIC key. So this is a certificate signed by APNIC.
What are we certifying? I think the blandest statements, or the most crisp statement I can do is, APNIC is certifying that the certificate subject who's public key is contained in the certificate - that's all we're saying - whoever owns that matching private key is the current controller of the set of IP and AS resources that are listed in that certificate extension. So we're not saying who you are, or that your intentions, good or evil, whatever they may be, we're simply saying that whoever owns that private key is the current holder of those resources.
What can you do? You can start talking to other folks saying, "If I sign this routing request, it's really me and it really refers to addresses that I control." So you can sign routing authorities, or you can even submit stuff into Internet routing registries with your private key signature on this, sign it. The recipient can validate. All of a sudden, you're talking about validatable trust here. The matching certificate's public key works and you can then validate this. Or, you could actually sign routing information that could be propagated in a routing protocol, and if you've looked at things like SBGP, SOBGP, PSVGP and so on, there are various proposals flying around who actually use this as part of the protocol payload carried around in routing. And of course given that sort of structure of the hierarchy of delegation, and there are LIRs that do further allocations, you can issue signed certificates, subordinate certificates, for further delegation.
So the trial, we're going to, in fact we have issued a dummy, 3779 compliance certificates that reflect all of the APNIC membership holdings so that there's one certificate per member actually has been generated. We are now looking at the policy and technical infrastructure to support this. In particular, we're looking at the CPS, the certification practice statement, trying to say right up front that even though the CA bit is set on, even though you can issue subordinate certificates, if you wish to use subordinate certificates for other than allocated resources, the CPS says don't trust them. Don't look at them, they make no sense. The practice statement says this is all about IP resources. But looking at the mechanisms for the certificate repository and how to gather certificates together to validate them, and also the issues around revocation, and also now, working on developing open source tools, and they really open source, about the kinds of things you need to do in order to work with certificates.
Currant status, you'll actually find that the URL down there is trial certificate repository. This is the more unique form of certificate repository. You'll also look hard and you'll find the private keys in there as well. Why? This is not normal practice, but if you want to play with these, then there's enough information to play to your heart's content. If you try and use them in any other context, beware; they're not intended for that kind of use, but they are intended to help you and the open source community look at these and start developing tools and techniques. So you'll find in that repository a key pair generation, all of the holdings, and even an explicit re-issuance, so there is a revocation list as well.
The tools that we're working on finally, there is a fair deal of tool work, because quite frankly, in this kind of area, we haven't had a lot of experiences in industry in dealing with resource certificates, so we are looking at generating and actually creating some open source tools to really strap this up. If you want to validate certificates and you want to do it quickly, you may need most of the certificates nearby. They're not actually very big, but you're going to have to synchronize with external repositories. So then that tool that wanders and validates will be looking at open source tools to assist.
So, the synchronize repository tools, the tools around validating certificates or routing authorities or of assigned objects. How to generate a routing request or a routing authority? Tools to let you do that in what's called private -- generate the block. How to generate subordinate certificates and actually do, if you will, sign certified suballocations? And of course, the issue around revocation of these subordinate certificates and, of course, otherwise how to update certificate revocation list and how to manage them.
Those tools are being developed now. Now, the current time line for this work is we would like to get most of these tools in place in the trial across this calendar year. So, APNIC is certainly well under way to try and push this forward, if you will, as a real trial that you can actually use and work with across this year. And that's about what we're up to. Thank you.
MR. KENT: Well, I have more slides than is appropriate for this time but the good news is that some of the things I was going to talk about have been discussed by previous speakers. Why PKI? If you look at the various proposals that Geoff Huston just mentioned for improving routing security, most of them rely on public key infrastructure at some level to attest to holdings of the resources that we've been talking about; PKI is a natural way to deal with this. And I'll go into a few more details compared to the previous speakers on what this might look like.
And the things that we can do with are the things that have been mentioned previously and that is we can provide an infrastructure that will allow ISPs to be able to detect bogus route origination and if we get fancier about it, in fact bogus half information, at least on a static basis and also help avoid social engineering attacks where an ISP is easily convinced that they should be originating route for someone who in fact does not hold the prefix in question.
In terms of principles, again, previous speakers have talked about these things. I think we should be doing this in a standard base fashion which translates in X.5 or 9 certificates or the peak X profile of the IETF and RC37-79 extensions which are ways of specifically listing ranges of address space and AS numbers.
A goal here is to not created a trusted third party kind of PKI, to have the entities that allocate addresses and AS numbers and suballocate them take on responsibility as certification authorities. So that we're not bringing anybody else new into the party, we're relying on people who do the job now to do this extra step in doing the job but not trying to bring in someone new to do this.
And we have to deal with all the kinds of allocation practices and suballocation that takes place. Portable allocations, form registries, multi-homed subscribers, subscribers moving from an ISP from which they have address space and bring that address space with them, legacy address allocations, transfers among registries, et cetera.
There are multiple parts to the PKI certificate and CRL portion form or basis for it. The repository portion which we've just been talking about and also the notion of signed objects that allow participants in the PKI to make what we can consider the attestations about resource holdings, the simplest form of this being authorizing an ISP to originate routes for prefixes that you hold or to advertise a route not just a prefix but actually a path if you're an ISP.
What would we do with certificates in this kind of an environment? Well, the goal is to issue certificates that attest to the resource holdings and these would be done by registries as essentially the top tier by ISPs and even, in some cases, by subscribers.
Because these resources are done in a simple hierarchic fashion today, the notion is that we should be able to parallel this in PKI. That forms the simplest kind of PKI and avoids a lot of complexity that otherwise would show up. So, we get this kind of address allocation hierarchy and this kind of AS number assignment hierarchy and the idea is to be able to have a public key infrastructure that exactly parallels these, not to deviate from that.
So, if we assume for a moment that we have a route for the system and admittedly as Randy mentioned earlier, there are questions about whether or not we absolutely have to have a route and, if so, you know, get to place in the bottle and decide who gets to be the route.
But assuming we do, IANA does form the top tier in the allocation hierarchy and so you could imagine the allocations to the RIRs themselves representing their holdings. Then each RIR would issue certificates as appropriate to national or local registries if applicable and to ISPs and to subscribers with portable address allocation.
The ISPs would in turn issue certificates to downstream providers if they've done that in terms of address suballocation and to subscribers if the subscribers are multi-homed subscribers.
A subscriber who starts off getting an address allocation from an ISP and has only that ISP as its gateway to the rest of the Internet doesn't really need to participate in the PKI because they are invisible to the rest of the Internet. They're just one portion of the address base held by their ISP and until they do something different, they don't have to do anything as part of the PKI.
The organizations issue certificates that match the address base and AS number allocation records in their database; that's all you can ask for them to do. All of these resource holder certificates are certification authority certificates and there's a reason for that that I'll get to in a couple of minutes.
The proposed PKI uses the extensions, the X.509 extensions from our C37-79 that I mentioned earlier and the certificate path represents suballocations. So, they're directly traceful in that fashion.
So, if we pick APNIC and Geoff and his colleagues have been up front with this, we could imagine looking at it in a little more detail. So, starting from a route down to the five RIRs and then under APNIC, looking at five registries and then if we pick one of, you know, those portions of the path and zoomed in on a little bit, we go from an RIR possibly to a national registry and from the national registry to ISPs or to subscribers from the ISP in the middle down to another level of ISP, et cetera.
So, a kind of path starting here and working your way down but all these other paths are also legitimate things that could appear in the PKI to reflect how allocations and suballocations take place.
If we look inside the certificates, certificates form a chain. That's how we do certificate validation. And so, we would start, let's say, at the root which owns everything in terms of address base and AS numbers and then going down to APNIC, we'd see that the issuer who would hear the route, whatever that name is and the subject would be APNIC and I have shown a subset of address blocks allocated to them and a few AS numbers. In fact, when Geoff and his colleagues produce thereon a certificate based on what their holdings are, it's in the neighborhood of 8,000 bytes which is a pretty big certificate. But when we checked it later, we discovered that there were a few little bugs that would allow it to be compressed some more using the RC37-79 detail. So, it'll shrink a little bit.
Then, under APNIC going down to JPNIC notice, a subset in the addresses are allocated and a subset of the AS numbers and then if JPNIC issues a certificate to some ISP, a further subnetting, a further AS number subnetting and all the way down to a subscriber.
So, that's reflective -- representative of a simple case of this kind of allocation.
As Geoff mentioned, while we need to put names on certificate, that's part of the format, it's not clear that we want to put meaningful names in most of the certificates.
At the top level for the RIRs and maybe national, local registries, it makes sense to do this but once you get further down in the hierarchy, it's better, from the perspective of this PKI to not put in a meaningful name into the certificate. It discourages their use for other purposes and reduces the potential liability for the CAs in this environment who are just in the business of using their existing database records. So, they shouldn't turn -- shouldn't be assuming any additional liability in the course of doing this.
So, for an RIR, you know, country, Australia organization, APNIC organization or unit resource registry, CA might be a reasonable name for a production version of the system that APNIC now has on a trial basis. Underneath that, for instance, for JPNIC, country Japan, organization JPNIC, similar kind of organizational unit name. But when you get to the next level in the hierarchy, we expect that you could have a non-meaningful name of the sort that Geoff had mentioned earlier in terms of a X number.
If you've got a certificate, a question naturally arises: If I get additional resources, what do I do? And the answer is: Whatever you'd like. You could have those resources added to your existing certificate, no need to change the name, no need to change the public key in the certificate. A new serial number will be assigned because we always do that with a new certificate and we could update the validity if that was appropriate based on your relationship with the issuer of the certificate.
Alternatively, you might decide you want to get completely new certificate just with these resources because your business practices, are you going to use the new allocations, make that more appropriate? Either way works fine in a system like this.
Also, if you want AS numbers in certificates all by themselves separate from your address allocations, sure. That works too. You can consolidate things or you can leave them separate. It's just a question of what makes sense in your environment but it will all work in the end.
You also have to accommodate in a system like this allocations from multiple sources, getting AS numbers from one place and address base from another or perhaps more commonly address space from two different places over time. You have to be able to do it. It's possible. There are several choices on how you can accommodate it.
One thing you can choose to do is once you've got a certificate from one provider is to go to another provider and say, "When I get a new resource allocation from you, instead of generating this random looking number to put in there, I want to re- use the number I have in the other certificate". And that can be helpful for a technical detail relating to PKI design that allows the result to be looked at in a more uniform fashion. You don't have to do this. It's just an option.
And so, this is the kind of diagram that would show up here. Let's say that this subscriber has an allocation from a regional registry as well as from an ISP, they can appear inside this dotted box to be the same entity because they are the same entity. But they have to have two different CA certificates because of the subsetting property for the allocation system that allows automated verification to take place.
They can then issue what I'll talk about in a moment which are shadow certificates. These are the first end-entity certificates as opposed to CA certificates in the system and from that, sign what are the labeled route origination authorizations, either separate ones or a combined one, if you want to glue it all together.
So, route origination security is one of the first and easiest things to make use of here in support of improving route filter generation. We're talking about creating signed objects. You could name them anything you want. I call them ROAs because that was the acronym -- that sounds like a bird, probably, from New Zealand or Australia.
If you want, you can have one ROA that combines all of your allocations if you have them from multiple sources and you can then indicate which ISP or ISPs are authorized to advertise all of them or, if it makes sense in your environment, you can create separate ROAs and a motivation for doing this is to allocate different chunks of your address based to be advertised by different ISPs.
So, any kind of mix and match there that you want to do works. This is a rough format for this kind of thing. A list of one or more prefixes up front, a list of one or more AS numbers identifying the ISPs that you're authorizing to originate these, a validity in a -- because experience shows if you're going to sign something, putting a validity in a -- in it is a good idea, and then a signature list and inside that list, if it's more than one, what you have is a sequence of pairs of things which are signatures and you might have to have multiple signatures because you might have multiple certificates representing the different sources of allocations, and then, a back pointer to help on this issue of: "Okay, which certificate is the right one to use to verify this signature?" So, that's the rough notion for this.
We've talked about how to do route filter generation easy. The approach here is you go to repository system, one or more repositories, download either all the stuff that changed from the last time you went there and asked the question or just download everything. Certificate CRLs and these ROAs, verify the cert paths, use those shadow certificates that are added in there at the last stage to verify the ROAs themselves and then, from that, you can construct a table, for instance, that for each AS, what are the prefixes it has been authorized to originate or the other way around.
You could also do a variant on this if you're a subscriber going up to an ISP and saying, "Please, advertise my prefix". You would go ahead and send the ROA in some locally secured fashion, locally good enough for the ISP to show that you are in fact authorizing them to advertise this prefix and that you are the holder of the prefix in question. The ISP can even automate that process and verify that, yes, you're the legitimate resource holder and therefore, it's reasonable if you are their customer -- if you are a customer of theirs to advertise this on their behalf.
You could do something more ambitious and Geoff Huston, in fact, suggested this at meetings at APNIC just last month which is create fancier signed objects to authorize a neighbor, an ISP neighbor, to advertise a route, not just to originate a route. And you put in the AS number of who you're authorizing. You put in your AS number. You put in the prefixes and you allow these signed objects to be nested. And, in that fashion, you can pass them around or put them in a repository and create a static representation of the kind of information one would use for fancier kinds of route filtering.
So, this is the kind of technology that in some level of detail we're talking about creating. It has tremendous promise both for near term improvements in terms of route filtering and convincing ISPs in orderly fashion to legitimately originate routes for you. It also provides the basis for fancier, more dynamic sorts of things through modifications to routers and BGP in the future.
And so, I just ask you to contemplate this sort of thing over lunch. That's my Ninjia. Thank you.
MR. CURRAN: I'm John Curran, I'm the chairman of ARIN and my purpose for being up here on this panel is very simple. You've had a number of folks talk about possibilities for using PKI to better secure the chain of allocation and potentially there are announcements in the routing infrastructure.
All of these are functions that certainly, if you take a look, the function of better securing the chain of allocation information is something that's within the scope of ARIN. And what I mean by that is we presently provide these allocations to people and the infrastructure we use to do it has some degree of security or insecurity and there's nothing wrong with looking at alternatives to tighten that up if that's desired.
The real challenge is that it's hard to know if it's desired. All the people on the panel here think that it would add value. We've seen other RIR go through some preliminary efforts to forge ahead in this area but, at the end of the day, the ARIN board is going to have to know whether or not we should invest ARIN's resources in securing the allocation infrastructure and providing effectively information that's of higher value than just performing the allocation, information that would let you actually perform some verification and improve the quality of the data that Randy was talking about on his first slide.
So, my request to everyone is: We've seen a lot of slides that have a lot of technology regarding encryption and security and PKI but I don't know whether or not people think that this is a place where ARIN should put resources and that's going to have to be - as we move forward in the discussion today - that's going to be an important part because we don't want to invest in something if it's not valued. Likewise, we don't want to turn down an opportunity if this is important to some of the members. So, that's my speech. Thank you.
MR. PLZAK: I guess I'll say the floor is open and I'll take the back microphone. Go ahead.
MR. WEILER: Thank you, gentlemen. Sam Weiler, Sparta.
First, I wanted to thank you gentlemen and APNIC for working on this, particularly on the cross-registry bits and on using certificates who don't have identities in them.
However, as I listened to the earlier presentations, particularly Randy's, I've heard the first problem that he's stated as an ISP wanting to verify that a particular customer is entitled to advertising address block.
And if you look at that first stated problem in isolation, along with Dr. Bellovin's analysis which I didn't hear him mention any threats against WHOIS look ups. No one's attempted to -- WHOIS data, at least, I didn't hear him say that.
One might reasonably ask why is doing all this PKI stuff going to help? How is it going to improve the WHOIS data? Even if we were able to improve the underlying data, why would you need the PKI stuff? And even, why isn't this worse? Because once you start doing automated things for cartography, you start introducing extra breakage.
So, I would encourage the panel to explain, again, why is this better? How does it improve the data? Why do you need the PKI stuff? And I would encourage the Chair in asking the room to ask exactly what bits membership wants resources spent on it, whether that's improving the underlying data or doing the encrypting, as a separate question.
MR. BUSH: In the ARIN database, underneath all this, the data of what ARIN has actually allocated way back is stuck in Oracle is actually pretty good. The WHOIS data by the time you get out to the front and the RIR data are weak. This obviates both of them in the long run. It replaces them, period. You may want auxiliary WHOIS data or who -- what's the postal address of the person -- the entity to whom this has been allocated. Okay? And that can be signed and certified with this.
But what this gives you is the same data structure in a verifiable certified fashion. And I think that's a distinct improvement organizational for the manual procedures.
And I've lost the -- I haven't answered the second half of your question. I forgot it, Sam. I'm sorry.
MR. WEILER: That's okay. I had trouble keeping track of it myself. So, the first question was: How do you think this proposal will improve the data. And then, why do we need the crypto once we've improved the data? We haven't heard that WHOIS look-ups are threatened.
MR. BUSH: Because why should I trust it? How do I know it? How do I know you have -- somebody hasn't put false data in the WHOIS? Oh, you mean that you drew this data in, it's going to require some sort of signature and -- oops! Aren't just following the same trails from a different entry point? This is an invitation.
MR. KENT: Sam, you're right, that crypto is low replacement for correct data in the first place. Getting that data correct is absolutely prerequisite for -- you know, you don't want to issue the certificates to the wrong parties. This is an issue that needs to be worked for other reasons and it is being worked. We need to clean it up.
As for why this is better than WHOIS, WHOIS -- you know, really improve through his data, even populated in the routing registry helps if you are the first hop. It doesn't help if you're four hops away. In the example I gave where I said, you know, your immediate neighbors are being lied to by someone three hops upstream from them. You have no idea what connectivity is supposed to be. That's what this is supposed to solve.
MR. HUSTON: But the take away point is that the first problem Randy posed, you know, the ISP -- verifying the origination in the first place --
MR. KENT: That's already a problem we -- the RIRs have already tightened up their procedures for change of registration because of paper base highjacking of prefixes and domain names. This is not a new problem.
MR. HUSTON: Sam, there's another part to it. Last year, this kind of question was asked at a routing security workshop that department of homeland security sponsored and the folks at ARIN did an analysis and came back and the -- and I'm just going to paraphrase it. But the answer is that the vast majority of the data in WHOIS database of course is not put there by the registries. It is put there by the suballocators and the suballocators, in many cases, don't have a strong incentive to maintain the data accurately.
So, this system creates such an incentive in terms of facilitating the routing, that is if people start demanding that certificates be in place and ROAs be signed in order to accept route origination information, it creates that motivation further down the tree which previously has not existed.
So, there is a rational basis for saying, "Yes, this can be improved" and it is not primarily the responsibility of the registries to do that improvement however. There's a distinction.
MR. CURRAN: Okay. Should one people -- we are going to go a little late for lunch but not too far, if you're going to speak on this, please find a microphone. Centre microphone.
SPEAKER: I support this work. I think it's very important for us to move forward. I'd like to see ARIN commit financial resources as well as people resources to supporting APNIC work as well as specifically working on the tools and the use cases for ISP because I think that is where we must spend the majority of our time to make this deployable and operationally feasible.
MR. CURRAN: Okay, far microphone?
MS. MURPHY: I actually have a couple of different questions. I'll ask one and then circle around them.
MR. CURRAN: Name and facility you are, please?
MS. MURPHY: Sandra Murphy, Sparta. I was getting there.
I'd like to point out that Randy's presentation said that a central repository was not operationally feasible and Steve Kent spoke a lot about a repository because these items are digitally signed, they maintain their assurance separate from the transport mechanism and Randy said from their source.
So, we have other communication models available to us. I was wondering if the panel members would like to discuss their difference of opinion there.
MR. HUSTON: This has certainly been a topic that we've looked at in the context of the APNIC trial. And the original model that we did have was this -- if I could describe it as mothership repository because no matter where the certificate is, its assurance is part of the validation chain. But actually collecting the certificates to do this is the issue.
We have looked at the fields that have been included in the version 3 of the X.509 certificate structure. The subject of authority information access fails --
MS. MURPHY: M'hm.
MR. HUSTON: -- and still undecided as to, you know, precisely what we would do with them. But it seems that if someone there said, "I want to operate my own repository", then the ability to point to that repository inside those fields of the certificate allows us the flexibility to have more than one repository as the prime resource --
MS. MURPHY: M'hm.
MR. HUSTON: -- while still having a plain way of collecting the certificates together in order to do reasonably efficient validation.
MS. MURPHY: And what you just suggested would be a hierarchy of repositories?
MR. HUSTON: The APNIC trial is certainly looking at three repositories in a hierarchy, certificates that APNIC issue themselves.
MS. MURPHY: M'hm.
MR. HUSTON: Second, certificates that are lodged with APNIC are verified at the point of lodgment and cycled through continuously refreshed on verification.
MS. MURPHY: M'hm.
MR. HUSTON: And thirdly, a repository where we actually work from the top to the bottom collecting the certificates for the chain and validating names. So, we would certainly see a three level hierarchy and the repository would be operating in this trial.
MS. MURPHY: If you had the pointers though to other repositories, that would naturally create kind of a higher hierarchy --
MR. HUSTON: The pointers throughout the repositories would assist us in collecting all of the certificates into the level three.
MS. MURPHY: Okay. All right.
MR. CURRAN: Any other people?
MR. BUSH: Two things that you forgot to mention, Geoff that your description of the certificates actually had those pointers and, uh -- I think it's important that we note that we shouldn't disable this new design whether it's actually there in the first trials, there in the second year and there in the tenth year in other matter. When we did the IRR originally 10 years ago, we were worried that because we allowed it to be -- have multiple of them, there'd be 10,000 of them and every whinny in the world would run one. There ended up to be about 30.
So, the stuff is difficult. There's no real silver badges given out for running one. So, you know, those people that need to should be able to. Steve, go ahead.
MR. KENT: Yes, just a quick observation. While we've emphasized the fact that the signed data is temper evidence so to speak, the point is that if somebody does stop on it, then the data is not there -- or there's only an old copy because somebody didn't want you to see the latest certificate verification list.
So, having a smaller number of repositories with access controls in support of preventing these kinds of denial of service attacks is one of the things that motivates me to say we should have a system that's fairly, you know, well coordinated and I look at the WHOIS model in terms of the level of distribution of the data as a good example of it.
So, if I -- you know, have my -- that's sort of the thing I'd like to do.
MR. CURRAN: Okay, moving on to -- Mark?
MR. KOSTERS: Okay, Mark Kosters, VeriSign and also AC member, like to say a couple of things, one is that we're king of already -- kind of hitting the edge to this with policy proposal 2006-3, that Sandy is putting together on trying to do validation of routes.
But my bigger question and I'd like to pair it with -- and Andrew Dul just talked about in terms of it would be really nice to get ARIN involved in this and how can we, as members, say, ARIN, we want you to get involved and we want you to be a part of this test, but in making this happen because this has been going on for a couple of years now.
So, it would be nice to start seeing some real activity from the -- and leadership from the ARIN registry as well.
My second question is since Steve Kent is up here, I'm just going to throw this out, there was this -- for a while between secure BGP and secure origin BGP, does this mean that secure BGP has one -- or if BGP is now that?
MR. BUSH: If we all insert it here, maybe it will be so.
This is neutral. This proposal is neutral to secure BGP, SOBGP, PGP, BGP and your mother is BGP. You'll need this for all of them.
MR. KOSTERS: You're going to need -- you're going to need at least a -- there's a commonality, I'm not saying that everything that Steve has in his presentation actually is going to be in the final tapestry of this, there's going to be the final --
MR. HUSTON: Allow me to make one comment, in the APNIC context, we have been careful to consult with the authors of SPGP and SOBGP to make sure that when we're designing this trial, we weren't cutting out anything that they regarded as essential in their models that they're looking at.
So, we believe at this point, as Randy said, it is neutral to these and could be used by any of them.
MR. KOSTERS: Okay, so, actually, could I have an answer for the first question, how can we have ARIN actually be a part of this and what will it take to make it go?
MR. BUSH: Part is a difficult thing, I think Geoff, George and APNIC have done an excellent job, kicking it off and spend a lot of effort on a very minimalist but sufficient model and I do not really believe in design by committee.
I think that ARIN support in user requirements in making sure ARIN and any other registries should try to understand -- and is actively doing some by the way, there have been inter-registry meetings on this, we had one in Perth last month and we're all hanging out in the corridors here together.
But I'm making sure that the inter-registry issues and the different process models of each of the registries fit over this so the two -- develops meets everybody's models.
I'm trying to speak, of course, from the ISP perspective and seeing that the ISPs needs are met as -- well, as I can do that, et cetera.
But I don't think we're going to see 40 people on a design committee and I don't think we're going to see 10 people riding the validation code and side open SLL.
MR. KOSTERS: I'm not -- actually implying that at all, I'm asking about, okay, when is ARIN actually going to have some sort of service for someone to play with, where is -- how far are they coming along, where are they at?
Doing just requirements is fine but you're not an ARIN employee, Randy, so what does it take to make this happen, how --
MR. CURRAN: Okay, that one is mine to answer. This Wednesday, we're going to have a members meeting where we talk about how ARIN is doing, you know, we'll talk about the organization, direction, coming year, budget.
At that time, it would be great for people to say ARIN should invest resources in this, if that's what they believe.
Okay, so certainly there's a cost involved for this. All right, folks, I am going to close the microphones for new additions, this is with respect to lunch.
And now, coming back here, middle microphone back, Bill.
MR. MANNING: Bill Manning, EP Net, ARIN board of trustees, and general -- When I wear my little tiny ISP hat, I go back and I read a white paper that came out that said there were several -- the rank order to set up threats, routing security was top or near the top, there was another one which was DNS integrity.
And I'm looking at two development communities with two distinctively different sets of tools and I'm going to be asked to run two different key managements regimes to support DNS security and routing security, I don't want to be that, is there a way that we can harmonize these two different regimes because if we can't, the likelihood of adoptions is going to be pretty high or pretty low, actually.
I'm going to reject a lot of this if I -- if it's too high to do.
MR. BUSH: I think this stuff is actually fairly well understood, a fairly narrow design and actually a good -- a deployment model that actually can roll out, et cetera.
So, I'm less worried about it than, you know, the 12 year old DNS set redesigned effort.
The key management is -- you know, what can I say, DNS set uses its old own entire universe, so, go for it.
MR. BELLOVIN: I think that the two have inherently different trust patterns, there are so many domains for hosting centers, people who don't own any address base, don't want to own any address base, let their provider deal with it.
One way to which this does help -- Geoff has been working very hard, George and APNIC to make one certificate for dealing with somebody else -- one reason why you have one -- with an RIR, you get a customer who's dealing on DNS issues and address base issues, they can authenticate both sets of messages, both kinds of requests with one certificate and that will help.
Any infrastructure that you set up to deal with customers securely will apply to both but the trust patterns are so different that I don't think that this will come -- it's nothing else, the route for.com is not going to be the same as the route for some block of address base.
MR. CURRAN: Okay. Moving to the middle back microphone.
MR. LEE: Thank you, John. Louis from Equinix and also on the ASO Address Council. We, at Equinix, have a pretty good view of the current Internet infrastructures so we believe that it is important for ARIN to invest resources in this very important work. Thank you.
MR. CURRAN: Okay, far microphone.
MR. McMONTGOMERY: Don McMontgomery, I had a question about the OK subject names, is -- in a couple of presentations, there were what's kind of like some soft design gold that discouraged misinterpretation and avoid potential liability issues.
I was wondering, are there any hard privacy requirements about that so that entities that you would envision being involved in the process?
MR. HUSTON: I can give -- this is Geoff Huston. I can give some hindsight into the thinking in APNIC around that area.
We certainly quite worried about having the CA bit set on so that when we issue a certificate, in theory, the subordinate entity who has that can issue a certificate for anything because the CA bit is set on and derive some level of authority that may be inappropriate.
So, as well as having a certificate practice statement, we thought, well, to be sure -- to be sure, we'll actually blur out the subject name so at least, from our point of view, when you validate and look at the validation chain, you come to a point where the subject name doesn't make sense and it seemed to us to be a reasonable design point to say, we're not actually attesting a valid entity, we are attesting about the holder of their private key as the controller of these resources.
So, that was our thinking in this area of saying, we can avoid some problems and make the intended use more explicit about resources, not identity, by doing that.
MR. KENT: Yes, I don't know of any privacy -- specific privacy requirements in this regard but from a PKI perspective, it's bad to have CA issuing certificates, attesting to things they are not authoritative for and it creates liability concerns that I would have a hard time arguing that the registries should incur.
So, by doing it in this fashion, it's reasonable to say that a registry is issuing certificates based on what its database says and it's not getting into the dangerous waters of putting a subject name into a certificate, that it's really not in the best possible position to vouch for.
And people also get very touchy about subject names and this avoids all that by saying, no, you can't have -- whatever one you wanted, you can't have it, you're going to get this thing that isn't a meaningful subject name and it's intentional.
MR. BELLOVIN: There are generally two broad classes of privacy issue, one is if there's a particular requirement especially for a particular identifiable name in the field and as you've heard, there are good reasons not to have such a thing and no particular strong reasons for putting one in, so we completely get out of that.
At some level of link backed to the WHOIS database reducing it to a previously unsolved problem, but the -- adding this doesn't compound that problem, we can live with whatever -- this will work with whatever solution comes up with there.
The second issue is linkage. When you're using the same certificate publicly for more than one purpose, you're clearly the same party and that may or may not be a concern, BGP routing is rarely seen in that issue, but there's nothing to require you to use the same certificate for two different prefixes or two different ASs you own.
So, if you wish to, you can get -- you can decouple that there. So, no, I do not see any particular threat to privacy and a decision to keep names -- personally identifiable names out of the subject, name field avoids the biggest potential issue.
MR. CURRAN: Okay, thank you. Front microphone?
MR. DILLON: Michael Dillon, DT Radiance. I'm concerned that -- we've spend a lot of time here hearing how this thing is going to work cryptographically, we're hearing a lot about certificates and signing and so forth, and we're not cryptographers, we're supposed to be dealing with ARIN policy.
It sounds like this new system is going to replace, entirely replace and wipe out the WHOIS directory as it exists today and the routing registries as they exist today, at least, that's what I -- John's statement implied.
I'd really like to hear more about how this system would work from the point of view of things like repositories, things like how -- who communicates to what.
Leaving aside the certificates and the signing, all that stuff, in a working system, should be under the hoods that nobody ever pay any attention to it.
So, I understand that when you're designing, you need to pay attention to it but how would this thing work one it's built and in place, what will it do for us?
SPEAKER: I don't really understand the question.
MR. BELLOVIN: I do. The -- it's not going to replace the WHOIS database, it can link back to that if you wish.
Whether or not it replaces the routing registry -- it doesn't replace it completely because at least, it was -- may not because -- at least, for some of this, there's nothing about policy -- writing policy in any of these certificates, if you went with SOBGP, you'd need a former derouting registry, there are operational issues, very roughly speaking and this should, as you say, all be hidden under the hood of the software, when you delegate an address block to one of your downstreams, you press the magic buttons on your keyboard, a magic mouse clicks and it gives them a certificate and it needs to get uploaded to some repository some place.
But when you're dealing with a downstream, you need to issue them a certificate and not just update your own database.
There are -- the other big operational issue is what happens if something -- in the certificate infrastructures and a certificate gets -- expires and isn't renewed properly, the certificate ends up on a CRL revocation list improperly, this will break routing for the effect of prefixes and this will require rapid and easy recourse in a way that doesn't -- that somebody say, I really own 61/A, please stop no routing it for -- yes, there are operational issues, I don't see them as insurmountable, but it will impose some extra burden on anyone who hands out address block.
The whole purpose of the software that Geoff is developing is to make that as easy as possible.
MR. DILLON: So, do you see, this is a third system separate from the -- and separate from routing registries.
MR. BELLOVIN: It may or may not -- how it relates to the routing registry is going to depend on the exact details of this proposal, it is completely separate from WHOIS.
MR. BUSH: It will also depend upon what happens in the secure routing area. If, for instance, SOBGP relies on redundant data in some form like VR or to say what are valid paths, whereas SBGP does not, because the paths themselves are forward signed, and in that case, the IRR become -- if this is fully deployed some time in my grandchildren's lifetime, then this indeed will obviate the IRR in the sense that people use the IRR to build route filters.
For those people that are not using the IRR for all the extended RPSL things to build all the other stream -- non-routing parts of their routed configurations, no, it won't supplant those functions, I don't actually think anybody is using them.
MR. CURRAN: I do think that at the end of the day, this is a very early stage, and that it would be incumbent on the individual RIRs to look at the tool kit and figure out what use or interface and what external programming access and external tool kit they supplied for the members and wish they're well before that.
SPEAKER: I was hoping that perhaps some of that would get into the requirements stage before things were built.
MR. CURRAN: That's worthwhile, that's actually a good point. We have over here, remote participant.
MR. LEIBRAND: Yes, this is from -- Scott Leibrand at Internet Network Services, this is not necessarily a comment for the room but my contribution to judging consensus, I second all of Andrew Dul's comments, particularly that this work is potentially very useful and deserves support.
MR. CURRAN: Okay, thank you. And a final comment, down here.
MS. MURPHY: Sandy Murphy, Sparta. To return to the question of the relationship between WHOIS in this new PTI, there is a whole lot of information in the WHOIS that people have put in there over many many years.
I don't know if people would want to have to completely reiterate all of that in order to create this PTI, if the PTI is completely independent from the WHOIS, we're creating the potential for conflict, if the PTI data says 12/8 is allocated to some person and the WHOIS data says 12/8 is allocated to someone else, there -- I don't believe that there's a necessity from maintaining independence of the two but of course, that would be -- how would we get data from the WHOIS and influence the creation of a -- in the PTI, who would creation of a -- in the PTI influence the WHOIS database, we'd have to work on that.
I don't think that maintaining complete independence is necessarily a good thing. Two potentially -- two hierarchies which represent the same information but are not tied does not seem to me to be entirely wise.
MR. BUSH: Yes, both our mothers, I think, warned against that kind of thing. The couple of things -- to show how open and confusing it is, I could see a WHOIS record that held the -- a reference to the relevant cert, allocation cert.
Conversely, I could see a WHOIS record that was signed with the private key of the allocation cert that matches it.
But I think we're -- I get a problem in my stomach, is observed that the -- a large extent, the WHOIS data have two purposes that are outside this domain and very intentionally outside this domain.
The first one is that the WHOIS data are actually trying to identify a party which this specifically is trying to avoid. And the other has escaped my mind. Geoff, go ahead.
MR. HUSTON: It certainly -- very quickly, Sandy, in WHOIS, you could actually say that there is some margin for error, the stuff is interpreted by people rather than automatically.
Certificates do give you no margin, this is a business actually about accuracy, business process accuracy and data accuracy.
And certificates do imply a level of rigor in the way in which addresses are managed which says you've got to be right all the time.
And I think we certainly looked at that and considered it and said, that's our business, that's what we believe we can and should do now and should continue in the future.
So, yes, the issue is recognized but I would still say, as a registry, particularly APNIC, accuracy is our business.
MS. MURPHY: With an implication that WHOIS is not as focused on strict rigorous accuracy. We've tried actually to look at the WHOIS in two different universes in APNIC, the bits that we entered and the bits that other people entered because the bits that we enter, we would like to stand behind and say, they're true.
The bits that other people enter, we don't know.
SPEAKER: Others have the same approach, Geoff.
MR. HUSTON: Okay, thank you.
MR. PLZAK: Okay, as I said when the panel started --
MR. CURRAN: Do you have another comment?
MS. MURPHY: Yes.
MR. PLZAK: Okay.
MS. MURPHY: Sandy Murphy, Sparta. A question about introduction of time dependencies in the checking for the allocation of a prefix, there was a discussion after Randy's presentation of the tutorial yesterday of the formation of AFRINIC and people who had allocations in the space that was transferred to AFRINIC would necessarily get -- have to get new certificates signed.
This will also show up, I presume, in those cases where people transfer part of their space to someone else and want to relinquish the authorities for the part of the space that they've transferred.
It would be nice if the system ended up being designed that you didn't have to have -- know when your certificate was signed by someone whose certificate authority was changed at some point.
But I can see that that's going to necessitate resigning a whole bunch of things when transfers occur and I just wanted to hear comments from the panel.
MR. CURRAN: Steve?
MR. KENT: Yes. If you transfer the resources, let's say, from one registry to another, then you're absolutely right that it does require resigning certificates for the resources that are transferred.
The good news is that the effect in the system stops exactly at that point, as long as you do it correctly and don't change the keys in the certificates that are being resigned.
MS. MURPHY: Yes.
MR. KENT: And as long as you do it in orderly fashion so that you create new certificates with a validity and overlapping the old certificate so that you can allow an orderly transition.
But yes, you have to pay attention to this. The good news is that if you do it right, it won't trickle down and require a lot of re-issuance of certificates in any years.
MS. MURPHY: But in the case where you're transferring part of the space that you've been allocated by another ISP, for example, you would need to get the other ISP to sign a new certificate for you and a certificate for the person to whom you transferred space? And they got it from you so they don't know to go to your parents --
MR. BUSH: You have to go all the way up to the route of
Where they too differ.
MS. MURPHY: Right.
MR. BUSH: So if, you know, my friend over there, 702 and I, somebody -- Steve is moving between us, you're going to have to go to the place where 70 -- the address block from which 702 got that meets my identity.
MS. MURPHY: M'hm. But they -- the person to whom you're transferring doesn't know anything about your parent and so I can see that there's going to have to be -- it's going to have to find a way to make that clear and make it easy for the people to do that.
MR. BUSH: But it's very determinable what that parent is --
MS. MURPHY: Yes.
MR. KENT: Right.
MR. BUSH: -- from the data.
MR. KENT: You're going to have to form a certificate chain to validate it and in the forming of the chain, you know who are the parents, you know, you know, the path of, so --
MS. MURPHY: Right.
MR. KENT: -- it's -- as Randy said, it's straightforwardly determinable.
MS. MURPHY: Okay.
MR. CURRAN: Thank you everyone. At this time, I'll turn over to Ray and he'll tell us what preparation for lunch.
MR. PLZAK: Okay. As I started this panel, it's not a matter of if, it's a matter of when and obviously, there's an intended discussion of how and how much.
So, we will start lunch back up at -- after lunch, the session will start at 1:45, a few announcements here, please take your valuables with you, this room is not locked and there is no security.
Cyber Cafe is open, visit and sign up and to win a backpack, that one will be announced on Wednesday, please complete your meeting survey and there's a for that too, two lucky winners, the iPod.
Thanks again to the sponsors for this morning. And lunch is where you had breakfast this morning and the meeting will start back up at 1:45. Reminder, we did announce a few agenda changes this morning, please go to the Website and see them there. See you at 1:45.
(Whereupon, a luncheon recess was taken.)
A F T E R N O O N S E S S I O N
MR. PLZAK: Good afternoon. I think I may have to do what the Chair's been doing, which is going through sunglass with these bright lights.
So let's get started here. I hope everyone had an enjoyable lunch. Before we start, again, let me give your Miranda warning, we're putting you all on film. If you don't want to be there, please go to the registration desk and sign the out form.
I did say I hope everyone enjoyed lunch. Did everyone enjoy lunch? Okay. Is there anyone that didn't like it? Anyone that didn't like it? Bill Manning didn't like it? Well, he didn't eat that lunch. So you ate the other lunch, and no, we didn't like having you there either. How's that? Yes, we all agreed, Bill, it was the company.
So, anyway, that lunch was sponsored by CIRA, so let's give them a little hand here. And Bernie Turcotte, who is from CIRA, is here. I have asked him to come up and just say hi, and let him explain to you why the Canadian immigration guys let me across the border.
MR. TURCOTTE: Thank you, Sir. I always hate it when people come up here and make long speeches, so it's going to be real short. Thank you very much for coming to Montreal. We're very happy to have you here. I wish you a great meeting, and it's great to see bottom up process really working well
12 with some good transparency. Have a good meeting.
MR. PLZAK: Okay, thanks Bernie. So, yes, the cyber-cafe is still open. And I've been showing you this slide all morning, it says "Visit site and win a mobile edge backpack in the Cyber Cafe raffle in and the drawing will be announced Wednesday morning". Well, this slide is in error, I've been lying to you all morning. Actually what we're going to do is we're going to have a drawing tomorrow morning for those people that visited today, and have a separate little prize to give away, which is a little quickcam, webcam, whatever you want to call it, so that will be the prize drawing for tomorrow, and the backpack will be drawn for those people that show up on Tuesday, and so this is your chance to get two things, you get the back pack and you get this to put in it. So, if you haven't had a chance to get over there yet, please do so.
So, anyway, in reminder, join us tonight for the street party, and here's how you get there. Between 6:30 and 6:50, pick up the badge that you need to get onto the street, and the directions as to how to get there are in the hotel lobby. It's a short walk to it, and it's also accessible by subway. So, remember, in the lobby about 6:30 or so, until about 6:50 to get your information and directions on how to get there, and then be there, and come and join us for a real good time, lot of stuff to eat and drink, music to enjoy, stilt walking -- I don't know if John's going to be stilt walking tonight, but maybe he's just -- well, actually we know John juggles because you see him do it at every meeting, so we're okay there. So --
Anyway, and as I said this morning, those people that picked up their trophies this morning have a chance to practice tonight as well. So, anyway, having said that, please remember the rules of the road. I'll just show you the signs and you just remember what they are. And we'll take it at that.
And so, reminder, we did make some agenda changes were posted to the web site. Because are starting 15 minutes late, everything is shifted 15 minutes as well.
So, the first proposal for the afternoon is, as staff can punch it up, there we go, Policy Proposal 2005-8: a proposal to amend the ARIN IPv6 assignment and utilization requirement.
It changes the IPv6 policy from /48 for end sites to the guidelines, which are shown here. And the utilization will be based on /56s, AC shepherds are Lea Roberts and Bill Darte. History, this was first introduced on the PPML in August of '05, designated a formal proposal in September '05. First public policy meeting discussion was in ARIN 16, seventh discussion is this meeting, the last revision of the text of this policy was in March of this year. And from a staff perspective, the resource impact is moderate, it's going to require changes to templates, software, guidelines, some staff training and production of educational material. Legal general counsel saw nothing in March, and there are no staff comments concerning this proposal. So, from the PPML, there are approximately 53 posts from about 17 people, 3 favor, 1 against. There's the comments, exemplary comments, you can see them all by visiting the archives for the PPML. And so, with that, I will call upon -- who's going to do -- oh, Lea is going to do the presenting. So, Lea.
MS. ROBERTS: Thank you, Ray. So, this proposal -- let's see here, looking back a little bit on the history of this proposal, for those of you who are first time attendees, the original policy for IPv6 assignment was based on RFC 3177 from the IETF, which basically specified three Assignment ranges, /128 for a single host, /64 for a single subnet, and /48 for anyone more than a single subnet. These are for end site assignments.
The RIRs got together and crafted a globally coordinated IPv6 policy which was adopted here in ARIN, based on RFC 3177, and part of that document said it would be reviewed after some operational experience was obtained.
About a year and a half ago now, it was noticed that some very large allocations were being made of /19, /20 size of IPv6 space, and that was based on existing customer, IPv4 customer base and HD ratio at the time of .80.
Geoff Huston did some analysis on that allocation data, or actually of looking back at IPv4 allocation data and projecting it on to IPv6, and showed that with the policies in place at that time, there could be a possible problem with everything aligned in the wrong way, of using up a large part of the IPv6 space within six years, presented these at ARIN XV and RIPE 50, and the sense of the meeting was that he should continue to pursue ideas about how to deal with these issues.
Proposals were forthcoming in APNIC, RIPE and ARIN, and the two proposals, the ideas were submitted as two separate proposals here in ARIN. This proposal 2005-8, which originally proposed to move from /48 to /56 as the default allocation size, or -- yes, assignment size - got to keep those names straight - and 2005-5, which incorporated Geoff's proposal that the HD ratio be raised to .94, that policy actually passed and is in place now here at ARIN.
Thomas Narten also followed up on the IETF side, writing a subsequent 3177 BIS document which was submitted to the IETF. It continues to evolve, the 01 draft is out there now. It revisits the 3177 recommendations, and states that there are really no architectural requirements for the /48 that was a policy that the IETF decided would be a good starting policy for IPv6.
And in response to that draft, so far, no actual architectural issues have been put forward to counter that argument. So we consider that closing the IETF loop and asserting that address assignment for IPv6 is actually an RIR issue.
In the RIRs, looking at these proposals, this proposal, as Ray said, was presented in Los Angeles, at ARIN XVI, and it had specifically defined /56 as a new default allocation size, but response to it on the PPML had made it clear that that was already not a popular proposal.
In addition to the concern over /56, there was concern about what would happen to /48s which had already been assigned, and in the other IRRs in particular, there was concern about existing IT systems which had been built assuming /48 assignments, and what resources would be required to go back and retool that software.
Also, it wasn't well-defined at that time how the utilization measurements would carry forward in the new non /48 environment, since the HD ratio was counting /48s. The specific feedback in Los Angeles from ISPs that was the concern that we go back to as classful kind of address assignment, that really we should learn from the past and stick with a CIDR kind of allocation for IPv6, no fixed boundaries for assignments, and so the new proposal actually does that. It says the assignment should be chosen by an ISP or an LIR, anywhere between /48 and /64 for an end site, and that that was the decision of the ISP LIR.
There are some guidelines suggested, awareness of boundaries if you're doing reverse DNS delegation, and it redefines the utilization count for HD ratio from /48 down to /56.
Then, recently it's been noted that there might be some issues on how to count a /48. The initial answer when it was asked on PPML was, sure, you just count it as 256/56s. Someone observed that this might not have the desired results since it sort of doesn't reflect a fully utilized HD ratio but actually improves your HD ratio and makes it an advantage to give out /48s.
One alternative that's been proposed is you could count it at the HD ratio of /56s, in this case, it would be 184 for an HD ratio of .94. Of course that only removes any incentive, it doesn't actually provide a disincentive, so one of the questions on the table is should there be some kind of disincentive to assign large amounts of address space?
And Geoff Huston intends to do some additional analysis here and we'll have more data forthcoming.
Another question that comes and I have heard is how to deal with providing guidelines to the ISP/LIRs and who would define what is the best practice for these -- for assigning addresses. We believe they should be generous but not wasteful and balance between the concerns of the LIR/ISP and the end-user. And we would like to be able to avoid any kind of competition of address assignment policy. So, you know, provider able to assign in /48. So, if you don't give us a /48, we'll go to provide A kind of thing.
And where would such a policy be defined? I mean, ARIN address policy is probably not the right place but where -- there doesn't seem to be a clearly defined place for something like that right now. So, that's one of the open issues.
Other questions regarding how to actually apply this policy have to do with how documentation of usage would be done from end-user insights to the LIR. One of the statements earlier in IPv6 is that assignments would not actually look back at customer infrastructure any more like has been happening now in IPv4. Is that still really appropriate or is there a need to be some kind of documentation that would guide the LIR in what size assignment to make to an end-client?
And also, again, it's a question of balance and you want to assign a large enough amount of address space to allow for growth and hopefully not have an end site have to come back for additional assignment.
So, what would be a good algorithm for that in the sense of taking what they clearly need right now and then applying some formula perhaps to that.
So, as far as the future of this proposal, a similar proposal is going to be presented at RIPE in two weeks. There will be a similar proposal resubmitted to APNIC. The original one was voted down but in the most recent APNIC meeting, the policy requested that it be resubmitted.
We believe it should be a kind of globally coordinated tour of the world try and all reach the same sort of conclusion, so you can see it -- you can be sure you'll see it here again.
And the one particular feedback we'd like to get from today's meeting is the question: Should there be a policy-based incentive for ISPs to make reasonable assignments? In other words, some way in the policy that would reflect back on disincentivise perhaps really large assignments.
MR. CURRAN: Thank you very much. At this time, the floor is open for discussion of this policy. I remind people this is a very important policy. For people who are curious, this is sort of the current default and only IPv6 policy that people are used to get addresses from.
So, those questions that Lea posed are very important topics for us to resolve as a group since widespread IPv6 deployment other than other proposals on the agenda today, that the present IPv6 assignment policies rely on the ISPs being involved and having some consistent answers for those questions.
SPEAKER: Over here, John.
MR. CURRAN: Tony, go ahead.
MR. HAIN: Tony Hain, Cisco. To the last point you were looking for feedback on, it's a very ambiguous question because you're saying reasonable. Define reasonable. You know? Reasonable, is in view of the beholder and, you know, through an insight, larger is more reasonable than smaller. To someone who's trying to minimize adverse space utilization, smaller is better. And those are both reasonable. Right?
So, you can't get an answer to the question as posed because you'll get different answers from people on the other side of that. So --
And given that the people in this room tend to be focused on -- conservation, you're getting get an answer that's skewed.
MR. CURRAN: So, just to respond, historically, RC20-50 has set guidance that said we look at people's needs and we provide the address space that they need for a reasonable, example, two year period of growth and that's based on evaluating an application and looking at infrastructure and doing a lot of other things.
In the IPv6 world, the guidance that we receive to operate under that came from the ICS amongst others was, "Don't look at anything. Just believe" and that makes it challenging to actually have a reasonable allocation because both parties are actually operating on a complete vacuum of information.
MR. HAIN: I understand. At the same time, I don't think you can ever say that /48 is the only value, right? There are organizations that are going to need more than that and you're certainly going to have to evaluate those. But there are many of those and we certainly don't want you to evaluate every home network known to mankind to decide whether they need a 56 or 50 or 52 or whatever because that just is an insane amount of work.
MR. CURRAN: So, for the proposal that's on the table, Tony, would you support advancing 2005-8?
MR. HAIN: As it's currently worded, I would have no objection, but I'm not necessarily ready to support it per se.
MR. CURRAN: Okay. The microphones are open. Centre mic.
SPEAKER: I just want to respond briefly to Tony. I mean I think pretty clearly in my mind and in the minds of other people I've spoken to, we're looking for balance between the end-users' needs and also, you know, the ISP needs and you're doing the right thing from a public policy perspective. So, I think it's not really quite fair to characterize sort of this community as being, you know, more focused on utilization or on addressing efficiency at the expense of everyone else. I think, you know, we're trying to find a balance and that's why we're having this discussion here.
MR. CURRAN: M'hm. And Thomas, quickly, for the proposal on the table 2005-8, would you support advancing it or not?
SPEAKER: I would support it. But I think it needs -- I think it still needs further work and more clarification. But in its current form, I would still support it.
MR. CURRAN: Okay. Good to know. Far microphone?
MS. OKUTANI: Izumi from JPNIC. Since I'm not from this region, I'm going to -- I'm not going to say that I would support it or not. But just as a reference, since it's a globally coordinated policy, the situation in Japan is that I think it would probably be difficult to gain support from Japan if we try to remove the fix boundary and have a guideline over, you know, which size to assign. And the reason for this is that people are concerned that by doing that, you might lose the benefit that IPv6 has over IPv4 which is the simplicity of the network design and lowering the costs. So, that's just an information for your reference. Thank you.
MR. CURRAN: Okay. Thank you. Back over here.
SPEAKER: We have a comment from a remote participant.
It is Fred Wettling and he's with the IPv6 Business Council. We feel that the PI allocation qualification in the proposal 2005-8 does not recognize the dynamics of potential rapid corporate site growth or new users of IPv6. A standard /48 allocation for physical site for qualified enterprises reduces enterprise management effort. /48 is the same allocation that's currently assigned by LIRs to customers.
MR. CURRAN: Okay. Centre microphone? Geoff?
MR. HUSTON: Geoff Huston, APNIC. For what it's worth, even though I'm a staff member of APNIC, I think it's a good proposal.
The issue here is actually one of balancing extraordinarily long term against extraordinarily short term. If we honestly believe that IPv6 is a technology that will effectively be utilized by literally billions of end-devices, then you really have to worry about can you change address allocation policies in the future when your -- of installed bytes is not the tiny thing you have now but a massive amount of deployment.
We've already seen that IPv4, as we tried to refine policies, we started pointing at the early allocation saying, "I'm fair. I'm fair". We have an issue here of trying to understand beyond their immediate goals what we view as the outcomes of these technology over decades.
The studies done with the allocation /48 seem to indicate we will choose for you this space in decades, not centuries, even with the HD ratio change. Allowing ISPs to have some latitude in how they do inside allocations is a very, very good thing. And from that point of view, I think this is this case of trying to understand it's not just the obligations to the folk around you that we have to be mindful of. You actually have to be mindful of the folk who will be in this room some decades away saying, "Gee, they stuffed it. Now, how do we change it?" Thank you.
MR. CURRAN: Thank you, Geoff. Okay. Back over here.
MR. RICH: Yurie Rich from Command Information. I support advancing this proposal. My biggest concern is in regards to Tony's comment as well. But reasonable is for commercial entities, there's a process in place for going and getting an allocation and there are some costs involved with that and that's supported by the entity.
But my biggest concern is for the residential user. What I would like to see is have a policy in place that doesn't create a new business model for the ISPs to provide another or larger subnet to residential users, say giving a /64 if I want a /66 or -- excuse me, the wrong way. A /62 that I can get, if I pay just a little bit more, which is an inherently large address space. I'd like to see a reasonable allocation that would fit the needs of the residential user given from the get go.
MR. CURRAN: Okay. Centre microphone?
MR. SCHILLER: Jason Schiller, UUNET/Verizon Business. I'm in support of this policy. I think it moves in the right direction. At the last ARIN, we heard a number of comments about not doing CIDR that we should be getting variable length and this policy enables LIRs and ISPs to do that.
What I'd like to see is some stronger recommendations about how to give out the space in the appropriate size without creating individual different type buckets.
And I think that that metric has to be based on current utilization times, some over provisioning factor based on what you think the right balance is between efficient utilization and aggregation.
That being said, without some sort of encouragement for ISPs to do the right thing, assuming that we can actually find the right balance and know what the right thing is, without having encouragement to do the right thing, there's nothing from stopping one or more ISPs from simply giving out 48s because they can and it's easy. And if enough of them do that, then all of them will have to do it so that there's not a competitive advantage or disadvantage.
So, what I'd like to see is a very clear guideline based on need times whatever factor you think is useful to strike the
right balance between efficient use and aggregation.
MR. CURRAN: Okay. Quick question, just for clarification.
You say you support this proposal but you'd also like to see clearer guidelines on how that allocation is decided. Would you think that this proposal should be advanced but not implemented until those guidelines are present? Would you like to see those guidelines be integrated into a future version of this proposal?
MR. SCHILLER: Definitely the latter I would agree with. The former, I'm not sure where I stand. On one hand, if the policy is implemented as is and everyone decides to ignore doing the right thing and just give out a /48, we're nowhere soft than we are today.
MR. CURRAN: M'hm.
MR. SCHILLER: And at best, maybe some ISPs will want to give smaller blocks, assuming they can strike the right balance. The other potential problem is maybe ISPs would give too small blocks from my perspective. I don't personally see that as an issue, but I know that there are other people that are fearful of that.
MR. CURRAN: Okay. And do you believe that this forum is a forum that's appropriate for setting the guidelines for what those ISP assignments then usually should be?
MR. SCHILLER: If this isn't the right forum, than what is?
MR. CURRAN: M'hm. Just asking as part of your feedback.
Thank you. Okay. Actually, I'll take the back mic. He was there first.
MR. WOODCOCK: So, hyperbolic babble aside -- oh, Bill Woodcock. The only difference between v6 and v4 is 96 more bits and those 96 more bits do not make classful addressing a good idea. And there is no point in having all those more bits if we just sit around and talk about them rather than actually allocating them to people who want them.
So, us sitting around and talking rather than getting something out there that gets addresses in the hands of the people who can't apply for them right now or having to lie when they apply for them right now would be a good thing.
MR. CURRAN: I believe though you support the proposal 2005-8?
MR. WOODCOCK: I support any proposal that actually moves forward at this point. I've given up on good. Okay?
MR. CURRAN: Thank you, Bill. Owen?
MR. DELONG: Owen DeLong, Netli Networks. I support 2005-8 as it's currently written. I do agree with most of the proposed changes but as has been pointed out, even if everybody ignores the recommendations, we're still better off than where we are now.
MR. CURRAN: Okay.
MR. DELONG: So, that's pretty much what I have to say.
MR. CURRAN: Yes. Microphones are open for comments on this. Please go to the mics. Yes?
MR. BUCKNELL: Here we go. Leo Bicknell, ARIN advisory counsel. Without commenting on the actual proposal, to the original question of incentive, I wanted to remind people that while today all IPv6 fees are waived, there is codified and I just pulled it up on the web site, IPv6 fees that would start to be charged on January 1st, 2008, and they are based on the total size that the ISP has received.
And so, as an ISP hands out more space, they will pay more money. So, there is at least a financial incentive that has already been codified that I think a lot of people aren't thinking about because it's waived at the moment.
MR. CURRAN: Good point. Okay. Yes, centre mic.
MR. DILLON: Michael Dillon, BT Radianz. I don't support this policy. Basically, I don't think it's finished yet. I don't think there's enough detail, enough of the loose ends have been tied up and if this policy was a good go ahead to the advisory counsel to then have to turn it into the actual test in the NPRM, I don't think we have enough information to do that at this point in time.
And overall, this policy is just changing the way things -- okay, we already have a policy that allows ISPs to assign end sites address blocks. We don't need a policy in order to enable that. So this doesn't actually enable anything. It just changes the way that they have to do it in the future. And I don't think there's any point in tinkering with that right now. I think we have more pressing issues like getting PI allocations available to people.
MR. CURRAN: Okay. Far microphone.
MR. LOEVNER: Michael Loevner, Verizon Internet Services. I agree with most of what Bill Woodcock was saying and, in addition, I think that it's the place of ARIN to set policies for justification of the IP address blocks more than setting the exact sizes that can be assigned down to customers.
MR. CURRAN: Okay.
MR. LOEVNER: I'm for the policy because it's a step forward.
MR. CURRAN: Okay. Tom.
MR. NARTEN: Thomas Narten, IBM. Just to respond a little bit to your comment, I mean, Lea and I and some other have had some discussions about the question like pricing pressures and if LIR is getting charge for address space, there is in some sense some disincentive to give out too much 198 space. But I suspect that there is actually a number of dragons if you go in that direction because for one thing, the pricing policies vary from region to region and another thing is I don't know that we ever want to be in a situation where people say, "You know, we're not putting enough back pressure on what LIRs are doing. Let's raise the prices". I mean if this is the kind of question -- I'm not sure that we want to ever have to deal with this.
So, I personally would prefer to see other kinds of ways of achieving a balance than just pricing.
MR. CURRAN: Okay. To complete that, we have two comments from -- we had two. Over here.
SPEAKER: This comment is from a remote participant from Scott Liebrand. In my opinion ISP should be free to allocate between /48 and /64 without incentives or disincentives to end up at the higher or lower end of the range. The approach of making a /48 HD ratio neutral seems reasonable to me. The new paradigm in IPv6 seems to be to give people as much space as they might reasonably need. The decision of what is reasonable should be decided by the LIR and the consumer within a broad guidelines proposed and also I agree with the sentiment of supporting for advancing 2005-8 as is and making further tweaks later.
MR. CURRAN: Okay. Microphones are opened. I'll shortly close the mics on this topic. Microphones remain open. Microphones are closed. Okay. At this time, folks, it's necessary for us to have a show of hands because the AC needs this to make a deliberation on trying to figure out what to do with this policy proposal. I'm going to ask for single vote show of hand. The first vote is -- the first show will be to -- raise your hand if you want high and then the second one will be to raise your hand if you're against. Okay?
So, I hope everyone is ready. Time to stretch after that wonderful lunch. All those in favor of policy proposal 2005-8, proposal to amend ARIN IPv6 assignment utilization requirement, please raise your hand now. Hold them nice and high. You can actually hold them higher if you want. The ceiling is very high. You don't have any fears. We have a vote. Okay. Thank you.
All those opposed to advancing policy proposal 2005-8, proposal to amend ARIN IPv6 assignment utilization requirement, all those opposed, please raise your hand nice and high.
We have a vote. Thank you. It just reminds me that in a moment, we're actually going to count all the heads in the room because that was asked at the last vote and I forgot to get that.
I'd ask my wonderful poll takers to count the number of people in the room. Okay.
So, regarding 2005-8, the number in favor is 55, the number opposed is 3 and we're getting a total population now. I'll let you folks know that as soon as I have it. Thank you.
MR. PLZAK: Okay, moving on. If you recall, this morning, I mentioned that 2005-1 and 2006-4 were closely related and we are going to be making an agenda adjustment because of that and accordingly, we'll be making a slight modification to the rules that I discussed this morning and so the Chair will explain that slight bend in the road.
MR. CURRAN: Okay. So, we actually have two policy proposals on the same topic. One is rather new and the other one is quite aged and has color and history to it. But they both address provider independent IPv6 space assignment.
In order that we don't discuss the same topic twice, we're actually going to have a joint proposal on these two proposals because they have a lot in common and then we'll actually call for the vote for both of them independently at the end.
Now, you have to recognize that the AC can't handle two IPv6 PI assignment policies and that even if you end up with both of them both advanced to the AC, they're likely to take one based on its works or lack of votes or slight -- slight position behind in the running and set it aside.
So -- but it's important you vote for either one because we don't know which one is the one that has the most value. We're going to discuss the merits and actually show the differences between them.
I would ask that people not hesitate when we're going into discussion to discuss the merits of either proposal. Yes, Mr. Bradner.
MR. BRADNER: Hello? Hello. There we go. Can you pay attention, please, in the future? Thanks. Scott Bradner. Note that the AC isn't required to toss one in the garbage.
MR. CURRAN: That's true.
MR. BRADNER: The AC is a bunch of bright folks and is allowed to merge and come up with the best of both worlds with cooperation from the authors and all of that kind of stuff.
MR. CURRAN: Right and the office has shown a remarkably high level of cooperation as you'll see, in the joint presentation that they're about to give. So, at that point, I'll turn it over. Come on up, gentlemen. Oh, sorry. You're going to do it, Ray? For point of information, 107 people are in the room.
Policy Proposals 2005-1: Provider-independent IPv6 Assignments for End Sites and 2006-4: IPv6 Direct PI Assignments for End Sites
MR. PLZAK: Okay. So, what's going to happen is that I will go through the impact analysis, legal analysis, staff comments, PPML discussions for both of these proposals in a serial manner and then Owen and Andrew will come up here and share the stage and present the proposal and, at that time, it'll go back to John to moderate the discussion. So, let's move forward.
And so, looking first at 05-1, it is to allow for v6PI assignments to end sites and here's the criteria: Not being an LIR qualified for v4PI assignment, assignment /48, Robert and Cathy Aronson. History, as John said, it's been around a while, December '04, is when it was introduced for formal proposal, February '05. The first policy meeting it was discussed at was ARIN XV. It was discussed at ARIN XVI and it's now being discussed at ARIN XVII.
The last revision of the text was on the 10th of February of '06. And from the staff perspective, the resource impact is significant, requires templates, registration software change, guidelines changes, staff training.
Legal risk counsel in March of this year saw no risk and staff had no comments.
And PPML discussion, approximately 434 posts by approximately 42 people. This is since October of '05. This is not for the entire length of the proposal but since October of '05 which is when -- at the conclusion of ARIN XVI meeting. So, it's been a quite active discussion. There are the treads and you can see there's a number of different treads.
And looking now at 06-4, it provides IPv6 assignment inside -- usually assignment criteria here which is not being LIR, being inside, be a multi-home with a V4/19 at 80 percent utilization and the assignment size is a /48 from a reserve /44 and it's coming from an identified range to facilitate filtering. Shepherds for this proposal are Bill Darte and Lea Roberts and so Lea is quite a popular person in the v6 world, is she? This is three in a row for her.
History. Introduced in February this year, formal proposal in February of this year. This is the first public policy meeting discussion of this. There was a revision of text on the 3rd of April of this year.
From the staff perspective, implementation assessment significant. It would require templates, software change, guidelines change, staff training.
Legal, in April of '06, no risk foreseen. Once staff comment is that must have a direct assignment from ARIN of at least a IPv4/19. Does this mean that ARIN would issue space or does it apply and does it include any legacy space that the holders may have? That's something that staff would like to know in terms of this criteria. In other words, that /19 is a direct allocation from ARIN - no, I'm not to answer now. I'm just giving you the comment - or would the /19 fit also into space that a legacy holder has.
Okay. PPML discussion. It hasn't been around long but there's been 147 posts from about 32 people. And I won't go through and read the comments. They're there. There's more on the archives.
If you've been a regular participant in the PPML, your mailbox will have been full all year long with discussions between these two proposals.
So, with that, I will ask Owen and Andrew to come up here and share the stage and then John will take it from there.
MR. DELONG: Okay. So, this proposal has been around for a while. Andrew and Kevin and I spent some time last night and some more time this morning working on hashing it out. We actually have resolved a number of things down to where they are actually very few differences remaining, and we'll go through those. We've actually even merged the slide set.
This is where we have common ground. We believe that there is a need for provider independent v6 assignments for a number of reasons. Currant policy allows it for v4 and not for v6, providing a disincentive for many organizations to move to v6, and currently there is no viable technology substituted for multi-homing or ACL management, et cetera, et cetera.
The end result, no viable migration path, non- ISPs with v4 PI assignments, just can't make a business case for v6 because it's a straight jacket for them, and that creates a significant obstacle.
Solution, basically we need a PI policy, the first version was, if you have enough on a system, you can get PI, that was seen as too permissive by the people present at the first meeting where this was discussed. The next version had 100,000 node requirement that was proposed by some of the people that were present at the first meeting. That was viewed as too restrictive at the second meeting where this was discussed. So the current proposal offers basically parity with the existing v4 policy in the hopes that, since we consider that acceptable in the v4 world, it's probably reasonably close to what we want in the v6 world at least until we know more.
Viable IPv6 only criteria has been pretty elusive because we don't have much v6 OPEX in terms of allocations and assignments, and it's expected that, you know, this process will be used again and again as time rolls forward and we gain more experience to modify the policy.
The current state of the proposal, minimum size of the 48 in terms of the assignment, obviously that would probably get adjusted if 2005-8 is adopted. Larger sizes available based on justification. The HD ratio is not actually part of the policy wording, it's part of the existing v6 policy body that would just be incorporated into this because of being part of the existing v6 policy for how additional assignments and assignment expansion is done.
It is expected and now part of the revised proposed policy that these assignments would be made from a separate block, and the draft has been updated to reserve a minimum of 44. For any allocation smaller than a 44 and essentially to provide, for example, if you're issued a 44, it's from a reserved 43, et cetera, of the chain.
Concerns have been expressed on multiple occasions about a land rush. I don't think that's really a meaningful situation. 2002-3 came up with a lot of the same resistance for the same reasons, and the reality is this is no less restrictive than 2002-3, and according to the ARIN assignment statistics, 2002-3 did not create a land rush. Given the current state of v6, I think a land rush would be a nice problem to have at this point.
I believe this is where I turn it over to you.
MR. DUL: Thanks Owen. As Owen said last night and yesterday, and Saturday, we're trying to meld these policies and make them as close to possible so we have some options, and we clearly explained exactly what the differences are between the two policies. So they both come from similar motivations, the desire to solve the issue that we currently have with enterprises, and other organizations to get them into the v6 world. And we really think they have more in common than they are different at the moment. And I wrote the 2006-4 policy to provide a more conservative one to the one that Owen and Kevin had written, to try and quell some of the theories about a land rush, as I perceived that to be an issue among the community, and this is -- the policy that I wrote was an attempt to try to at least stem some of those fears about a land rush. So, we think that either policy is probably better than no policy at this point, and a policy today isn't a policy forever, so if there are specific things that need to get changed in the future, let's change them, but I think we need to move forward and start down this road, otherwise we're going to continue to continue delaying v6 with option by some large organizations.
So, during our discussions, we came to three conclusions about differences between the two policies that we've decided to harmonize, and the first is including an explicit requirement in 2005-1 to require a specific block to facilitate filtering, that was in 2006-4, but not in 2005-1, so that's an area that we agreed on. Second area that we agreed on was a reservation of a /44, so we're going to add that to the 2005-1 policy. And the third area of agreement was to remove the end site requirement from 2006-4, as this was just causing confusion due to the way that end site is defined in the current IPv6 policy.
We think there's a need to define the type of organization that uses a PI assignment in the future, and that's not in the current text, so I think that's something that we should do in the future to clean up this after we get it implemented.
We'd like to focus today's attention on the initial assignment qualifications, and those initial assignments. We realize there are differences in the subsequent assignment criteria between the two policies, but we think that if those are issues, they shouldn't stop us at this point from moving forward with either of these two proposals because the subsequent assignment parts of the policy we don't expect to have to be exercised for some time.
So this is the meat of the differences, this chart here. 2005-1, the requirements for an initial assignment are, you're eligible for any v4 assignment under current ARIN policy, so that means a /22 for multi-home sites or a /20 for non multi- home sites.
2006-4 differs in that it requires you to be currently multi-homed with v4, have an IPv4 /19 or larger, and the way I would answer ARIN's staff question regarding this, is I believe that the policy covers both legacy and current ARIN members, or end site policies. Obviously a legacy holder would have to sign a registration service agreement to obtain a PI policy. It also requires 80 percent of a IPv4 /19. Where we differ on assignment size, we agree somewhat, both agree on a minimum /48, 2005-1, basically uses the, although not explicitly in the policy, uses the idea that is in the PA policy about using the HD ratio and the number of the subnets to determine the size of the assignment. The 2006-4 policy just spells it out and says, "You get a 48, you get a 48 per ASN you have, and that's it."
And then the future assignment criteria are also up there, they mostly map to the way that the initial assignment is made, so the subsequent assignment uses the same criteria, or slightly different criteria, but builds on the initial assignment.
So, the differences here are in the two top blocks: the requirements for initial assignment and the actual assignment size. Those are the areas where we're different, and where I think we should focus our discussion today.
So this is a fun slide, choice is good. We want to have a debate on this and really decide which one is the best for us, moving forward. We realize that there are lots of ways you could interpret and lots of ways you could write these policies, but we really want to come to consensus on one or the other, and be able to move forward. We believe that it's necessary to get this on the books, and move forward, and then let's tweak it later as time goes on. We think both of these are reasonable, I think both Owen and I would support each other's policies, provided they achieve consensus to move forward and then tweak as necessary in the future.
I think that's it. We have the policy statements available on the screen if people want to specifically talk about them.
MR. CURRAN: We also have them in your books. If we could go back two slides to the comparison slide, that might be good to have up during the discussion. Yes, that one. Why don't you stay handy for just a minute or two. There might be a question or two. Microphones are open for discussion of 2005-1, and 2006-4. Middle microphone.
MR. DILLON: Michael Dillon, BT Radiant. I am going to support proposal 2005-1. I think it's very important for us to get a PI policy on the books for IPv6 as soon as possible. Of these two proposals, therefore, I've decided to pick one and vote for one rather than vote for both of them because I want to try and send a more clear message, and I urge everyone else here to do the same. If you're in favor of having an IPv6 policy, pick one of these proposals and vote for only that one proposal, not for both of them. In the end, the advisory counsel does little tweaks and things, so if -- I don't know if you've cleaned the word "end site" out of all the proposals, but if it's still in there, I'm sure they'll put "end user organization" in its place because that's the intention.
MR. CURRAN: And specifically 2005-1, for what reason?
MR. DILLON: It's simpler. Simpler.
MR. CURRAN: Okay.
MR. DILLON: And as far as getting the details right, I think that can always be done later with different policy proposals at a different time. But at least we get the addresses out there and get people using them, and using IPv6.
MR. CURRAN: Okay. Thank you. Far microphone, Bill Darte.
MR. DARTE: Yes, this is Bill Darte and I'm on the advisory counsel, and I'd just like to clarify and make sure everyone understands that the role of the AC in evaluating what might come out of this discussion and be forwarded to us is impacted by the amount of change that any one of these policy proposals receives through this discussion, so in other words, if one or the other were to come to us with very minor as, Michael just said, changes, then we would be able to work with that and move it forward, but if there were substantive changes, then that would require us to go on to a further cycle.
MR. CURRAN: Ray, did you want to comment on that, or --
MR. PLZAK: Not on that, but I do want to say one thing as we move forward on this, realize that the implementation assessments, legal assessment and staff comments are all based upon the language that the proposals as presented. Any new drafting so forth, we will do a redraft of those, and submit any changes that may occur.
MR. CURRAN: Right. Okay. Microphone over here.
MR. WILLIAMSON: David Williamson, Tellme Networks. I just had a quick question about clarifying the latter proposal, Andrew. You have a requirement for an assigned /19 or larger. Is that aggregated across an organization's total space, or is actually going to have a 19 or bigger literally?
MR. DUL: Little blocs can add up to a 19, that's the intended way that I wrote the policy.
MR. WILLIAMSON: I was just curious about that. As a likely consumer of this policy, of either of these policies, I'm pretty much in favor of nearly any PI policy that will move forward. I think I have mile preferences for 2006-4, but again, as a consumer of this policy, I just want to see something out there that is more than what we currently have, which is nothing. Thanks.
MR. CURRAN: Okay. Okay, thank you. Back microphone.
MR. DIVINS: Dave Divins, ServerVault. I fully support this policy and I'm actually inclined to support 2006-4 just a little bit more, but I just wanted to say that I think giving multi-home identities the ability to get a PI is extremely important, and I know the counter-argument of the concern for route aggregation issues and I think it's ARIN's place to allow IPs to be assigned, I think it's ISPs -- if the ISP is placed to say if we can't support these, we don't support them, they don't support a lot of technologies out there, but it's not ARIN's place to dictate whether or not, you know, that, but ARIN should give out addresses and if ISPs don't want to support them, that's perfectly within their right, and let the market decide what we end up doing with these things.
MR. CURRAN: Okay.
MR. DIVINS: Thank you.
MR. CURRAN: You expressed a preference to 2006-4 over 2005-1. Could you say why?
MR. DIVINS: Because it goes to 11.
MR. CURRAN: Okay. Got it. Okay. Centre microphone.
MR. WOODCOCK: Bill Woodcock. Please, please, please move 2005-1 forward without any changes and delays and so forth, let's just get it out there, and if there are problems, we can deal with them, we can deal with them next time instead of talking and talking and talking, and still talking next time, and not having actually made any progress. 2006-4 has too many specific points that will keep the staff running around in circles and keep people having to lie about stuff because they want space and it's got a bunch of specifics that they won't quite match up with. Let's just do 2005-1, and if any problems come up, we'll know about them.
MR. CURRAN: Okay, thank you. Far microphone.
MR. DUDEK: Aaron Dudek, Sprint. I'm just curious on how either one of these two policies would enforce anyone to fix the multi-homing problem that we currently have?
MR. CURRAN: You need to ask the question, Aaron. Are you for either of these policies?
MR. DUDEK: I'm against.
MR. CURRAN: You're against both. And your reason is because you don't believe they address --
MR. DUDEK: There's no incentive to fix multi-homing if this gets passed, because --
MR. CURRAN: Okay --
MR. DUDEK: -- multi-homing sites can just claim an API space, and therefore we'll never move forward with that part of the protocol.
MR. CURRAN: Okay. Sounds good. I'll ask the two proponents, does either of these proposals fix multi-homing?
MR. DELONG: I don't think multi-homing per se is broken, so no, we weren't trying to fix multi-homing, we were trying to fix the ability to multi-homing v6 instead of the current state where the ability to multi- homing v6 is broken.
MR. CURRAN: Okay. Do you want to comment, Andrew? No?
And do you want to respond, Aaron?
MR. DUDEK: No.
MR. CURRAN: Okay. Far right microphone.
MR. FELDMAN: Hi, Steve Feldman, CNET Networks. I support both 2005-1 without reservation, 2006-4, personally I think the requirements are too stringent mainly because my organization doesn't quite qualify. But -- it's true. We might be able to fudge numbers. The big problem with 2006-4 that I see is it doesn't take into account -- it requires the existing assignment to v4 space. We could easily qualify /19 or maybe even larger if we took all the stuff that's currently in private address space and put it in public space, which we would do if we move it to v6. So I'd like to see some mechanism to accomplish that. I think 2006-4 is actually a little simpler, but what do I know. No, so to Aaron's comment earlier, yes, multi-homing is broken if we can't use it, from my point of view, as a content site that needs to get fixed if we're going to use v6, I don't care how it gets fixed, but this is the closest thing on the horizon that I see, so that's why I'm actively supporting it.
MR. CURRAN: Got it. Okay. Centre back microphone.
MS. SKANKS: Okay, so, can everyone hear me?
MR. CURRAN: Yes.
MS. SKANKS: I guess my first question would be -- sorry, Heather Skanks from MCI. My first question would be is the goal of this to solve the ease of renumbering, or to allow folks to do multi-homing in v6?
MR. DELONG: Yes.
MS. SKANKS: Which is the primary goal?
MR. DELONG: They're both primary goals.
MR. DUL: I would agree with Owen.
MS. SKANKS: Okay.
MR. CURRAN: So these proposals are designed to address both multi-homing and avoidance of renumbering. Okay?
MS. SKANKS: Okay. So, my first concern is using a policy solution to solve a technical problem. So, multi- homing is a technical issue, and you're trying to solve it with policy and not allowing the existing work going on to solve the technical problem of multi-homing to finish. And the second issue is the ease of renumbering and trying to -- you can find a technical solution to make renumbering easier as well rather than solving the same policy. So that's my first concern.
My second concern is the existing policy for LIRs today is that you have to announce it through a single aggregate. Neither of your policies say that, so what ends up happening is if either of these pass as they are, end sites will be able -- it's unclear whether end sites will be able to be aggregated or not, but LIRs won't be able to. So, to me, there's a conflict there. Any comment?
MR. DUL: So, to answer your first question about a policy issued to solve a technical problem, we'd be happy to take technology and solve it with technology, but we don't have any technology. So, in order to deploy IPv6 --
MS. SKANKS: So --
MR. DUL: -- therefore, we have to do it this way or you're going to have to wait or we'll let be v6 die in the vine, I think.
MS. SKANKS: I think -- So, it's easy to say in this forum, let's solve this with policy. Because hearing is about policy. We're all hear to set policy. It's much harder to go to ICF or another forum and trying to come up with a technical solution. But it doesn't mean that we shouldn't do it, though.
MR. DUL: And I agree with you. I was at the IETF meetings, I was at the Shim6 meeting. I support moving forward with the experimental part of it. But we're not ready. It won't be ready for five or 10 years. So, at this point, if you want to say delay IPv6 deployments, large enterprises for five to 10 years, that's fine. We can go that route or we can deploy IPv6 with this and try to move forward and gain momentum with IPv6. Because, if we don't gain momentum soon, it's just going to sort of -- just go sort of cruising off into Lala Land. That's my personal opinion, but others are certainly welcome to their different opinion.
MR. CURRAN: Heather, I guess these two policies, given whenever issues are going on technical solutions, given that these two policies are here before ARIN, would you recommend proceeding with either of them, or one of them, or neither? Because --
MS. SKANKS: Yes, I think that it opens -- it's another situation where, if we do this, it's going to be a lot harder to clean up and fix later on. And it's going to, I think, stall. So, everyone else had to do multi-homing today the way that we currently do. And it's easy and -- But it opens up other problems later on down the line in v6. And so, it'll be a lot harder to draw the line. It'll be a lot harder to ever change anything. And I think you'll leave momentum for finding a technical solution. So --
MR. CURRAN: So, you'd be against both of these? Okay. Okay. Far microphone.
MR. SEASTROM: Rob Seastrom, Interdotnet, narrative advisory counsel. For exactly the same reasons just enumerated, I support 2005-1 and hope that we move it forward as quickly as possible, and look forward greatly to the time when we have pressure from the operator community to change our policy based on actual observed growth of the IPv6 routing table rather than theoretical problems that may or may not happen and will certainly never be a problem if we don't actually get any IPv6 adoption.
MR. CURRAN: Okay, well said, far microphone.
SPEAKER: I just want to, yes, voice my support for what Heather said earlier. And I'm just curious, because I wasn't there when this happened, but how many of these arguments are coming back when we had to worry about CIDR and CIRA was first coming around? Are we doomed to start repeating the same mistakes that we did just because a technical solution won't be available for five or 10 years, and then, by then, it's going to be too hard to go back, and then we're going to find another solution, IP - what -- version 9, 10?
MR. CURRAN: Okay. Thank you. We have Leo, you here. Yes, Leo.
MR. BUCKNELL: Leo Bicknell, ARIN advisory counsel. I just wanted to ask a clarification point just to be sure it's clear since it's not on the slide. My understanding of reading these two policies very quickly here, the actual text again on the web site is that, with 2005-1, you only have to be eligible for the IPv4 assignment. So, conceivably, a new party who wants to do v6 only could show v4 eligibility and get a v6 block and actually never have a v4 block. Whereas 2006-4 requires that you actually have the v4 space before you can do it. So, with 2006-4, you would end up with both, even if you only desire to use the IPv6 base. Is that a correct interpretation?
MR. CURRAN: That is correct.
MR. BUCKNELL: Thank you.
MR. CURRAN: Yes, okay. That's correct. Far right side. Oh, I'm sorry, Owen, you have to say?
MR. DELONG: Yes, actually, a couple of speakers back, I wanted to comment. In terms of a technical solution to a technical problem versus a policy solution, there is an existing technical solution to multi- homing, and it works pretty well at the current scale of the Internet. And this policy allows us to continue using that in v6. If we have a better technical solution later, then we can change the policy later to meet that better technical solution.
MR. CURRAN: Okay. Far right microphone.
MR. RICH: Huey Rich, command information. I'm also representing the views of the IPv6 business council. So, PI space is very important to businesses for a number of reasons. And I don't necessarily think or have a different perspective, these are not necessarily technical solutions, but they're business drivers for IPv6 adoption.
One of them is forcing large businesses to get their allocation from one ISP is a form, from their perception, of a perpetual contract, and something they won't do. Consequently, it's an inhibitor to v6 adoption. IPv6 adoption has plenty of issues without address allocation being one of them. So, if I didn't say it earlier, I support advancing 2005-1 and/or 2006-4.
In addition to that, the business council wants to make it clear that it's important that these restrictive covenants are put in place so that there isn't a land rush. I know that was one of the issues in Florida last year. And one of the point is that, in recognition that this may not be a perfect solution, it's a temporary solution, but one we think is important for IPv6 adoption that this should be reviewed again in the future once good multi-homing solutions are in place and there are the technical means necessary to support an alternative to PI.
MR. CURRAN: Okay. Thank you. Back microphone. Jason.
MR. SCHILLER: Jason Schiller, UUnet / Verizon Business.
Gosh, where do I start? Oh, I don't support either of these policies. And I strongly don't support policies that set the bar lower rather than higher. I would say that we should hold off on a policy that's going to allow PI space. And if this means halting v6 to -- slowing it, I think that that's probably the right thing to do.
And I'm not saying this because I believe the sky is falling and the world is going to end. And I'm not saying this because I believe we should wait until we have a technical solution to the problem that does not have deaggregation as its core principal. But I'm saying this because I am not hearing from the court here -- ISPs that are in the default free zone that they've looked at this problem long and hard, and that they've looked at it in the long term.
And the point here is: If we decide to do multi-homing through deaggregation, then we're committing to it for the foreseeable future, because those routes are never going to get out the rounding table.
So, the question is: In the long term, is this a solution that the tier one ISPs and the default free zone are comfortable with had they looked at what this really means 5), 10, 30 years out, had they talked to their vendors to see what their hard work capabilities are going to be 5, 10, or 30 years out? And have they done studies to see that they can actually purchase equipment today that will be living in their network in five years, and five years from today, repeating this process?
Or is it possible that we can get into a solution where -- Me, personally, because of the size of my network, it's a three year process to refresh the network. And I might have to upgrade my network every two years. I guess the point I'm trying to say is: If there are too many routes in the default free zone, nobody gets transit.
MR. CURRAN: Okay. What would be your alternative? Because you said: Can we get into a mode, some other alternative or technical solution. What do you propose? Do you propose that we remain with LPI space until some event?
MR. SCHILLER: Well, I mean, short of getting a protocol out of IETF that provides all the capabilities that we need for multi-homing and traffic engineering, short of that, we should at least strive to have our vendors build boxes that are big enough and at least feel comfortable that, in the future, they can continue to build boxes that are big enough. Did that answer your question, John?
MR. CURRAN: Thank you. Yes, it did. Thank you. Front microphone, Marla.
MS. AZINGER: Marla Azinger of Frontier Communications. I support proposal 2005-1, namely because I need to pick one of the two. And that one seems a bit more simple. However, I'm not happy with the complete way it's written, that things I would personally like to see right now is no subnet stipulations, honestly, because we don't have a land rush issue, we worried about that, it proved not to be a problem, at least so far, so honestly, why aren't we writing some temporary policies that we can implement today and relook in a year or two years.
And why aren't we using specified section as a Z6 block that just allowed the aggregation in multi- home so we can use the technology we have today.
Temporary policies are an okay thing for us to write, that gives everybody a warm fuzzy that this isn't set in stone and we can go change it there, it also gives the people that are working on Shim6 or +A or whatever, that gives them one incentive because yes, they're the ones that are worrying about their routing tables.
So, now, if we start using them, they might actually move a little faster. That -- so I think we should actually just put some perimeters, put some temporary marking on the proposal and move forward with the technology we have.
MR. CURRAN: Okay, in terms of the two proposals, which you'd be for both of them, do you have a preference?
MS. AZINGER: I'm for both of them mainly because I'm for anything that helps move v6 along and get it used because we do
20 not have a problem with land rush, I -- I'm a big network, I'm not in that situation that this proposal is even written for, but I can also understand the fact of why they need it and that we shouldn't be holding anybody back right now from using it because we don't have a problem with the lack of v6 and I don't see it happening in -- it's a certain amount of time that we've got -- gone through, you know, 75 percent of the space or 50 percent of the space where we've got the issues we have with v4.
We're working off of a new block, we're working with technologies -- so temporary policies -- so yes, I'm supporting them because they're moving forward and I picked one of the two because we kind of need to.
MR. CURRAN: Okay, thank you. I should warn people we are going to close the microphones soon, if you care about provider independent space going through or not going through, find a mic, far microphone over then, all right.
SPEAKER: Clarification on 6-4, using the least -- at least 80 percent of /19 so does that mean if I have a /17, I only have to show 25 percent utilization to get a box?
MR. CURRAN: That's correct.
SPEAKER: Okay. I have a problem with that because that -- the person doesn't know how to --
MR. CURRAN: There might be a legacy holder.
SPEAKER: We're not here to solve the problems we haven't before.
MR. CURRAN: Okay. Back over here, Tony?
MR. HANES: Tony Hanes, Cisco. I specifically am against 2006-4 because of the requirement for current employment of v4 -- Other than that, I don't really have any major concerns with it. 2005-1, I would support from the perspective we need something in place and we can change it later.
One of the things that Jason raised is, you know, this is the aggregation and it will persist for ever.
And if we just do this with random assignments, that's true. If we think about the space and we're specifically talking about identifiable block, if we structure that identifiable block in a way that we can aggregate down the road, if we think about that before we actually start handing this out and do some design work up front, it doesn't have to be a long-term problem, we can think about how to -- okay, constrict that routing space over time.
So, I would support 2005-1 because we need something and not 2006-4 specifically because of the issue about current. Thank you.
MR. CURRAN: Back microphone here.
MR. SCHILLER: Jason Schiller, UUNET Verizon Business. I just had a question of clarification about if this was to be a temporary policy.
If we did use this as a temporary solution for multi-home until such time as we can solve this in a protocol and not the aggregate, would we be able to get that space out of the routing table, maybe six months to a year or two years or five years after such a solution was available and viable and if so, would the people who are in favor of provider independent stage to avoid provider lock and become through with the idea that there would have to be number.
MR. CURRAN: Okay, so let me first say, neither policy proposal is marked as temporary. So that they came in without that marking and I'll say a policy proposal says that it would need to be pretty clear because temporary doesn't mean anything unless you put the date in the table that says it's going to expire.
By nature of the fact that -- dynamic organization and we can change policies, there's nothing to prevent this body from two years from now changing a policy and saying, hey, we have a viable solution.
So, as written, neither of these are temporary, people need to take that into consideration while they're voting knowing that, of course, we could revisit. Yes?
MR. WOODCOCK: I would point out that we tried the temporary thing and you guys can go for that, so, let's not revisit things that we already tried and shut down.
MR. SCHILLER: To respond to your comments. There was a third point which was if this policy is revoked, do you think we can get that space out of the global routing table?
MR. CURRAN: ARIN doesn't control the routing of prefixes, okay, the ISP's control the routing of prefixes. Any group of ISP's can carefully get together and decide that they're going to pull prefixes out, okay, I emphasize carefully but there's no reason why, if there was a viable technical solution, that didn't require PI address space and individual routing, there's no reason it wouldn't be adopted.
MR. SCHILLER: Thank you.
MR. CURRAN: Sure. Far microphone.
MR. PALET: Jordi Palet, I actually was thinking something similar that just Jason explained it, I am in favor of 2005-1 but I am really concerned about routing table size and I will like to see somehow a way to -- in a good time, I mean, not just six months but maybe two years, three years, being able to not controlling the routing table but at least claim back the space when there is a good stable and proven technical solution.
MR. CURRAN: Okay, that's an interesting proposal. Jordi, would you be for either of these as written?
MR. PALET: Yes, 2005-1, but I would like to see at the same time this kind of clause that says one sits clear that we have a good and stable and proven solution, let's give enough period of time, not just a short one, not just three months, six months, two years, three years, so, those holders of this allocation can renumber without any inconvenience and apply for the better technical solution.
MR. CURRAN: Can I -- can I just point out, I need to be very clear here.
MR. PALET: Yes.
MR. CURRAN: Because that's a new concept, that isn't in either of these proposals, if we attempted to do that, we would definitely need to restart the discussion cycle because there's certainly people for whom the part that these are provider independent but not permanent might change how they felt about them.
MR. PALET: Yes, I understand that point so somehow, it's a kind of question, if the counsel can decide to take that over existing proposal so we don't wait anymore.
MR. CURRAN: Understood, thank you. Okay, we are back over here. Yes?
MR. BARGER: Yes, Dave Barger, SBC/AT & T. First of all, I'm in favor of moving ahead with PI policy regardless of which one we do, we got to get off the center, we got to move ahead, North America is behind on the whole v6 thing, we got to kick start this and kind of get it going.
So, you're not thinking in that vein, either one of these are good policies? I do like the wording on 2005-1 as far as the eligibility statement rather than, you know, saying you have to have had a specifically assigned /19 or, you know, aggregate 19.
I guess it's conceivable there could be some new company six months from now that never had v4 space but they need a bresilian v6 addresses, so, you know, I kind of like the soften approach of 2005-1.
Regarding, you know, the multi-homing comments and routing table, obviously, that is a big concern, I think we can, you know, spend a lot of time countering up numbers and saying what if and the routing tables are going to explode but I think as long as we, you know, take the wording that's on these and say, you know, we're going to allocate at least a /48 out of a reserve 44 and having done, as you said, the ISPs get together and decide what's going to be reasonable and what's going to -- you know, what we're going to advertise, then maybe we have a discussion either here or some other form a year from now and -- or two years from now and say, okay, what is happening on routing tables, what do we have to tweak, what are we - you know, what do we agree to advertise.
So, I think we need to move ahead with these and get it going and obviously keep revisiting the policies ant tweak them as we go.
MR. CURRAN: Okay, thank you. Back microphone.
MR. BLANCHET: Marc Blanchet, Viagénie. I was going to say "must" but I will say "should", we should have a PI policy soon. I am more -- I'm pretty against 2006-4 for the same reasons people are talking about, which is too much -- I would rephrase it as too much dependency on v4, you know, deployment. I would support 2005-1 if we could, by some means, make sure that we provision for IPv6 only, you know, end sites. Because, to me, if I read it correctly and I put it in my head, /20 or /22, 25 percent utilization, you know, 500 hosts on a network, an IPv4 network with an address plan is something that you could do with subnets and there's some sparks, but on the v6 side, you could have the full 500 hosts on the same subnet, you know, just for the addressing discussion, so I think we're comparing different technologies where I could envision some cases where, you know, IPv6 addressing identification in a plan would not necessarily fit the same way as before. So I'm kind of scared that we should have some wording in -- modification in 2005-1 that would provision v6 only like deployments.
MR. CURRAN: Okay, thank you. I am closing the microphones.
Microphones are closed. If you're not up at a mic, you're done. Okay, far mic.
MS. SETTLEMYRE: Allie Settlemyre, Microsoft. I have a general question, more specific. So if I was given a /32, the minimum routable block is a 32, correct?
MS. SKANKS: For an LIR?
MS. SETTLEMYRE: Yes.
MR. CURRAN: Theoretically, although ARIN doesn't set policy on what's routable.
MS. SETTLEMYRE: But they did in this case.
MR. CURRAN: No.
MS. SETTLEMYRE: It says to announce it as a single -- if you're a LIR, the current policy says to announce it as a single aggregate. A /32.
MR. CURRAN: If you have someone who's willing to take that announcement, you should announce it as a single one, yes, that's the current policy.
MS. SETTLEMYRE: I think -- well, someone pull out 6511, because I'm really sure that it says that the requirement in order to get a 32 is that you assign 48 and that you'll announce it as a single aggregate. That's the requirement in order to get space.
MR. CURRAN: We can pull it up, I believe that might be true. Note that ARIN does not control the routability it addresses.
SPEAKER: Yes, the policy requires you to have the intent to announce it as a single router.
MS. SETTLEMYRE: Yes.
MR. CURRAN: I guess I'll ask -- Do you have a follow up question to that?
MS. SETTLEMYRE: So my problem is if I can chop up my 32 into 48, it works, I can do that, but otherwise I'm going to have, you know, to get provider independent space for all my different ASs? I talked to Marla about this.
MR. CURRAN: Right, the question is whether or not a large ISP will allow you to break up that allocation into pieces and route it. That's indeterminate.
MR. SCHILLER: Actually can I amend that question?
MR. CURRAN: Sure.
MR. SCHILLER: The question is whether or not a large ISP should do this if they want to be a good net citizen.
MR. CURRAN: Right.
MS. SKANKS: Okay, so it's sort of related to Allie's question, and partly what I wanted to say was that 6511 says:
"An organization must provide some activity and assign 48 and advertise that connectivity through a single aggregated address allocation."
So the existing policy to get space says that you will announce it as a single aggregate. For the PI space, there is -- it doesn't include that, so what -- as much as you want to say that ARIN is not dictating routing policy, you are by saying that the minimum allocation for PI would be a 48.
MR. CURRAN: Okay, so hypothetically two ISPs, ISP A and B, walk into a room, sit down and have a drink, and they say, "We have customers that have much in common, and they have address space, and in order to serve my customers' full list of network destinations, I need to actually give you some pieces. But I notice you have a customer too who also has offices that only I can serve, and you need to give me some routes of yours." And they agree to exchange those routes smaller than just the /32. There is no reason that ARIN should be involved in the discussion between those two ISPs of exchanging routes.
MS. SKANKS: So you're saying that we should ignore the fact that it says to not use a single aggregate and go ahead and do what's best for our customers? Then why do we -- so then customers who come to us and want space from us, we can go ahead and like make our own decision about whether or not we should let them multi-home that way, and --
MR. CURRAN: Again, ARIN says you should announce that as a single route, that doesn't prevent any two ISPs from getting in a room and deciding that they're going to do something else.
MR. DELONG: In addition.
MR. CURRAN: In addition, okay. There is nothing to prevent -- ARIN does not have the ability to control the business arrangements between two ISPs.
MS. SKANKS: Yes, it's just -- it seems to go against aggregation, it seems to go against, what, the policy for LIRs is, and then it just --
MR. CURRAN: Those two ISPs have two networks with two routing tables, and if they decide to exchange routes, they decide to exchange routes.
The policy says you have to announce the single aggregate. It doesn't say you can't also announce more specifics.
SPEAKER: I'm sorry, I need clarification. What is the intention of that piece of the policy, and what is the intention of aggregation as the most important step in IP storage --
MR. CURRAN: Okay, let's say the policies on discussion right not are these IPv6 policies. For the sake of clarifying the existing policy, okay, we can answer this, but we actually need to bring the discussion back to the policies under consideration. It is -- the policy that you see there says you should announce that as a single route. That is not an all-encompassing statement of business practices. ARIN does not set the business practices via speeds, okay. So, regardless of what you might want to have in ARIN's policies, we cannot prevent two ISPs from exchanging whatever set of routes they wish to do. Okay? All right, far microphone.
MR. WILSON: Doug Wilson, Microsoft. I'd say as far as this piece goes, I would lean toward the 2006-4, and the reason is it does end up having the minimum bar to slow down the land rush if people are worried about that. I don't think a land rush is a real big problem in the sense that I see it's more like a RF spectrum in the way that if you want to try to get your piece and hold on to it, then good for you, and try to be early on, and -- I mean, v6 has been around for a long time, and you know, I'm personally not a super big fan of it, and it's taken a long time to really pick up, but it does look like it is picking up now, and in that sense, I would say that it's better to have certain minimum bar.
MR. CURRAN: Okay, thank you. Back microphone.
MR. NARTEN: Thomas Narten here. So, I'll spare you of asking the question, I support 2006-4, and one of the reasons is it is -- this is a sort of question back to you, Owen. In my understanding of 2005-1 is that anybody who's eligible for a v4 assignment under the current policy can get a v6 address as well, and my understanding of that, for example, is in the current policy for v4, you can get, for example, a micro-allocation. If you get a v4 micro- allocation, does that make you eligible for a PI allocation in v6? Is that the intention?
MR. DELONG: It wasn't really the core intention of the policy, it was mainly aimed at the 2002-3 and larger assignments, but as a result of the way it's worded, yes, that would probably be the effect, and I don't really have a problem with that effect because I think the number of micro-allocations is pretty small, and I don't think most of them would care about getting PIv6.
MR. NARTEN: Okay.
MR. CURRAN: Leo, did you have your hand up? Okay, got it, last speaker, Jason.
MR. SCHILLER: I had a similar question about the micro-
Allocations, but I also wanted to include the legacy space, like for example, swamp /24, does that make you eligible for PIv6 space?
MR. DELONG: If you have a swamp /24 and you could still qualify for a new IPv4 prefix to be issued to you, then yes, you'd be eligible. If you have a swamp 24 and you're just hanging on to it for your two hosts in your household and you don't qualify for an IPv4 allocation under current rules, no, you would not be eligible.
MR. SCHILLER: Thank you.
MR. CURRAN: Okay, thank you, gentlemen, for presenting. We can actually put that slide back up. It's a good slide. Okay, at this time, we actually need to take a vote, or a show of hands for advising the AC. As I said when we started the discussion, we're actually going to take a vote first on 2005-1, asking for everyone in favor and everyone opposed. Then we're going to take a vote on 2006-4, asking everyone in favor and everyone opposed. I ask if you're in favor of the proposal, that you vote in favor. If you're against the proposal, you can vote against. Both of these will go to the AC to help them in discussion with the authors to try to determine how to best move forward. As always, Scott.
MR. BRADNER: There we go. Scott Bradner. I would like to suggest two additional votes. One is I oppose both, and the other is I support either. The latter specifically so the AC can look at it and say -- make up their own mind on either one, if indeed that was the support for that, that allows something to go forward without having to go through another process cycle.
MR. CURRAN: You would suggest a total of four votes?
MR. BRADNER: That is correct.
MR. CURRAN: And do you have a preference of order?
MR. BRADNER: No. Jason?
MR. SCHILLER: Jason Schiller, UUNET/Verizon Business. If you're going to do additional votes, then maybe you should also consider "I support both but I support 2005-1 more" or "I support both but I support 2006-4 more".
MR. CURRAN: Actually we've had -- I understand the reason for asking that. Okay. So, it's an interesting challenge to make sure everyone knows what they're voting for, okay. And so, I will -- we will first vote for the proposals individually, okay, and then we will vote for whether or not we should have a proposal here at all following Mr. Bradner's suggestion.
So first, it's a simple vote, it's whether or not you want to have -- whether or not you support Policy Proposal 2005-1. I'm going to ask all in favor and then all opposed. Everyone in favor of 2005-1, raise your hand, nice and high. Nice and high. We have a vote. Okay, put your hands down. Everyone opposed to advancing Policy Proposal 2005- 1, please raise your hand. Nice and high. We have a vote. Thank you.
Okay, on the issue of 2006-4, everyone in favor of 2006-4, raise your hand, nice and high. Everyone get nice and high. Everyone opposed to Policy Proposal 2006-4, please raise your hand. Okay, we have a vote.
Okay, now, this next one's interesting, and I'm going to propose we do this actually in one vote, and the vote I think we'll summon is, basically I'm going to ask if you believe that we should advance a proposal, any proposal, for provider independent PIv6 space, I'm going to ask you to raise your hand. If you do not think we should advance any proposal -- I'm sorry, if you don't think we should advance neither proposal --
MR. BRADNER: John, let's try this again. I want to know whether people want to blow all the proposals out of the water, just say no, that should be one question. Do you support just no, not forcing anything through, and the other is do you support either proposal. You could let the AC decide on proposal A or proposal B, but either one I support just going forward. We've heard that a number of times, was, let's do something.
MR. CURRAN: You're actually proposing four shows of hands there, correct?
MR. BRADNER: No, I'm just proposing two. We know how many people are in the room.
MR. CURRAN: So again, phrase both questions, because I want to be clear. That's what I'd like to, but I want to make sure I have those questions.
MR. BRADNER: Question one, I do not support forwarding any proposal. Any of these proposals. I don't support put forward either 2005-1 or 2006-4 now. That's the first question. Second one, I will support the AC choosing either 2005-1 or 2006-4, up to the AC.
MR. CURRAN: Amazingly, that's exactly what I wanted to do.
So we're going to ask for two show of hands, okay? And I believe they're to be opposite sides of the coin, if we define the coin correctly, okay. The first one is, it's going to be if you believe that neither of these two proposals should go forward, okay? Neither of them should go forward, I'm going to ask you to raise your hands. And then I'm going to ask a show of hands for people who think that either of them should. So first, everyone who believes neither of these proposals should move forward, please raise your hand. Nice and high. We have a vote. Okay. If you believe either of these proposals should advance, raise your hand. This should be the sum of people in the room, minus me, so come on. Between the two, that's everyone. We have a vote. Thank you.
I'm waiting for the results. Bill?
MR. DARTE: I would just like to say for those of you who might have some concerns about that last vote, either of them in the AC making a decision, the decision that we might make in choosing would be based upon those previous polls that just took place as well as stuff we got off the PPML previously.
MR. CURRAN: The AC is made up of really bright people elected by you for their expertise in this area, okay, and they pay attention to the PPML and the discussion, and they working with the office will come up with something. I'm waiting for the vote. While I'm waiting for the vote counts to come in, yes Jason?
MR. SCHILLER: Yes, I just had a question for interest, I wonder how many -- what percentage of the voting hands represent an ISP in a default-free zone, just out of curiosity?
MR. CURRAN: Hold it, I call for a show of hands, okay, and I guess, why would you ask the question? Because we haven't discussed the topic at all.
MR. SCHILLER: Well, because -- just a factual question.
MR. CURRAN: Oh, so you'd like -- the question you'd like to know is how many people here operate an ISP or use an ISP, or --
MR. SCHILLER: Operate an ISP and are in the default-free zone?
MR. CURRAN: Okay. Or think they're in a default-free zone. I just want to clarify this confusion for years for some people. Okay, just for Jason's edification, if you operate an ISP in the default-free zone --
MR. DA SILVA: John, can you define that for the audience, please?
MR. CURRAN: I think I did. If you believe you operate an ISP in the default-free zone, please raise your hand. So there's a few. Keep them up, we're counting. I don't know how many notepads our people have but they're grinding these things out. This is like confessing your sins. We have a count, thank you.
MR. BRADNER: Actually I'm afraid I might want to ask that count again, just to be clear. If multiple people from the same ISP voted in favor or against some of the proposal, we're asking -- we'd like to know how many of those people were doing so with some knowledge.
MR. CURRAN: Well, hold it.
MR. BRADNER: So, there was some discussion of you can't vote if UUNET can't vote twice. Well, if UUNET voted twice on the other proposals, they should vote twice saying that they --
That's one question, the other is what percentage of -- what percentage of gage of the number of folks who might have vote for one of these things would somewhat knew what they're doing.
MR. CURRAN: Folks, a little bit of order. So, the question was phrased whether or not a person operated an ISP. If you've got five guys from your company, you may have had five hands up and people need to understand that.
All right, I need to give people -- I have a lot of paper up here, okay. So, okay, policy proposal 2005-1, those in favor, 55 in favor. Those opposed, 12.
Policy proposal 2006-4, those in favor, 26 in favor. Those opposed, 17. How many believe that neither policy proposal should go forward? Four. Sorry, six, thank you.
How many believe -- how many believe that either of them should be advanced? 60. Thank you very much, this information will be forwarded to the advisory counsel for their deliberations, at this time -- oh, at this time, we get to know about the fall free ISPs.
The default free zone, we had 20 shows of hands in the room. Thank you very much.
MR. BRADNER: I should note that the ice cream is melting.
MR. PLZAK: Okay, Scott, I was going to note that but thank you very much for that timely intervention. We will now take a break, do I have any announcements? Okay.
And it is now 3:30 by my watch, so, 3:45, please be back in the room, we have another substantial discussion ahead of us this afternoon, so, please come back as soon as you can so we can move on. RECESS
MR. PLZAK: Before we get started, at the previous -- before we started the previous session, I mentioned that this will be raffled up tomorrow for those who visit the Cyber Cafe at 8:00, what I neglected to tell you is that the contribution of this is coming from Shaw Communications, they're sponsoring, so Shaw, thank you very much.
Okay. We are behind the times on the agenda but we will move through. I have good strong confidence in my Chair, I hope everybody else does to.
MR. PLZAK: Anyway, we are now at policy proposal 2006-1, Residential Customer Privacy and there is a change to current policy to require the entire address for residential customers, the AC shepherds are Marla Azinger and Paul Andersen where they introduced -- in January of '06, a form of proposal on 26th of January '06.
This is the first public policy meeting and discussion of it. From a staff assessment as far as implementation, impact is significant because it's going to require template changes, registration software changes, skyline change, staff turning and directory services change.
Legal risks, counsel is present, I will read this.
"However, this type of policy may have a series of impacts in different portions of the Internet community. Let me give you a single example: Law enforcement authorities have a desire for real -- to obtain information of the types that will now be met, this may increase the burden on ISPs -- contact them more often to obtain such information, the governments might wish a different policy, each as a customer privacy and how ARIN's policy -- these issues remain an error of ongoing legal concern and attention." Staff comments: "The proposal as written could be interpreted -- no longer provides different country information on the reassignment template. ARIN must continue to collect this information in order for forum verification, reassignment information and utilization. ARIN could not implement the proposal as written and continue to perform verification of reassignment information and utilization." About 27 posts on the PPML by 11 people, here are the comments and I will ask Sam to come up and do the presentation.
MR. WEILER: I'm hoping to give you a very brief introduction of the proposal, maybe the simplest proposal in the packet.
As I look at this policy, I said, well, what does this mean, it looks like, as a residential customer, I could ask my ISP if they're willing to blot publication of my home address in the WHOIS.
Well, it turns out that's not exactly what ARIN staff interpreted the policy to be. They took street address here to mean street number and street name and that city state and zip code are still required.
I thought that was a bit odd, I went and dug back to the history and looking at the policy before 2003-3, I think their interpretation is arguably correct, arguably.
However, I wondered why was I confused, was this a reasonable confusion. And if you look at the discussion around 2003-3, if it restated the prior policy, using the words residential address information, in much broader phrase, and that was the same phrase that appeared on slides in Memphis three years ago and I couldn't find anything in the minutes or in the recording of the public policy meetings that highlighted that city state and zip would still be required in reassignment of templates to residential customers.
There were two posts about that on the PPML, I hadn't noticed them at the time, I noticed them again this past fall when I went back to look at this.
And mostly other discussions on the PPML just talked about addresses and to me, it seems that it was talking about the entire address, certainly that was my interpretation.
I suspect, given the discussion, that was the community's interpretation. So, I'm proposing a clarification to 2003-3 striking out the word street from street address replacing it with entire address.
And the corresponding change to a related policy which is 2003-5 having to do with directory information services, striking out several words including the state and zip code which are not applicable in all of their service areas.
The policy proposal is on the next slide, this is the -- really substantial bit of it. I will note that there has some discussion on the PPML on the last few days about business or non-residential customer privacy, I think that's an interesting discussion to have and I hope we have it.
However, from the -- well, from what I saw on the list, that looks like a very controversial discussion.
And what I'd like to do is discuss this given that perfect maybe -- if good and see if we can get a good change and then continue to work on something better for non-residential customers or for all customers.
I'm responding briefly to the staff comments which I just found out about last night. Staff saying that they must have city, state and zip code in order to evaluate utilization.
I'd like to get a little bit more information about that, where they're now on the PPML, I imagine that the staff has some -- for evaluating utilization of addresses that don't have to be reported, where customers using addresses because they don't have to be reported, blocks for PPP and dialogue.
And I'd be really surprised if you can find a reasonable -- to evaluate the utilization for these blocks as well, so I'd like to probe that a little bit more and if we can't do that today, so be it.
And I can put this back up later if we need it but here is the text of the proposal.
MR. CURRAN: Okay, microphones are opened, we have three microphones, plenty of room. Okay, Mr. Bradner.
MR. BRADNER: Scott Bradner. Oh, the microphone works. A clarification question: This says that the ISP doesn't have to pass the information to ARIN, not that it's not displayed, is that correct?
Because the problem you're trying to solve is that it's not publicly available, that's a different question than whether the information should be provided to ARIN.
MR. WEILER: I don't think we've ever made the distinction between which customer information must be passed to ARIN versus displayed.
MR. BRADNER: The reason I bring it up is specifically the kinds of things that counsel brought up which is that we may actually have some very interesting discussions with law enforcement if we can't provide that information. Not that it means to be displayed but --
MR. WEILER: Okay.
MR. BRADNER: -- comes across and says --
MR. WEILER: If someone would like to argue that that information needs to be held at ARIN rather than just at the ISP -- is that the argument you're making?
MR. BRADNER: Well, I see it's pointed out and it's pointed out as the discussion we had in the past on this when law enforcement was in the room that they would like one place to go. They don't want to be tracing ISPs in the middle of the night. They want one place to go.
MR. CURRAN: Okay. My question to you is: Is your proposal such that this information is not displayed and could it -- would you believe you could interpret it as supplied to ARIN or not supplied to ARIN or you're specifically saying your proposal is it's not provided to ARIN?
MR. WEILER: The proposal as written would allow the ISP to not give it to ARIN at all.
MR. CURRAN: Okay. Got it.
SPEAKER: Is that the current policy?
MR. WEILER: I believe -- let's ask Leslie.
MR. NOBILE: Currant policy on supplying of information for downstream residential customers.
SPEAKER: Is it a change, this part of the policy?
SPEAKER: Currently, you can put private for the -- just the street address and you can substitute the customer's name.
MR. WEILER: And ARIN wouldn't see the street address.
SPEAKER: We would not see the street address but we would see the city, state and zip. Much of the time, we will see the name. It depends on what the ISP sends. Sometimes, they'll send their name or an actual customer name. They have the option.
MR. CURRAN: Okay. So, presently, ARIN accepts people who do not supply the street address but city and zip and your proposal is -- your proposal is to replace the entire address, allowing the omission of the city, state and zip in addition to the street address, right?
MR. WEILER: Correct.
MR. CURRAN: Okay.
MR. WEILER: And even country.
MR. CURRAN: And even country. Okay. So, people are at the mics. Owen?
MR. DELONG: Owen DeLong, Netli Networks and I strongly oppose 2006-1 as written. I would accept a clarification that allowed zip or postal code to be limited to the first three characters in the case of Canadian postal codes, the first five digits in the case of U.S. zip codes. I think that's sufficiently anonymous to cover the privacy concerns.
MR. CURRAN: Okay. Far microphone over here.
MR. LOEVNER: Mike Loevner, Verizon Internet Services. I don't support the proposal either. I agree with Owen.
MR. CURRAN: Okay. Far microphone left side.
MS. AZINGER: Marla Azinger of Frontier Communications. I do not support this proposal and along with Owen's comments, I would support a proposal that includes five digit only in the U.S. and three first digits of Canadian postal.
Also, I oppose in this as the word -- the use of the word "may" in the second sentence. I don't believe it should be a choice. It should be yes or no. We do it or we don't.
MR. CURRAN: Okay. Central mic.
MR. DIVINS: Dave Divins, ServerVault. I strongly agree with this proposal but I also have no problems with an amendment that would say the full information does get sent to ARIN but the public WHOIS records are --
MR. CURRAN: Okay. Microphone over there.
MR. BARGER: Dave Barger, SBC. I am somewhat in support of this policy change. The thing now, I think we're missing a larger issue and it's about time we deal with it and I think it has to do with, you know, what do we provide ARIN versus what do we publish in WHOIS. You know, how do we really handle the privacy issue.
I can understand the issue of the law enforcement wanting to have one place to go to to get information. At the same time, you know, the ISP is supposed to provide abuse and technical -- We're supposed to have the information on hand. We do have the information. But, you know, we try to keep tweaking this over the years and we keep putting little band-aids on it. We keep wordsmithing one or two words here and there but the big issue is what is -- you know, we need to take another look at WHOIS. What is the value of publishing customer private addresses in WHOIS? Do we have to do it? Can we give it to ARIN? Can we not publish it? And I think that's really the bigger thing that we need to be addressing here is, again, what is the value to it, like -- if we're going to keep it out, let's get it out and from an ISP's perspective, you know, I have no problem providing ARIN, you know, full customer information: street, city, state, zip code, whatever it takes. That's easy to do. But let's just keep it out of WHOIS.
MR. CURRAN: Okay. Thank you. Central microphone back.
MR. DILLON: Michael Dillon, BT Radianz. I am strongly in support of this proposal. I think residential privacy is important and I think that as stated, it's a good proposal that covers the bits of the existing policy that need to be changed.
I'd like to comment on the staff comments on this issue of providing ARIN information.
First of all, I don't think that this is going to limit the staff in any way because what the staff does when they analyze a company's usage is for additional allocations. This is completely separate and different from what we're talking about here. What we're talking about here is ISP submitting information to be listed in the WHOIS directory.
Now, I know there's a bit of a fuzz here, eh? Because ARIN can and does use that same set of information to do an analysis and if that information is sufficient, I imagine that they don't bother asking for any additional information.
But we've all signed -- well, at least I think we've all signed NDAs with ARIN. I know my company has signed an -- or ARIN has signed an NDA with us.
MR. CURRAN: ARIN has signed an NDA with all the companies.
MR. DILLON: Right. And in the past, we have provided various different types of information to ARIN. In fact, we usually provide a dump of our database in a CSV format for them to load up in whatever tool they use to analyze it. The policy we have in place says something like -- I think there's a /29 boundary. If you allocate somebody a /30, you don't have to put it in WHOIS. Whereas when we submit the stuff, we'll include those.
As far as I know, it's completely open ended what information ISPs have to provide to ARIN but simply if ARIN needs it, they'll ask for it at an ICS to provide it. And it's under NDA. So, it's completely secret and ARIN won't tell anybody and won't put it in any WHOIS database and, as far as I'm concerned, that issue doesn't have anything to do with this.
MR. CURRAN: Okay. Counsel?
MR. RYAN: I have a question and I was before Congress last week and the congressmen are confused about it and so am I. So, let me ask you a question and see if I can get a reading from the room. Let's assume for the moment that just for purposes of argument that ARIN doesn't have immediately accessible to it data about such residences and where they are. Is it correct that the ISP would maintain such data and how long is the period that you would have it so that if law enforcement wanted to find out where a particular IP address matched up to a residence and customer information, how long do you keep that?
Because there's a legal regime of some import here that I need to just understand what the ISP practice is because it impacts what policy we may have to have as a matter of law.
MR. CURRAN: Okay, so, that's Steve Ryan, ARIN's counsel and he has a point of enquiry and it's for those ISPs in the room. And Steve, you're asking how long, meaning how far back --
MR. RYAN: How far back in a temporal sense.
MR. CURRAN: So, if someone -- if I wanted to know the address for an IP -- if I want to know the street address for an IP address, six months back or a year ago, how far back could people go? If you want to answer that question, don't do anything other than raise your hand and I'll just -- just spit out the time. Raise your hand. How far back -- come on, folks -- how long can you match an IP address to a street address? So, four years ago, if I gave you an IP address and I said, "Where was this four years ago?" You can tell us. Okay. Other people, Owen?
MR. DELONG: I might be able to give you a caller ID --
MR. CURRAN: You might be able to give me a caller ID but how far -- how long back in time can you give me a street address?
MR. DELONG: Never.
MR. CURRAN: Never. You can't give it at all. Yes? Eight years. Other folks? Bill?
SPEAKER: For the fixed ones, probably 15 to 18 years. For the dynamic ones, 20 minutes.
MR. CURRAN: 20 minutes for the dynamically assigned ones. Yes? When the contract terminates, how far past contract termination? A year or so. Other people? I only want to have this answer. How long? 31 days for dynamic customers. Other people who know their practice? Yes, over there? For about a year. Other people? Yes?
SPEAKER: For dynamic customers, six months.
MR. CURRAN: Six months for dynamic customers. So, Steve, that gives you a range. Note particularly dynamic customers are interesting compared to static ones. Those are the ones who come in temporarily and disconnect.
MR. RYAN: I think just for informational purposes, and I don't know how this affects your debate, Congress is contemplating requiring ISPs in the United States to have that information available for one year back at a minimum as a law matter. But I'm not aware that there's a current statutory requirement with regard to that. There may be but I'm unaware of it.
SPEAKER: Clearly, the problem here is we're going the wrong direction. We're asking engineers to give the street address. But if we ask the marketing people to keep an IP address, it'll stay there forever.
MR. CURRAN: Right. Okay. Thank you, Steve. I don't know if that helped. So, Bill, comments, far right side.
MR. WOODCOCK: Yes. I look at this and I ask myself what would the difference be if I was to remove the word "residential" or "residence" from the proposed wording and would that make a difference?
MR. MANNING: Just speculating -- Dr. Manning. There's been a lot of discussion about something similar on the PPML for the last two days. That was very controversial.
SPEAKER: I've been following that. The thing is is that some people's residence -- it seems an arbitrary distinction in some cases as to what is residential. So, anyway --
SPEAKER: Bill, would you support the proposal as worded? It's a yes/no, Bill.
MR. MANNING: My conscience says no.
MR. CURRAN: Okay. Thank you. Microphone in the middle?
MS. WOOLF: Yes, sir. First of all, I'm Susan Woolf, ARIN AC and ISC. First of all, for Bill, yes, the distinction might very well be that natural persons are distinct from companies although you, as often is the case, are a corner case.
I'd like to sort of suggest that as people consider what they think about this, I'm in support of the proposal, and I'd like to suggest that the way to frame the question is in terms of: Are the justifications offered strong enough to justify what amounts to people's entitlement to privacy. Privacy arguments tend to converge around, "Gee, why would people want to suppress this information?" and "Is it worth the inconvenience to whoever wants it to have it suppressed?"
I think that's the backward's question. That's backward's of the right question. The right question is: What justifies requiring people to give out personal data?
What we've heard so far is registration services use it and law enforcement. Through some combination of cooperation with law enforcement and then some issue of compulsion.
It's really important that we be clear on what the justifications are for asking people to disclose rather than we ask them to justify why they wouldn't.
MR. CURRAN: Okay. Far microphone. Mark Kosters.
MR. KOSTERS: Mark Kosters, VeriSign, ARIN AC. As I was looking through the number of resource policy manual it's actually -- this is referenced three times. Two times with the exact same language and a third time, it has different language; it is actually specifically enumerated out. And that is something that I think we should probably fix because it is U.S. entry.
The other parts about in terms of what should be kept and what ought not to be kept is actually -- it needs to be held in sort of a larger context which I think it's -- this proposal in itself does not satisfy. So, we need to address that but address that in a holistic perspective and not just dealing with a few words up here.
MR. CURRAN: Okay, Mark -- wait, wo, wo, wo! Back. You don't get off that easy. So, presuming that, as a result of any change, we do harmonize all the references to this in the policy manual, would you be opposed or against this particular proposal right now?
MR. KOSTERS: I don't have enough information to say that I'm forth or against it.
MR. CURRAN: Okay. That's fine. Centre microphone.
MR. HANNIGAN: Hi, I'm Martin Hannigan with Renesys Corporation. I'm a member of the technical staff and I oppose this policy as written. I would support it if it was first three Canadian and first three U.S.
My company uses this data as input to geolocation with other companies and I think this is a big break for me and I don't know that that's be thought out enough and I would like to hear more from people like how this affects them and I know that none of them are in the room today. They do a lot of geolocation work. Thank you.
MR. CURRAN: Okay. Yes, Heather.
MS. PETROVICH: I just wanted to say that for us, we have some operational need to be able to see certain information and could or would this policy be modified -- so, if a customer wanted to be multi- homes and we couldn't see who the block was to, how would they do that? I mean, the odds of a private residential customer wants to be multi-home, they're probably not so good but did anyone think of that or --
MR. CURRAN: So --
MS. PETROVICH: You are? So -- I mean -- is there some mechanism to address that other than having to, you know, contact the person's provider and say, "Is this really, you know, assigned to you, your customer block"? So, we use it kind of in an operational sense to evaluate someone's request for additional address space by being able to look at what they currently have and then I'm guessing so -- if they have -- if you need this, it means that you're talking about private customers who have something larger than a 29 that's requiring it to be flipped, so, is it also a customer's -- residential customers who have something larger than a 24 that they might want to be multi-homes with it. That's my first question.
MR. CURRAN: Let me ask to clarify that. At present, these customers show up as private customer, only their street address is included. Does that work for your current operational needs at present?
MS. PETROVICH: As long as they don't want to be multi-homes.
Because if -- if they came to us and it's a private customer, we'd have to go to the other provider and say, "Can you verify that we're allowed to route this block for your customer?"
MR. CURRAN: Does losing the street address information make that a bigger or smaller problem?
MS. PETROVICH: If we can verify the street address information, then that helps to some extent.
MR. CURRAN: Okay, so --
MS. PETROVICH: The street address information is public and we can look it up somewhere and say that, yes, that street address belongs to so and so. That, at least, helps us in one direction to be able to not have to -- you know, intervene with another provider.
MR. CURRAN: So, this makes it harder for you to verify someone who may be looking for multi-homing.
MS. PETROVICH: Correct.
MR. CURRAN: Okay.
MS. PETROVICH: And then my second question, and I'm not a lawyer, so -- but comes from our legal department and our legal department said that -- we asked them to evaluate this and in terms of Canadian privacy laws, and they couldn't find anything -- they weren't sure what the problem is with Canadian privacy laws. And so, they wanted some clarification on that and they said that the only law that they could find was Pepita and -- so, they didn't see anything in the Canadian -- no, it was our U.S. legal team but they're -- I mean -- I don't know who they asked it, I don't know what research they did but they were just looking for more, you know -- for me to ask you if there was more information that could be provided.
MR. CURRAN: Okay. So, I think actually you should take that one off with Steve Ryan for that information to your legal team.
MS. PETROVICH: Thank you.
MR. CURRAN: If any of you folks have lawyers who have questions about our policies, you can talk to Steve and he'll get your lawyers oriented in the right direction. And we do pay for that all the time actually. Okay. Yes? Centre mic at back.
MR. BUSH: Randy Bush, IIJ, 3130. First of all, I think we've been around this time after time after time. I thought this is what it said years ago essentially. I thought this is what it meant. The fact that we are revisiting this I think underlines what Susan was really saying is there really are deep underlying uncertainties and social issues here, namely the privacy one which I happen to agree with your position on and the operational need.
On that, what Martin, even though I'm in the same position, one of my hats is researcher in geolocations of issue, my personal feeling is that privacy is more of an issue.
From the operational need, what I care about is that if there's real operational problem, that I can go somewhere and say, "Hey, I have this real operational problem and even if it's a level of indirection in the contact, that solves my need". It's the same thing with other indirect means making contact. When we had the old Internet register -- Internet manual, it was still -- some things were kept private and I just -- I don't see the need for me to be able to contact a residential customer unless there's an actual operational problem, and then I can contact that customer's ISP who knows how to contact them.
MR. CURRAN: Would you be for this proposal as written, Randy?
MR. BUSH: I am for this proposal as written.
MR. CURRAN: Okay. Thank you.
MR. BUSH: I think it rewrites what was already the understanding nine times around the tree here.
MR. CURRAN: Okay. I am going to be closing the mics on this topic. If you need to speak, please approach the mics. Yes?
MS. WOOLF: I'm Suzanne Woolf, ISC and ARIN AC. Sorry for taking up more microphone time. I think I've been at the microphone more today than I have been in the last three meetings. But I just want to thank some of the other commentors for underlining my point. Everybody has a reason why they want the data, but I -- you know, some people want geo- location data, some people wanted to make their jobs easier, some people want it for research purposes. Well, as it turns out, I want a pony, and also, I would like my address suppressed under the conditions we're discussing. I would suggest people think very hard about what makes those other needs more important than mine.
MR. CURRAN: Got it. Andrew, you wanted to say something?
MR. DUL: I did. I've heard a couple of people talk about would it be okay with suppressing city and state, but we want a five digit US zip code, or three digit Canadian, or even a three digit US, and I'm wondering what's behind that. Now, we've heard some needs expressed, but I'm wondering if there's an assumption under there that, using three or five digits of the US zip code will always specify enough people that you get some meaningful privacy. I think that's a false assumption, and I'd really -- but what I'm hearing in there is that they're still -- we're okay with suppressing residential address information to some degree, and those who are suggesting the three and five digit zip codes are talking more about to what degree.
MR. CURRAN: Okay, so just on that one topic, does anyone want to speak on why three digit, three letter Canadian and five digit US gives you an appearance of privacy?
MR. DUL: Or three digit US, which we also heard.
MR. CURRAN: Well, yes. Anyone want to -- Owen?
MR. DELONG: I was saying that I was fine with suppressing the street address, not the city and state portions. I would like to retain city, state, and first three Canadian or first five US zip, Canadian postal code, sorry. So, hopefully that clarifies the issue. And when you say that that's giving some reasonable measure of privacy as a false assertion, I can only think of really extreme rural corner cases where that would be true.
MR. CURRAN: Someone yelled out US Virgin Islands in the back. I can give you data on that, Owen.
MR. DELONG: Okay, go ahead Marty.
MR. HANNIGAN: Martin Hannigan, Rensys Corporation. I'm not sure I understand, so I support Randy's privacy, but I also support being able to conduct business, and in this particular policy, if the customer's name is already private, what more needs to be hidden? I mean, I'm not going to find someone -- if the identifier is 021, I'm really not going to find them because that just means the City of Boston. So I'd like to get some clarification on that.
MR. CURRAN: Response?
MR. DELONG: I can take that. Why don't we let Matt go and I'll come back to that.
MR. CURRAN: Okay, Matt?
MR. POUNSETT: Matt Pounsett, I'm from CIRA and the ARIN Advisory Counsel. I support the policy as it's written. I think it's good enough, but I think we can probably do better too. I thought Leo's proposal last year went a long way to getting that by setting scope for what -- who it is, and we should -- maybe this is something for the open policy of next year, or in the fall, but might be good to go looking down that direction because it would make a lot of these discussions a lot of easier if we actually decided what we were trying to get out of it as a community rather than each individual person in the community having their own ideas about what it's for.
MR. CURRAN: Okay. Someone over there, okay, I think we've run out. Did you want to respond to the postal?
MR. DELONG: Yes, I did. In the security research community, there's actually some research on privacy and anonymity, and there's a technical term called the anonymity set, which is the number of individuals from which you can't distinguish a particular actor. If you have this individual can't be distinguished from these 500 or 1,000 or 20,000 other individuals. And as that set gets smaller, you run more chances of them finding an individual, right? Now, where can you get information to wheedle that set down? You might get from the address, from the zip code, and I'll show you some numbers, hopefully make an -- I want to come to this machine here.
But you could also get that information from other heuristics. For instance, of the people in the room who have residential customers who have reportable reassignments, do any of you have more than 1 percent of your customers that have reportable reassignments of your residential customers?
MR. CURRAN: What's reportable reassignments?
MR. DELONG: Assignments that would have to be separately reported in WHOIS.
MR. CURRAN: 29 or bigger.
MR. DELONG: 29 or bigger.
MR. CURRAN: Stuff you'd have to --
MR. DELONG: How many of your residential customers have 29 or bigger? Fewer than a percent across the board?
MR. CURRAN: It seems to be less than 1 percent. It's an aberration.
MR. DELONG: Yes, right, exactly. So, if you had for instance a zip code that had 1,000 households in it, and you could tell, you could guess which 1 percent might reasonably have their own /29, if you ran into one of these private address, you only have 10 doors to knock on to find the right person, and if you happened to know because they posted it on a blog somewhere that recorded their IP address that they drive a red pick-up truck, even if you don't guess the right 1 percent, you're probably still bound to about 1 percent just based on the red pick-up truck. There are a lot of ways to wheedle down that anonymity set.
And so --
MR. CURRAN: Are we switching --
MR. DELONG: I guess it didn't -- oh well. I'll just read it. I grabbed some US census data, some of which is tabulated by ZCTA, zip code tabulation areas. They don't exactly match zip codes but it's a close approximation. And of 33,000 some ZCTAs, of which we can discard 960 because we don't have any households in them, some of these households have people which is a bit of anomaly. The data has some interesting corner cases, but it forms a good enough approximation. Approximately half of them have fewer than -- oh, there's the number -- 1,100 households, and approximately 8 percent have fewer than 100 households. Having small zip codes is not that uncommon, and someone gave me an example of a Boston zip code, and we have a case actually at the bottom of this slide of a Washington, D.C. zip code 23 households in it. I didn't go looking for this, it just jumped out at me. Hm, there's a D.C. Zip code with only 23 households? This is odd.
MR. CURRAN: Marty, you wanted to respond?
MR. HANNIGAN: So, based on the original points about three points, this is flat because this is a five point zip code. And also, I also object to the presentation because it wasn't included to the rationale, only in that we haven't had enough time to analyze the data and possibly counter it in opposition to your proposal.
MR. DELONG: I'll post it. Okay?
MR. HANNIGAN: How about tabling it?
MR. DELONG: Okay.
MR. HANNIGAN: We can work together and figure it out.
MR. CURRAN: So the -- the point you make is that five digit zip codes could be sufficiently small in households that they don't afford a sufficient level of privacy?
MR. DELONG: I would say almost certainly are.
MR. CURRAN: And do you assert that for three, the first three digits of the zip code?
MR. DELONG: I don't know, I didn't run the analysis on that.
MR. CURRAN: Okay. Okay. Microphones are closing now. I see one person, Mark, are you up or are you stretching?
MR. DELONG: One thing to say about zip codes, this is about US zip codes. We have more than one set of postal codes in the ARIN service area. Do we really want to go picking this apart for each of them or would we rather have a straightforward and simple policy that covers them all?
MR. CURRAN: Right. The policy as stated covers them all because it simply states it's to be excluded. Okay. Mark?
MR. KOSTERS: So one of the things that you asked me about before was, so Mark, if you were to change things, what would you change or would you support it as is? And I responded I don't know, and I should probably enumerate why I don't know, it's because there's multiple factions at play here. We have privacy advocates on one side, we have legal law enforcement, trademark and a whole bunch of other communities on the other, and we need to bring them all together to come up with some sort of cohesive policy that they all agree to, because if they don't, we're always going to run into an issue of having too much or too little, and right now, we're just going to waffle back and forth unless we get that taken care of.
MR. CURRAN: So what would you recommend for advancing this?
MR. KOSTERS: So, a while back we were talking about this with WHOIS, about how much information we should have through WHOIS, and it was Leo Bucknell's proposal, and one of the things that was brought up is the scope and purpose of that directory service, and this actually applies to the scope. How much information should ARIN have, how much information should it provide to people, and what forms of information should be given to what types of people.
MR. CURRAN: Right. Now, when that proposal came before this group, the directory service proposal that Leo did a great job on, there was insufficient consensus to move forward with it. So we still have, whether it's looking at a micro level of one particular bit of data, or a macro level for all policy in WHOIS, we don't have a sufficiently uniform body of knowledge to make consensus on.
MR. KOSTERS: That's correct, and we actually need to -- it out and start looking at requirements, and actually start from ground zero on this, because we're hitting it from halfway through right now.
MR. CURRAN: Okay, thank you, Mark. Microphones are closed.
At this point now, we will actually ask for a show of hands. Thank you, Sam.
There has been a lot of good discussion, but no bodies of consensus to move on, so I'm going to ask that we do a show of hands on the proposal as written, which is in your information packs and online, and this is 2006-1, residential customer privacy. I'm going to ask for everyone in favor and then I'm going to ask for everyone opposed. So it'll be a simple vote, unlike the last one.
So I have my pollers out and ready. I ask everyone who is in favor of policy proposal 2006-1 for residential privacy, please raise your hand. Nice and high. Probably the last show of hands for the day. You can give it everything. Okay, thank you. Everyone opposed to 2006-1, residential privacy, please raise your hand nice and high. Okay, thank you.
And the votes are coming this way. For some reason, they move in the opposite direction before they get to me, but --
Okay, all those in favor is 28 in favor; opposed, 27. Thank you.
MR. PLZAK: Thanks, John. Okay, we still have two more items left on the agenda. First is Dave Deitrich to do a presentation on bogon filtering for fun and profit. And there he is. And then, after that, we will do an open mic session. So -- okay, Dave?
MR. DEITRICH: Hello again. For those of you who didn't see me yesterday, my name is Dave Deitrich and I'm a member of Team Cymru I'm here to talk briefly about bogons, bogon filtering, and some of the services we offer to assist in bogon filtering.
I'm sure that probably everyone in this room has at least a general definition of what a bogon is. Our definition of a bogon is a prefix that should never show up in the Internet routing table. This includes things like martians, private addresses and reserve addresses, and unallocated space which has not been assigned to an RIR by an -- I guess. And we like to refer to the IPv4 address space link at the bottom for easy determination on what is and isn't a bogon, even though some people dispute that list.
So why filter bogons at all? Well, for one reason, to prevent bogons you're using in your network from going out into the Internet, and more practical reason, because bogons are used both spoofed and non-spoofed for spam and bios attacks. Some figures, in 2001, Rob did a study on attacks IBM experienced, and found that 60 percent of the traffic generated by these attacks consisted of bogon addresses. Another more recent study, in 2005, one attack that we had some visibility into consisted about 12 percent of incoming traffic being sourced from bogon addresses.
Yesterday, one of the questions was, okay, attacks aside, how many bogons do we actually see in the routing table? So, I went through our route server information from the past 30 days and dug up that we saw - and this is just our point of view - 87 distinct prefixes ranging in size from a /32 all the way up to a /13. Most of those looked like they were configuration errors, six of them stood out because we were seeing them on at least 25 peers, which is more than half of the people peering with us, and as you can see, most of them were pretty brief, one of them's been in there for two weeks, and is still in there as of this morning, when I looked. Now, I'm not saying any of these ASNs are necessarily bad or doing bad stuff, it's just we have noticed them leaking bogons into the global routing table.
So, why wouldn't you filter bogons? Well, the thing you've got to keep in mind with filtering bogons is that bogons change regularly. Unallocated space eventually gets allocated. As you can see here, there were six allocations in 2005, and one in 2006 already. It doesn't always get -- it doesn't always get handed out. In 2003, there was an instance where a net block got handed back, becoming from non-bogon to bogon. The other peril of bogon filtering is that if you don't maintain it, you get this. Oh, that's a freaky font. This is a very common example of e-mails we see:
"Hi, I'm a director at the university. I just got a new block and I've already found six places that are filtering my e-mails because they use your bogon lists." Well, our bogon lists have been updated, the problem is that they were set up by the routers of the sites's filtering were set up by one person who walked away and never bothered to update their lists.
Martian may change as well, so you can't just say, well, I'm not going to filter unallocated space, I'll just filter martians. And generally the message here is that the best way to maintain bogon filters is to use some form of automated method to help keep them up to date.
When you do apply bogon filtering to your network, be sure to not filter things by accident. We've heard many instances of people applying bogon filters and cutting off their internal SNTV relays from their external SNTV relays. We also -- this has been a recent headache we've got, there's somewhere a spam detection package that uses one of our bogon lists, and it's a bit too aggressive in its filtering, basically if a bogon address shows up anywhere in the mail headers, it says, "Oh, this must be a bogon, I'm going to drop it." The problem is that a lot of people source mail from internal networks that use bogon addresses and thus valid mail is getting dropped. And of course all these packages say, "Please contact Team for assistance."
So, we offer a couple of services to help this. One service we offer is our bogon Route Server Project, where we will advertise the bogon prefix BGP, you can then configure your routers or other devices to use these prefixes -- filter bogons from your network.
When a change occurs in a netblock, coming either bogon or non-bogon, we will update our advertisements and if everything is done correctly, then you're filtering up these automatic.
For more information on the service and configuring examples, please use the link at the bottom.
Some technical details on the Bogon Router Project, currently we have 16 route servers on line at various locations on the world, we have 866 appearing sessions across -- 374 different ASNs. People are always curious about our route service are configured, we configure them based on our secure IOS and BGP templates which you can read at our documents directory on our Website.
Here's a quick example of how you can configure a router to use it, use our lists, you would set up a -- basically a route map that redirects all the prefixes you learn to -- or to use your favorite private address.
And then route that private address to zero, that's basically black holing the bogon route on your device.
We tag all the bogons with 888, right now, there's been -- we've been thinking about also tagging the martians with a martian and allocate it with different tags to allow you to use one or the other, based on the feedback I got yesterday, that's probably a good idea, so, we'll do that soon.
Here's an example so it's not just only -- basically the same thing, set up a black hole route, define between leads that you permit and set up your policy statement to set the next hop for all the routes received from us to your black hole routes.
We have full examples in much more details than those two slides available at our Website also for open BDP.
We've heard of people doing with -- found in other router -- if you have -- if you generate examples of using our templates, we'd love to hear it, please send it to us and we'll include it in our list.
Some people are justifiably concerned about us injecting routes into your routing tables, you can always control what we're giving you through prefix lists and if you don't want to -- at all, you can set up your own routes service using the same technique.
And as I demonstrated yesterday in the workshop, you can use Unicast RPF to filter both incoming and outgoing traffic on your devices.
If you don't like BGP at all, there are other alternatives, we offer text based lists, unaggregated and prefix list, Cisco, I was talking to one group yesterday to download our lists regularly, it incorporates it automatically into their regular filter regeneration which I think is spectacular.
We have templates -- servers to -- queries from bogon sources and we have instances in various routing databases for bogon and last but not least, we have a mailing list that you can subscribe to where we will basically send out mail whenever there's a change in advertising status.
For information on any of these, please go to.com/bogons.
Some useful links to keep in mind, again, the IANA address space link. We're not the only group who monitors bogon, there are several groups and here are some of the links here, they also offer tools, various tools for filtering bogon and we're going to be working with ARIN in the near future to offer some services to help -- help on addresses, help outdated filters when addresses become non- bogon and we'll be probably giving more information on that on future ARIN meetings.
Some other useful links, the BGP I just described is based on a technique called remote trigger black hole filtering which you can get from Cisco's FET site, also information on US URPF and they provide filter templates which you can use for coming up with a filtering strategy.
Steve has translated those into Juniper versions as well, so if you -- you can take a look at those.
And again, the link for bogon route service. So, real quick, how is it?
MR. CURRAN: Okay, thank you. Any questions for our speaker? No questions, bogons are just second nature to everyone. I guess so. Thank you very much.
MR. PLZAK: Okay. We are now at the time for open mic and I will remind you of the rules of the road here. We have drifted a little this afternoon in terms that some people are forgetting to say who they are and where they're from and so, please pay more attention to that tomorrow.
Anyway, John, I will turn over to you to conduct an open mic.
MR. CURRAN: Okay, this is the open mic session of our wonderful meeting. The microphones are opened for any topic, I ask that a policy proposal that has not been discussed and is on the agenda for tomorrow be held off and put tomorrow but anything else, policies that we have discussed or for that matter, anything that came up in the open policy BOF that was held on Sunday or an issue that you want to raise about ARIN itself, the microphones are opened for you to use now.
It is true that when we're done with the open mic session, we all get to leave and I know that sometimes it weighs heavily on people's mind on the decision of whether to approach the mic but they are opened at this time. Yes?
MR. DILLON: Michael Dillon, BT Radiant and I'm in favor of this proposal. Well, I think it's good to have an open mic.
I wonder if ARIN has ever considered giving some survey statistical analysis but I guess it begins with surveying the membership to find out what parts of their organization and what kind of roles within their organization, the various people who are represented as of the member companies fulfilled, if you can -- that?
In other words, the ARIN member companies are allowed to send two representatives to these meetings and just what kind of people are they, where do they come from, where do they fit within the organization, are they somewhere in engineering, are they in operations, are they in CTOs officers, are they in policy, et cetera, et cetera, and --
MR. CURRAN: Okay, let me ask the question because I know Susan, you administer surveys both here and occasionally the members, we don't do -- have we ever pulled people as to what their role is in the organization.
No, no, we have a number of CEOs and a number of mailroom clerks who come here under alias and we don't know who they are, literally, you can be anything in your company --
MR. DILLON: Yes, yes.
MR. CURRAN: -- and show up.
MR. DILLON: Yes, I know that and I get a sense, when things are being presented up here, sometimes people seem to be talking strictly to the engineering part of the crowd or strictly focusing on sort of -- what I consider nit-picky operational issues.
And I wonder whether we actually know the kind of broad range of people that are involved and -- because if we did, it would help better prepare -- well, the presentations and even policy proposals.
If you know who you're going to have to explain the policy proposal to.
MR. CURRAN: So, you're saying that if we had that information, it would help you in preparing a policy proposal for example.
MR. DILLON: Certainly yes, the presentation -- when somebody stands up there at the mic and presents it, the rational for the proposal as well, if you know the audience that you're speaking to, you can come up with a much better piece of work.
MR. CURRAN: Susan, do you want to respond?
MS. HAMLIN: With adding a line on the registration form for a title.
MR. DILLON: No, I was thinking more along the lines of a survey that actually didn't just deal with the people who happened to be here at this meeting but the entire set of ARIN member organizations who, in that organization, deals with the ARIN membership issue, I mean, who's the ARIN representative, what role do they fulfil, do they come to meetings.
Of course, the ones we're interested in and maybe the ones who come to meetings are the ones that participated opposed to the ones who don't but it would still be nice to know the whole scope of it.
MR. CURRAN: Do we collect title on the contacts, the member contacts?
MR. DILLON: Job titles don't mean a lot these days.
MS. HAMLIN: No, for -- but there are various contacts, there are various POC types and then there's a designated member representative and we don't collect titles on any of those.
MR. CURRAN: So, to clarify, you wouldn't want titles, you'd be looking for something more like what's your role in the organization.
MR. DILLON: Something like that, yes.
MR. CURRAN: Okay. It's possible that we could collect that, start collecting that on new members and on ongoing basis over time but it's process to get it for 2000 organizations.
MR. DILLON: No, what I was thinking of something like a sociological survey where you take a sociology or an anthropology student and have them do it as a summer project.
MR. CURRAN: Okay?
MR. DILLON: Okay.
MR. CURRAN: So, you're proposing a special -- we do a special survey for determining this.
MR. DILLON: I think the only way you can determine it is to do a --
MR. CURRAN: Okay.
MR. DILLON: -- a special survey.
MR. CURRAN: All right, so, we'll take that to the staff and to the board to talk about it. Microphones, I see we have -- Bill, are you at the microphone?
MR. WOODSTOCK: Sort of. My conscience here asked me to stand up and ask when ARIN was going to adopt ELDAP.
MR. CURRAN: When will ARIN adopt LDAP? So, are you proposing -- Bill, you're proposing we adopt LDAP?
MR. WOODSTOCK: I'm channeling my conscience.
MR. CURRAN: Mr. Kosters, are you proposing we adopt LDAP?
MR. KOSTERS: Could you clarify for what purpose?
SPEAKER: Actually that was what the data -- talking but that's okay. All right, Bill was being Bill.
MR. CURRAN: Okay, and you and the bad idea will now sit down, okay. Very good. Mr. Hannigan.
MR. HANNIGAN: Martin Hannigan, Renesys Corporation. Would there be a better solution and potentially getting the persons corporate affiliation on the proposals that come across PPML, it seems to be getting harder to differentiate between community proposals and proposals by people with corporate interests and it would -- and it's pretty hard to Google somebody's name sometimes and figure out whether they're standing on a policy, so, just like many times, Randy will say, who are you with and which affiliation are you using, I'd like to see if we could -- we could do that on proposals and my zip code is 021.
MR. CURRAN: Okay, thanks Martin. Microphones are opened.
We'll take the suggestion about affiliation and as well we'll talk about that among the staff on the board.
Microphones remain opened. I promise you that the social event is more than an hour and a half away so the microphones are opened and you're not losing any social time. Last chance.
People may not know it but I'm not going to be here tomorrow, so this really is your last chance to stand in front of me and play with the microphone. Okay. Thank you very much, I'll turn it over to Ray.
MR. PLZAK: Thanks John. Okay, before we end the day, a few things I need to say and if I can have enough to say it.
There we go. So, I guess I's supposed to read you your Miranda rights again, anyway, you've been read and if you don't want to have your picture taken, and those guys aren't taking pictures now anyway, you could hop out.
Reminders, the help desks at registration services are opened till 17:30, 5:30 p.m. and that's 40 minutes from now.
The Cyber Cafe is also opened until then. And day 2, the meeting breakfast will be at 8:00 a.m. and the meeting starts at 9:00.
Now, I would like you all to note that the agenda calls for us to adjourn this evening at 5:00 p.m., it is now about eight minutes before that hour so we have successfully negotiated the day.
So, since we have done, let's pat ourselves in the back and go out and party tonight, street party and 6:30, 6:50, get down to the lobby and -- or up to the lobby, which ever we're doing here, and pick up the badge and the directions to get to the street which is also accessible by subway.
Don't forget to complete those meeting surveys and earn your raffle entry for two lucky winners of the -- and let us thank all of our sponsors.
And also the non sponsor who is contributing the prize for tomorrow's drawing, Shaw Communications. And let's remember the rules of the road.
Although the -- I guess is in order tonight at the social if you want to do that, you could have done it last night at the foosball games as well, so -- table soccer, north of the 49th year, I guess.
And they're also be tables there tonight. I do understand that the bean counters who won last night are receiving a rather substantial challenge and have been told to bring themselves and their trophies to the street party so there could be some entertainment there as well.
So, with that, I'll say I'll see you guys at 7:00 tonight. Oh, excuse me, have I a comment over here?
SPEAKER: Yes. Some people came to us and asked if there was really a street party like outside, it's a covered up street, no need for coats but you need your coat to walk to the place.
MR. PLZAK: Yes, I'm sorry, it is a covered up street but it is a street you -- well, it depends on how brave and harder you are, if you, whether or not, you want to wear your coat to walk to that street but it is a street party setting, so, it will be a good one.
So, anyways, with that, see you at 7:00 tonight and for some reasons, you can't make it tonight, we will see you tomorrow morning at 9:00 in here for the meeting, thanks.
(Whereupon, the PROCEEDINGS were adjourned.)